Building an Org at a Remote Site - Part 2
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.