Horizontally Scaling the Engineering Organization

Problem

As an organization grows, it becomes harder to maintain efficiency without splintering and fractioning teams to a certain extent. A startup usually has one engineering team, and they are all working on the same thing. As it grows, it wants to do more things simultaneously, and that ceiling is typically hit around 20 to 25 engineers. The company becomes inefficient because the processes they used to manage the team of a smaller size are not the processes they will need three months from now with that level of growth.

Trying to replicate the same approach of large, mature companies will be inefficient because their approach is predicated on a massive framework that is being built over the decades. The transition from a monolith team to a number of smaller teams producing different things is challenging because it entails preserving the cohesion, stability, and identity of the proto-team.

Actions taken

For starters, you should look at the macro perspective of what you are trying to achieve -- are you working on two simultaneous projects, dealing with large tech debt, trying to build a new platform while maintaining the old one, or keeping customers while working on new features. It is often nuanced and even ambiguous, so make sure that you know what your company is trying to accomplish.

Your main task would be to get your head around how you could start organizing human beings that they don’t have to interfere with each other to get the work done. You should define what the atomic constructs that maximize local decision making are. For example, you should be able to group together two full-stack engineers, a mobile engineer, PM, and UX person, and figure out the set of objectives they should accomplish without passing tickets to other teams and having many cross-dependencies. To identify what the generalized structure you need differs largely from one company to another. For example, a sales-heavy company may need five engineers dealing with the inbound incremental feature requests from customers in the field and defects and effective solutions. Your focus on the larger picture should determine what you need.

By creating more teams or matrices, you will be introducing more proxies; therefore, you will become less efficient. Over time, it becomes harder to track engineering decisions, sustain the common ground, reduce tech debt, etc. This is why you need to build a layer of technical governance to coordinate how you handle platform initiatives, build tools, CI/CD pipelines, etc. Also, you should enforce more rigorously documentation and standardization -- if you are designing something, there should be a template for how this is done and how other people can be informed about what you are doing. Sometimes, you need to create additional channels for people to broadcast their ideas and have other people outside their group to provide feedback or commentary.

Transparency is a must if you want to keep your team as horizontal as possible. For example, I don’t like private Slack channels or any private communication channels at all. Unless it is some confidential HR information, it should flow freely across the organization. The founding team could significantly suffer the ‘erosion’ of transparency that happens when the communication starts to spread across separated channels that include a much larger number of people. They would want to maintain the same level of transparency; otherwise, they will feel they are pigeonholed into a much smaller function. Moreover, when people are complaining of transparency, it is not that they are unaware of the end decisions, but how those decisions have been made.

Lessons learned

• For most companies, finding ways for people to do simultaneous development is a win. You will lose some efficiency, but what you lose in efficiency, you will gain in adaptability. Doing more things in a horizontal manner without letting everything turn into chaos ensures the most significant wins for startups.
• If you can do more things at once, you can fail at more things at once, which means your business can take more risks simultaneously. You can push for both incremental and non-incremental features: the incremental features will get you the static curve revenue going up and non-incremental can evolve into a whole new product line.
• Some operational models land better when everything is localized, like microservices, and cloud-native services tend to be more atomic and manageable. Also, trying to restructure code sections and produce solid documentation can help people understand what other people are working on, even in a more dispersed setting.