Back to resources

Horizontally Scaling the Engineering Organization

Scaling Team
Team Processes

11 January, 2021

Ken Pickering
Ken Pickering

VP, Engineering at Starburst Data

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

How to Streamline Your Recruitment Process for Quick and Effective Hiring

26 May

Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.

Scaling Team
Building A Team
Hiring
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Managing Culturally Diverse Remote Teams

11 May

Tom Hill, Engineering Manager at Globality, Inc., shares how he works with a culturally diverse team based within a thirteen-hour time gap.

Scaling Team
Handling Promotion
Remote
Onboarding
Hiring
Cultural Differences
Tom Hill

Tom Hill

Engineering Manager at Torii

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

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.