More Engineers, Less Impact? The Diminishing Returns of Team Growth
- Klara Furstner
- Sep 21
- 8 min read
Updated: Sep 22
You’ve heard it and thought it a hundred times: “We need more engineers to hit deadline.” Intuitively, adding people should get things done faster. But anyone who’s worked in software knows: past a point, more engineers can actually slow the team down.
But this isn’t just a management headache; it’s textbook economics.
The Law of Diminishing Marginal Product explains that if you keep increasing one input (say, labor) while holding others constant (like capital, tools, or processes), the marginal gains from each additional unit shrink over time. As Economics Help puts it:
“Eventually, adding more workers leads to lower per-worker output, due to fixed capital and overcrowding.”
Swap “capital” for senior engineering time, decision-making spread across many people, or a fixed number of supporting roles like PM and QA, and you’ve got a picture of what limits output in fast-growing engineering teams. Early hires solve obvious problems, but beyond a certain point, communication overhead, unclear ownership, and shared bottlenecks start to erode impact. The key is knowing when you’re gaining leverage and when you’re just adding friction.
TL;DR
Marginal return = extra output from hiring one more engineer, holding scope constant.
Rooted in classic economics: when one input (e.g. engineers) increases but others (architecture, PM/design bandwidth, CI) stay fixed, the output per unit eventually falls.
Causes include coordination cost, dependencies, onboarding drag, and upstream bottlenecks.
Rule of thumb: small, stable teams (4–8 engineers), infrastructure before headcount.
Shift the curve by investing in modular architecture, balanced staffing, and fast validation cycles, like rapid code reviews, quick test feedback, and incremental releases
If possible, track marginal throughput, cost per unit, and flow metrics to spot the curve in action.
What “Marginal Returns” Means in Software
Marginal return is a simple idea: if you add one more engineer to a team, how much more output do you get? That output might be features delivered, bugs fixed, lead time shortened, or even direct revenue impact, assuming the scope and systems stay the same.
And here’s the important bit: marginal return isn’t constant. It changes depending on how well your systems scale. And when you don’t scale the system, the extra hands don’t help as much (and sometimes hurt).
The Typical Curve of Returns
Let’s break down the pattern most leaders have seen, but don’t always name.
1. Early Increasing Returns
Most engineering leaders have seen this firsthand. When a team is small and clearly understaffed, adding a few engineers unlocks immediate impact. You fill gaps in key areas like infrastructure or frontend. On-call load gets more manageable. Reviews get faster. Parallel work becomes possible, and team members stop stepping on each other. It also reduces the need to multitask across multiple initiatives and cuts down on context switching, which means engineers can stay focused and ship higher-quality work. In this phase, adding people doesn’t just increase output, it actually improves output per person, because you’re removing constraints that were limiting the team’s effectiveness.
2. Diminishing Returns
As hiring continues, the dynamics start to shift. Each new person adds a little less than the one before. The team now has more communication edges, more reviewers on each pull request, and more people in every planning, standup, or sprint review. The number of meetings might not go up dramatically, but each one takes longer and gets less done per person, because more voices are in the room and the cost of alignment increases.
Fred Brooks outlined this decades ago in The Mythical Man-Month, noting that adding more people to a late project often makes it later. The reason? New engineers need ramp-up time, and every new person increases the number of communication paths. His formula for group intercommunication is: n(n − 1)/2
So a team of 50 developers doesn’t just have 50 voices, it has 1,225 potential communication channels. That overhead slows everything down, especially when the team isn’t modular or decisions aren’t clearly owned.
Senior engineers spend more time helping, unblocking, and reviewing work from newer or less experienced teammates. Their own deep work suffers, and their output drops. Meanwhile, the people they’re helping often end up waiting (sometimes hours or even days) for guidance or review before they can move forward. Work slows down on both ends. Output still grows, but now you're getting less incremental value from each additional hire.
3. Negative Returns
Eventually, growth hits real friction. Product and design can’t keep up with the size of the engineering team, so engineers either idle, self-prioritize, or pivot mid-build when priorities shift. There’s more work in motion, more people involved in each decision, and less clarity about who owns what.
At this stage, senior engineers often shift into default “architect” mode; providing direction, reviewing code, and unblocking others, but no longer writing much code themselves. Their time becomes fragmented across design reviews, planning, and technical oversight. Meanwhile, newer or less experienced engineers are producing more output, but with less validation and fewer feedback loops. There’s simply too much surface area to keep up with.
Quality can suffer. Ownership thins out. More bugs slip through. And unless the QA team scales along with engineering, the system starts to crack in subtle but compounding ways.
And beyond process breakdowns, there’s a psychological effect in play too. In larger teams, individual contribution often drops; not from lack of effort, but because ownership feels diffuse and direction unclear. It’s the Ringelmann Effect, observed across many types of teams: as group size increases, individual effort tends to drop and coordination becomes harder. In software, that often shows up as slower decisions, reduced accountability, and less motivation to take ownership because no one is quite sure who’s driving the work.
At this point, adding more engineers doesn’t just fail to improve output, it risks dragging the entire system down.
The Ideal vs. the Real: Onboarding Isn’t Free
In economic theory, marginal return is clean and immediate. But in practice, software teams deal with onboarding costs: new hires don’t contribute at full speed, and mentors lose productivity in the process.
Let’s compare the idealized model with a more realistic one that accounts for onboarding friction. While the numbers in our tables are theoretical, studies like this PLOS One research have shown that the pattern holds in practice: as team size grows, individual contribution and overall efficiency begin to decline, especially when coordination and ownership are poorly managed.
Idealized Marginal Return (No Onboarding Cost)
Realistic Marginal Return: Onboarding 2 Engineers Together
(Starting from a 4-engineer team at full productivity)
Why This Matters
In theory, more engineers should mean more output. In practice, onboarding creates a short-term dip in productivity, and the payoff only comes if your team is set up to absorb the growth. That means clear ownership, strong mentorship, scalable systems, and enough slack to support learning and integration.
By modeling the dip and planning for the recovery, leaders can make more honest, data-informed decisions about hiring and avoid the all-too-common disappointment when output doesn’t spike right after headcount does.
How to Measure It in Practice
Leaders often look at headcount and throughput, but the secret is in the marginal metrics.
Marginal throughput
= (New throughput − Previous throughput) ÷ Engineers added
→ Is each hire still adding real output?
Cost per unit of throughput
= Total engineering cost ÷ Delivered features/impact
→ Are you spending more per feature after hiring?
Flow metrics
Cycle time, PR review wait time, lead time, deploy frequency, change failure rate
→ If headcount goes up and these go down… your curve is bending.
How to Delay Diminishing Returns
Diminishing returns in engineering teams are predictable, but they’re not inevitable. You can delay their onset and soften their impact by designing your team and systems for scale.
That means addressing the very forces that cause the curve to flatten: rising coordination overhead, senior engineers pulled into full-time mentoring, work that can’t be parallelized, unclear ownership, slipping quality, and upstream bottlenecks in product and design. These patterns don’t fix themselves. But with the right choices, you can push the curve further to the right, getting more value from each additional hire, for longer.
Define Clear Team Boundaries and Ownership
Modular architecture, bounded contexts, and stable teams reduce cross-team dependencies and decision overhead. When a team owns a clearly scoped area, coordination becomes manageable, and accountability stays high.
Scale by Teams, Not Just Headcount
Instead of growing one team beyond the point of smooth coordination, create more small, independent teams with minimal overlap. In practice, teams of 4–8 engineers tend to strike the best balance between agility and capacity. This limits the communication surface area and helps each team stay fast, focused, and accountable for outcomes.
Tighten Feedback Loops
The faster engineers get feedback, the less time they spend blocked or reworking. This includes rapid code reviews, reliable automated testing, short-lived branches, and fast, confident deployments. Invest in this foundation (CI/CD pipelines, test coverage, release tooling, workflow processes) before you grow the team, not after.
Balance Functional Roles
Hiring engineers alone doesn’t scale delivery. You also need product managers, designers, QA, platform engineers, and SREs to keep work moving and quality high. The more cross-functional your teams are, the less drag from misalignment, missing scope, or weak validation loops.
Keep Scope Small and Flow Continuous
Avoid large, ambiguous bodies of work. Prefer small batches with sharp acceptance criteria and clear priorities. Limit work in progress, and encourage steady, single-piece flow. Pairing and mobbing can help teams move faster together while reducing rework and coordination gaps.
Default to Async and Lightweight Rituals
More people doesn’t mean more meetings. Use documentation, decision logs, and written updates to reduce the burden of coordination. Keep sync time reserved for what truly requires live discussion. This protects focus time and reduces the coordination tax across the team.
It’s Not Just About Headcount—It’s About System Design
The economy of software production doesn’t obey linear rules. Add too many people too fast, and things slow down, not speed up. But if you invest in modular systems, fast feedback, and well-balanced teams, you can delay that tipping point and keep adding value longer. As a leader, your job isn’t just to hire. It’s to build a system where hiring still works.
CHIME IN!
Where did your team hit the wall on marginal returns? And what helped you push the curve back up? Drop a comment or DM. I’d love to hear how others have tackled this.
References
Economics Help. (n.d.). The law of diminishing marginal returns. https://www.economicshelp.org/microessays/costs/diminishing-returns
Explains how increasing one input while keeping others fixed eventually leads to smaller marginal gains. A foundational concept in classical economics.
Wikipedia contributors. (2023, September 18). Ringelmann effect. Wikipedia. https://en.wikipedia.org/wiki/Ringelmann_effect
Describes how individual effort tends to decrease as group size increases, due to diffusion of responsibility and coordination loss.
Brooks, F. P. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley. https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf
A classic software engineering text introducing “Brooks’ Law,” which states that adding manpower to a late software project often delays it further due to onboarding and communication overhead.
Almaatouq, A., Yin, M., Alotaibi, A., Becker, J., & Watts, D. J. (2016). Team size and performance on a complex task. PLOS ONE, 11(11), e0153048. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0153048
An empirical study showing that as team size increases, coordination costs rise and performance efficiency per person declines—even on well-scoped tasks.
Comments