Key takeaways
Scaling is no longer synonymous with hiring. The question in 2027 is how to grow output without growing headcount at the same rate.
Output grows at best linearly with headcount while communication overhead grows quadratically. That gap is the whole scaling problem.
Senior review capacity is now the binding constraint in most growing organizations, not the ability to produce code.
Structure the org the way you would structure software: clear interfaces, minimal shared surface, unambiguous ownership.
Measure teams and systems. Ranking individuals produces behaviour, not information, and it breaks the data you need to scale well.
Everything you did as a team of ten stops working somewhere around thirty, and breaks properly around a hundred. Delivery processes, project management, communication, code review, all of it needs rebuilding at each threshold. What has changed going into 2027 is the first move. For a decade the answer to needing more output was hiring more engineers. Now it is one option among several, and often not the cheapest one.
There is a structural reason growth gets harder rather than easier, and it is worth stating precisely because it explains almost every symptom below. The best case for output is that it grows linearly with the number of people. The number of possible communication paths between those people grows quadratically. Double the team and you get at most twice the output against roughly four times the coordination surface.
Figure 1
Output grows linearly. Coordination grows quadratically.
Conceptual, not measured. Every structural decision below exists to flatten the orange line rather than to steepen the purple one.
Most organizations feel the first squeeze around twenty to thirty engineers, then hit it again at every rough doubling. The failure mode of rapid growth is predictable: impact per engineer falls, silos harden, and the organization loses the ability to change direction quickly, which was the advantage it had when it was small.
The old scaling playbook had one lever. If you needed more delivered, you hired. That is still available, but it is now the slowest and most expensive of four, and in a flat budget it may not be available at all. Before opening a requisition, work through the others.
Figure 2
Four ways to add capacity, cheapest first
This ordering is not a rhetorical trick, it is a time-to-value ranking. A new hire is productive in months and adds coordination overhead on day one. Cutting review latency in half helps everyone next sprint. If you cannot say what share of your current effort goes to unplanned work, you are not yet in a position to argue that headcount is the constraint. Our rework calculator will give you a first number.
The problem. Hiring is slow, expensive and easy to get wrong under pressure. A bad hire costs more than the empty seat did, and hiring fast measurably increases the odds of one.
Hire for the gap, not the archetype. Writing job descriptions modelled on your existing strong performers produces a team that is good at the same things and blind in the same places. Ask instead which capability the team lacks, and whether this person covers a teammate’s weakness or amplifies it. In most growing organizations the honest answer is that the gap is senior judgment and review capacity rather than more people who can produce code.
What to screen for. Open-minded collaborators, strong written communication, low ego with high self-esteem, and ruthless prioritisation. Competency can be developed; character rarely changes. That advice held in 2015 and holds now, with one addition: judgment about when not to trust a generated answer is a hireable skill and increasingly the differentiating one.
The problem. Joining a fast-growing organization is disorienting, and without a system every new hire works twice as hard to learn what they need. At scale that waste compounds.
Make onboarding a replicable asset. Document it, assign each new hire a buddy who can explain the undocumented parts, and set explicit milestones for the first weeks. Then have every new starter improve the documentation as they go, so the next person has a better experience than they did. That single habit turns onboarding from a recurring cost into an appreciating asset.
One 2027 addition. Onboarding now has to cover how the organization uses AI: what agents may touch, what must be reviewed by a human, and what the standards are for verifying generated work. Leaving that to osmosis is how inconsistent practice spreads faster than you can correct it.
The most useful framing for organizational design is the one engineers already understand. When you design software you give each component a clear interface, a minimal public surface, and unambiguous ownership of its state. Organizations need the same properties, with teams as the components.
If it were unclear who owns a data structure, or whether you needed a lock before writing to it, you would call that a design defect. Organizations ship that defect constantly: teams accountable for outcomes they have no authority to change, and decisions nobody clearly owns.
Close the gap between accountability and authority. A team responsible for a metric it cannot influence is set up to fail and knows it. This is the single most common structural defect in scaling organizations and the one that drives the best people out first.
Stop relying on heroes. A handful of people who understand everything is an efficient structure at fifteen engineers and a liability at fifty. When the hero is unavailable, or simply reaches the limit of what one person can hold in their head, delivery stops. The fix is smaller teams with real autonomy and documented interfaces between them, which is the pattern most organizations converge on eventually and expensively.
Separate the management structure from the delivery structure where you can. If project teams can form and dissolve without anyone changing manager, you get flexibility without the disruption of a reorganisation. Since the biggest single predictor of whether someone enjoys their job is their relationship with their manager, decoupling those two things protects retention while you keep reshaping delivery.
This is the biggest structural change since this article was first written. Scaling used to mean adding capacity to produce code. Producing code is now the cheap part. The scarce resource is the senior attention needed to review, verify and integrate it, and that scales with people rather than with tooling.
The practical consequences for how you structure a growing organization:
| What to watch | The warning sign | The structural fix |
|---|---|---|
| Review concentration | A few names appear on most reviews across many teams. | Grow reviewers deliberately. Pair juniors into reviews as training, not just as authors. |
| Review depth | Approvals getting faster with fewer comments as volume rises. | Cap change size. Large reviews get rubber-stamped whoever wrote them. See merge quality. |
| Stage imbalance | Coding time falling while review and deploy time grow. | Move investment downstream. Track cycle time by stage rather than in total. |
| Delayed quality cost | Throughput up this quarter, incidents and rework up next. | Report change failure rate beside every velocity number. See DORA metrics and code churn. |
Know why you are scaling. Copying the practices of a company you admire is tempting and frequently useless, because their constraints are not yours. Are you entering unfamiliar territory that needs expertise you lack, or do you simply need more of what you already do well? Those two answers lead to completely different hiring and structural decisions.
Fight the drift toward misalignment. As layers accumulate, keeping people connected to company goals gets harder, and the honest work is building awareness of what other parts of the organization are dealing with. Alignment is not a document, it is whether a team can explain why the thing they are building matters.
Set expectations explicitly. A surprising number of engineers cannot articulate what is expected of them, and ambiguity is expensive at scale. Use targets at team and organization level, and revisit them with the team rather than announcing them. There is a longer treatment in our guide to engineering OKRs.
One rule about measurement while scaling
Measure teams and systems, never individuals. It is tempting during growth to want per-engineer scorecards, and it is the fastest way to destroy the data you need. Once people understand a number affects how they are judged, they optimise for the number: smaller commits, less pairing, less willingness to fix the unglamorous thing or help someone else. Use team insights and internal benchmarking for performance questions, and contributor context only as an input to coaching conversations.
Done well, growth delivers four things worth having. Done badly it delivers the coordination cost without any of them, which is why the sequencing above matters.
Parallel capacity. More initiatives running at once, and the ability to respond to a market shift without stopping everything else.
Resilience. Fewer single points of failure. Knowledge held by three people rather than one is the difference between a holiday and an incident.
Genuine career paths. Enough structure for people to progress without leaving, which is cheaper than replacing them.
Broader perspective. Larger organizations sit closer to product, design and support, and engineers who hear the customer directly build better things.
The short version
Scaling is not a hiring problem, it is a coordination problem that hiring makes worse before it makes it better. Remove waste, unblock the flow, change the work, and only then add people. Structure the organization with the same discipline you would apply to a codebase, and measure the system rather than the people inside it.
Find your actual constraint
Connect your repositories and we will backfill your history, so you can see where review load is concentrated, which stage is slowing delivery, and what share of effort goes to unplanned work before you decide to hire.
For engineering leaders: Engineering Managers · Executives · Engineering Leaders Handbook · Becoming a great engineering manager · People, process, technology
Measure it: Cycle Time · DORA metrics · Merge Quality · Team Insights · Benchmark · Developer Experience · Resource Planning
Further reading: The WAY Framework · Code churn and AI code churn · Cost of rework · Measuring AI ROI
Key takeaways
Scaling is no longer synonymous with hiring. The question in 2027 is how to grow output without growing headcount at the same rate.
Output grows at best linearly with headcount while communication overhead grows quadratically. That gap is the whole scaling problem.
Senior review capacity is now the binding constraint in most growing organizations, not the ability to produce code.
Structure the org the way you would structure software: clear interfaces, minimal shared surface, unambiguous ownership.
Measure teams and systems. Ranking individuals produces behaviour, not information, and it breaks the data you need to scale well.
Everything you did as a team of ten stops working somewhere around thirty, and breaks properly around a hundred. Delivery processes, project management, communication, code review, all of it needs rebuilding at each threshold. What has changed going into 2027 is the first move. For a decade the answer to needing more output was hiring more engineers. Now it is one option among several, and often not the cheapest one.
There is a structural reason growth gets harder rather than easier, and it is worth stating precisely because it explains almost every symptom below. The best case for output is that it grows linearly with the number of people. The number of possible communication paths between those people grows quadratically. Double the team and you get at most twice the output against roughly four times the coordination surface.
Figure 1
Output grows linearly. Coordination grows quadratically.
Conceptual, not measured. Every structural decision below exists to flatten the orange line rather than to steepen the purple one.
Most organizations feel the first squeeze around twenty to thirty engineers, then hit it again at every rough doubling. The failure mode of rapid growth is predictable: impact per engineer falls, silos harden, and the organization loses the ability to change direction quickly, which was the advantage it had when it was small.
The old scaling playbook had one lever. If you needed more delivered, you hired. That is still available, but it is now the slowest and most expensive of four, and in a flat budget it may not be available at all. Before opening a requisition, work through the others.
Figure 2
Four ways to add capacity, cheapest first
This ordering is not a rhetorical trick, it is a time-to-value ranking. A new hire is productive in months and adds coordination overhead on day one. Cutting review latency in half helps everyone next sprint. If you cannot say what share of your current effort goes to unplanned work, you are not yet in a position to argue that headcount is the constraint. Our rework calculator will give you a first number.
The problem. Hiring is slow, expensive and easy to get wrong under pressure. A bad hire costs more than the empty seat did, and hiring fast measurably increases the odds of one.
Hire for the gap, not the archetype. Writing job descriptions modelled on your existing strong performers produces a team that is good at the same things and blind in the same places. Ask instead which capability the team lacks, and whether this person covers a teammate’s weakness or amplifies it. In most growing organizations the honest answer is that the gap is senior judgment and review capacity rather than more people who can produce code.
What to screen for. Open-minded collaborators, strong written communication, low ego with high self-esteem, and ruthless prioritisation. Competency can be developed; character rarely changes. That advice held in 2015 and holds now, with one addition: judgment about when not to trust a generated answer is a hireable skill and increasingly the differentiating one.
The problem. Joining a fast-growing organization is disorienting, and without a system every new hire works twice as hard to learn what they need. At scale that waste compounds.
Make onboarding a replicable asset. Document it, assign each new hire a buddy who can explain the undocumented parts, and set explicit milestones for the first weeks. Then have every new starter improve the documentation as they go, so the next person has a better experience than they did. That single habit turns onboarding from a recurring cost into an appreciating asset.
One 2027 addition. Onboarding now has to cover how the organization uses AI: what agents may touch, what must be reviewed by a human, and what the standards are for verifying generated work. Leaving that to osmosis is how inconsistent practice spreads faster than you can correct it.
The most useful framing for organizational design is the one engineers already understand. When you design software you give each component a clear interface, a minimal public surface, and unambiguous ownership of its state. Organizations need the same properties, with teams as the components.
If it were unclear who owns a data structure, or whether you needed a lock before writing to it, you would call that a design defect. Organizations ship that defect constantly: teams accountable for outcomes they have no authority to change, and decisions nobody clearly owns.
Close the gap between accountability and authority. A team responsible for a metric it cannot influence is set up to fail and knows it. This is the single most common structural defect in scaling organizations and the one that drives the best people out first.
Stop relying on heroes. A handful of people who understand everything is an efficient structure at fifteen engineers and a liability at fifty. When the hero is unavailable, or simply reaches the limit of what one person can hold in their head, delivery stops. The fix is smaller teams with real autonomy and documented interfaces between them, which is the pattern most organizations converge on eventually and expensively.
Separate the management structure from the delivery structure where you can. If project teams can form and dissolve without anyone changing manager, you get flexibility without the disruption of a reorganisation. Since the biggest single predictor of whether someone enjoys their job is their relationship with their manager, decoupling those two things protects retention while you keep reshaping delivery.
This is the biggest structural change since this article was first written. Scaling used to mean adding capacity to produce code. Producing code is now the cheap part. The scarce resource is the senior attention needed to review, verify and integrate it, and that scales with people rather than with tooling.
The practical consequences for how you structure a growing organization:
| What to watch | The warning sign | The structural fix |
|---|---|---|
| Review concentration | A few names appear on most reviews across many teams. | Grow reviewers deliberately. Pair juniors into reviews as training, not just as authors. |
| Review depth | Approvals getting faster with fewer comments as volume rises. | Cap change size. Large reviews get rubber-stamped whoever wrote them. See merge quality. |
| Stage imbalance | Coding time falling while review and deploy time grow. | Move investment downstream. Track cycle time by stage rather than in total. |
| Delayed quality cost | Throughput up this quarter, incidents and rework up next. | Report change failure rate beside every velocity number. See DORA metrics and code churn. |
Know why you are scaling. Copying the practices of a company you admire is tempting and frequently useless, because their constraints are not yours. Are you entering unfamiliar territory that needs expertise you lack, or do you simply need more of what you already do well? Those two answers lead to completely different hiring and structural decisions.
Fight the drift toward misalignment. As layers accumulate, keeping people connected to company goals gets harder, and the honest work is building awareness of what other parts of the organization are dealing with. Alignment is not a document, it is whether a team can explain why the thing they are building matters.
Set expectations explicitly. A surprising number of engineers cannot articulate what is expected of them, and ambiguity is expensive at scale. Use targets at team and organization level, and revisit them with the team rather than announcing them. There is a longer treatment in our guide to engineering OKRs.
One rule about measurement while scaling
Measure teams and systems, never individuals. It is tempting during growth to want per-engineer scorecards, and it is the fastest way to destroy the data you need. Once people understand a number affects how they are judged, they optimise for the number: smaller commits, less pairing, less willingness to fix the unglamorous thing or help someone else. Use team insights and internal benchmarking for performance questions, and contributor context only as an input to coaching conversations.
Done well, growth delivers four things worth having. Done badly it delivers the coordination cost without any of them, which is why the sequencing above matters.
Parallel capacity. More initiatives running at once, and the ability to respond to a market shift without stopping everything else.
Resilience. Fewer single points of failure. Knowledge held by three people rather than one is the difference between a holiday and an incident.
Genuine career paths. Enough structure for people to progress without leaving, which is cheaper than replacing them.
Broader perspective. Larger organizations sit closer to product, design and support, and engineers who hear the customer directly build better things.
The short version
Scaling is not a hiring problem, it is a coordination problem that hiring makes worse before it makes it better. Remove waste, unblock the flow, change the work, and only then add people. Structure the organization with the same discipline you would apply to a codebase, and measure the system rather than the people inside it.
Find your actual constraint
Connect your repositories and we will backfill your history, so you can see where review load is concentrated, which stage is slowing delivery, and what share of effort goes to unplanned work before you decide to hire.
For engineering leaders: Engineering Managers · Executives · Engineering Leaders Handbook · Becoming a great engineering manager · People, process, technology
Measure it: Cycle Time · DORA metrics · Merge Quality · Team Insights · Benchmark · Developer Experience · Resource Planning
Further reading: The WAY Framework · Code churn and AI code churn · Cost of rework · Measuring AI ROI
Ready to unlock your SDLC productivity?
