Elevate Spring Summit has been announced (Thu, Mar 11th)

🔥


Don't have an account? 

Horizontally Scaling the Engineering Organization

Scaling Team
Team processes

11 January, 2021

Ken Pickering, VP of Engineering at Starburst Data, explains how to structure a product engineering organization to maximize results and address inefficiencies through horizontal scaling.

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.

Related stories

Horizontally Scaling the Engineering Organization
11 January

Ken Pickering, VP of Engineering at Starburst Data, explains how to structure a product engineering organization to maximize results and address inefficiencies through horizontal scaling.

Scaling Team
Team processes
Ken Pickering

Ken Pickering

VP, Engineering at Starburst Data

Creating an Evolving Process to Address Customer Issues
11 January

Sabeen Syed, Senior Engineering Manager at HashiCorp, explains how she initiated a process to address customer issues by creating a community engineer role that further evolved over time.

Users Feedback
Team processes
Sabeen Syed

Sabeen Syed

Senior Engineering Manager at HashiCorp

Fostering a Culture of Experimentation
11 January

Sabeen Syed, Senior Engineering Manager at HashiCorp, talks about how she supports her team to come up with all kinds of ideas and why creating a structure that would encourage these efforts is vital for fostering a culture of experimentation.

Company Culture
Team processes
Sabeen Syed

Sabeen Syed

Senior Engineering Manager at HashiCorp

Structuring a Startup for Scale
30 December

Wadah Sayyed, Director of Engineering at HPE, discusses how he helped set his startup for success by mapping out ownership structures and building teams around clear ownership.

Scaling Team
Ownership
Team processes
Wadah Sayyed

Wadah Sayyed

Director of engineering at HPE

Building Internal Tools and Balancing Different Stakeholders’ Requirements
28 December

Frances Li, Lead Product Manager at Carta, describes how she created a unique framework that helps her balance different stakeholders’ requirements when building internal tools.

Managing Expectations
Collaboration
Team processes
Prioritization
Frances Li

Frances Li

Lead Product Manager at Carta

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.