The first 18 Months

I have been fortunate(or not) enough to be part of some of the early stage startups as well early stage products built at a larger org. I found one thing common in both places. The first 18 months in both places is a make or break situation. In a startup, you are hoping to find the product fit and customer traction before the money runs out. In a larger org, you are hoping that the management's patience does not run out while you build the product and consider alternatives such as buy or partner. Add to the mix of working from a remote site, you have an explosive combination.

Reality of a Remote Site

If you worry about the things that you cannot control, you are setting yourself up for a lifetime of misery and frustration - Unknown Source

Here are some of the realities that you will not be able to change. My observations are based on companies with headquarters on the west coast with a remote office in India. The observations are not specific to any particular organization

The Nerve Center of an org will always be the Head Quarters. There are multiple reasons: A large customer base (Mostly in North America) and the ability for execs to have interactive discussions works against a remote site. So it is obvious to see a large number of leadership roles clustered at the Headquarters. The epidemic may change this behavior with companies going all out remote.
Time difference. India and the US are on the opposite sides of the globe. Late night meetings are something that you cannot avoid but learn to work your schedules around it. You need to build bridges with your network to get all the information.
Uncertainity. During the early stages, there several uncertainities faced by the org. You will have the joys of customer wins. Similarly some days are extremely bad with product falling apart or asks for new features within a short time frame (read countless war rooms) While uncertainities are not unique to a remote site, it only magnifies 10X Open Communication with the team is helpful. You will also be making countless decissions on a day 2 day basis. Some of them will go wrong but dont kill yourself for the wrongs

What to expect during the first 18 months

Time and Tide waits for None

You need to deliver value to your customers with your product and show consistent progress to your sponsors. When you start off as a 1 man army, you are alone and running against time. Here are some techniques to manage precious time and deliver value to customers

Planning and Setting Schedules

As soon as I moved back to India to head the group, I came up with my 30-60-90 day plan. Everyone will be busy and no one will probably ask you but I found sharing the plan makes it easy to get on the same page with your peers, team and boss. I suggest you go with monthly plans and follow disciplined schedules to hit the dates

Ruthlessly Prioritize

During the first 18 months, you are mostly in “execute, execute, execute” mode. While you iterate and deliver products to early customers, listen to their feedback. At this stage of the product, when the customer is happy with certain good enough features of the product but needs certain additional capabilities, focus on adding customer requested capabilities. No need to further tune the capability. You may also have to throw away code that the team put a lot of effort on. Be transparent and reason out the prioritization with the team

Take all the help you would get

Help pours in from unexpected corners. Be open about taking help from others whether it is for building teams or building features. In our case, I had to build a Capacity Planning Service in less than 3 months and I had only 1 person who was free to take this up. Fortunately one of my colleagues in a different group had engineers with relevant experience and were interested in working on a new product. This just worked out and we were able to release the service just in time.

Building the Team

If you are building a product ground up, you will probably hire about 50-60 people by the end of the first year. If your product has the market acceptance and you are trying to add new teams to scale at a remote site, you should be able to hire faster with one scrum team at a time.

Adding too many people at a rapid pace may have growing pains at a later time. However it is rare that you get a perfect candidate. So look for people who are willing to learn and are really motivated to join you.

Look ahead by 2-3 years

During the major part of the first year, everyone works on everything. Assuming you are hiring about 20 people per year and plan to double every year, do not try to go with hiring 1 scrum team at a time philosophy if your product is still evolving. Instead focus on hiring staff level engineers/doers who can help evolve the product and are looking for growing to the next level. The team may look top heavy during the first year, but as you fan out teams in the second year, you will be able to make appropriate adjustments. Focus your initial hiring on attitude, ability to work with uncertainties and ownership

Delegate when possible

It is very natural for the leader to be wanting to be involved with all the interview decisions. While it makes sense that you hire the first 10-12 founding team members, you may have to delegate the next level of hiring to the team. While you can be a participant in the interview process, delegating the hiring to the leads/managers increases their trust in you and frees up time for you.

Interviews and Onboarding

You and your team will spend a significant amount of time interviewing and training new hires. Document the onboarding steps and keep it current. Assign a buddy to a new hire during the first month so that he/she becomes productive within a short span of time

Culture

Building a strong team requires putting together the right culture. The right culture has a multiplier effect. Usually people do appreciate places that trust them and give them autonomy. In addition, you would have to stress on the following and lead by example.

Customer Centric and Data Oriented

Unless the employee's show empathy to customer’s problems, the org cannot win and keep customers.

If the employees are not aware of the problem, they do not empathize. Make sure your product has built in telemetry that captures the failures and their implications. Build dashboards and measure metrics such as customer uptime accessible by everyone
Facilitate interactions with Support/SRE team and Customers. This could be an offer to do training on newer features, jumping in when the system goes down or just hosting them for lunch to get to know them
Add Customer Specific OKR at the Org level and measure it. People love the OKR and this shows the org is aligned to make the customer successful. Reward people that have gone beyond the call of duty.

Execution Focussed

Unless the team churns out products that customers pay for there is no business. Clearly articulate the vision and share the OKR openly amongst the teams. Bonus numbers should match the OKR results.

Inclusive and Collaborative

Inclusive and Collaborative culture will result in Innovation and a motivated team. Here are some things that you may want to do

Ensure everyone gets a chance to share their thoughts and opinions. Do not tolerate jerks.
Be Honest and Transparent. Share the challenges and encourage the team to provide their feedback
Set up group team building activities so that people get to learn from each other in an informal setting. It immensely helps with collaboration

Product Fit

It usually takes time to iterate and build a product that gets acceptance from customers. The initial set of product releases will prioritise feature and quality over time. Most of the enterprise customers that you interact with will not put your software in production. This gives you time to improve while addressing key customer pain points.

Always focus on what more an existing customer can buy instead of trying to go look for a new set of customers. Customers love products that help them increase their revenue and seamlessly integrate within their existing set up. So focus more on building capabilities that helps the customers increase revenues and does not require them to rip and replace their existing environments.

Right Architecture

It is known fact that products evolve in a startup. So migrations should be considered part of life. However wrong choices made during the software architecture will have lasting pains for the team. While it is OK to go with monolith with SOA before you transition to micro services care must be taken to ensure the architecture is solid.

Few things to consider

How experienced is the team building such solution? If the answer is this is their first time coding such service, you may have a problem. Make sure you have people that you gone through the experience building something similar
Are you building on something new shiny but unproven product by another startup? I had experienced disaster at a startup trying to build on a new network processor that was not proven. Pls dont mix 2 unknown things given your business is at stake
Do you have people that have deep expertise in their domain/industry. Lacking such expertise will result in software being written to meet all needs and and using shiny technologies not required for the use case. Dont build a bloatware

Team Building Activities

As you are hiring aggressively, you will also need to ensure the team comes together. Lunches and Outtings are all great, but I found success with team building that involves volunteering for local community causes. It helps build the right culture of caring for your community while building bonds with your team.

Caring for Self

The first 18 months can be very much intimidating. You may sometimes question the choices you may have made. But do realize that it is a job and let it not impact your family life. You need to pace yourself and do not run after unrealistic goals.