Company Growth: The Good, the Bad and the Ugly

The Good

The company continues to grow year over year. We continue to hire and also acquire a few other companies. Starting from just a few engineers in San Francisco, by 2020, we had diverse engineering teams working from different continents (Asia, Europe, and America).  

The Bad and Ugly

Some of the challenges that came with the growing organization were:

• Teams sometimes made decisions that prioritized their own success over the overall success of the organization.
• Engineers spent a lot of time discussing trade-offs during the technical discussions because there were no clear guidelines on what was important for the organization. Is it speed? Is it reliability?
• Sometimes different teams solved the same problem differently resulting in unnecessary duplication and maintenance costs.
• There were issues regarding cross-team collaboration and communication in general. The cultural difference and time zone difference made it even more challenging.
  

How to Break Down Processes Into Smaller Chunks

To begin with, we started by emphasizing the company values and how that translated into the way the Engineering teams should work together. Why? Instead of each team having their own values, we wanted everyone to follow company values, ensuring that everyone was on the same page and eliminating misunderstandings. We updated our hiring process to include questions related to our values and evaluate candidates based on those values. We updated our performance review process to make sure that the people we promote are those who exemplify our company values.

From there, we worked on our Technology Pillars and Principles. Pillars are the overarching umbrella on what we should prioritize when making technical decisions. E.g. reliability over speed, security over efficiency, etc. These pillars are not invented in a vacuum but based on the feedback from our customers and internal stakeholders. From the pillars, comes the technical principles, which express our preferences when evaluating problems or making decisions. E.g. We should prefer battle-tested technology over cutting-edge technology to reduce the unknown unknown and keep the platform reliability high. If functionality is a key business differentiator then we should prefer to build, rather than buy and/or customize.

Next are the Technology Map and Architecture Northstar. Technology Map is a collection of technology used within the company and their stages (Default Choice, Allowed, Trial, Deprecated), which is inspired by ThoughtWork’s Tech Radar. The goal is to provide visibility around what technology we currently support and should be used vs what should not be used anymore (deprecated) vs future technology we are trialing. We also write down the process for introducing and evaluating new technology that the team wants to bring in. The Architecture Northstar is a forward-looking architecture design to ensure that teams are moving in the same direction. E.g. Given the importance of security for the company, we will have security tools embedded as part of the developer life cycle so that we can find security vulnerabilities as early as possible.

We also introduced programs like recorded lunch and learn sessions. It encouraged teams from different regions to eat together in a group while simultaneously utilizing the time to complete training or other activities. We had an ongoing bi-weekly update through Slack about the work being done and delivered, updates on new technologies adopted, updates on the overall health of the platform, and other engineering updates. The goal is to keep everyone aligned in terms of where we are and where we are going.

In summary, we started from crafting the overarching direction and then broke it down into smaller, more manageable processes. We also invited the managers and the senior ICs to provide feedback and suggestions so that we can get buy-in from them.

Lessons Learned

• We are often hesitant to introduce new processes into the organization because of the bureaucracy sentiment that comes with it. But, not having one can also create confusion, friction, and misunderstanding. Relying on word of mouth does not work as you scale and have people in different locations and time zones. Having it written down also ensures that everyone has access to the same information.
• As you define your process and guidelines, make sure to invite the manager and the engineer to provide feedback and get buy-in. Often they can also provide you with different viewpoints or help you clarify your message.
• Discussing values and direction can be challenging because different people have different opinions. However, if you can successfully manage it, you can create a strong alignment across your engineering teams.