The standard way to talk about a dev team is as a number. Four engineers. Ten engineers. A founder will tell you they're "scaling the team to twelve" the way you'd talk about adding lanes to a highway, as if throughput were a function of seats filled. The number is the thing everyone negotiates, budgets, and brags about. It is also the least informative fact about whether your software will ever ship.
Here is the figure that actually decides outcomes and that almost nobody puts on the slide: developer turnover in this industry runs north of 20% a year. That means the average team replaces roughly a fifth of itself annually — and with each person who walks, the undocumented reasons behind a thousand decisions walk too. Then the same team stares at a velocity chart that has flatlined and concludes it needs to hire more people. It has the diagnosis exactly backwards.
The narrative: a dev team is a resource you dial up and down
The conventional story treats a dev team as fungible capacity. Need to go faster? Add developers. Need to cut burn? Drop a couple, you'll "absorb it." Staffing marketplaces sell exactly this fantasy: engineers as interchangeable units of compute you can provision like cloud instances. The whole vocabulary — "resources," "seats," "ramping up," "head count" — is the vocabulary of a commodity. It is a comfortable story because it makes software delivery sound like a procurement problem, and procurement problems can be solved with a purchase order.
It is also wrong, and it has been demonstrably wrong since 1975, when Fred Brooks wrote down the observation that bears his name: adding manpower to a late software project makes it later. The reason is not motivational. A new engineer is not a fresh unit of velocity. They are a net drain for weeks or months — someone has to explain the architecture, the deploy quirks, the client's three sacred edge cases, the reason that one service is never, ever touched on a Friday. Every person you add forces communication overhead onto the people who were already shipping. You don't pour in capacity; you tax the capacity you had.
What actually ships software is context, not capacity
A working dev team is not a pile of skills. It is a shared, mostly-unwritten model of a specific system: why the schema looks like that, which abstraction leaks, what broke last March, which client emails mean "drop everything." This is the asset. It does not live in the repo, the wiki, or the Jira board — those capture a fraction of it. It lives in people's heads, and it is rebuilt slowly, by doing the work, breaking things, and remembering. A senior engineer who has been on a codebase for three years is not 1.2x a new senior hire. On that system, they are something closer to irreplaceable, and the gap doesn't close for a long time.
Which is why turnover is the most expensive line item nobody books. When someone leaves, you don't just pay to recruit and onboard a replacement — the standard estimates of one-half to two times salary are the visible part. You pay the invisible tax: the months of reduced output while the new person ramps, the decisions that get re-litigated because the person who knew the reasoning is gone, the bug that takes a week instead of an hour because the institutional memory left in someone's resignation letter. Churn doesn't subtract a person. It subtracts the compounding.
The 10x engineer is a distraction from the real variable
The other favourite fiction is the rockstar. Hire the 10x engineer and the rest sorts itself out. Set aside that the original studies behind "10x" measured variance between individuals, not a class of mythical heroes you can recruit on demand. The deeper problem is that it points your attention at the wrong unit. A genuinely strong engineer who leaves in fourteen months hands you a brilliant codebase nobody else fully understands — which is not an asset, it's a liability with good test coverage. The variable that predicts whether a team ships consistently is not peak individual talent. It is how long the talent stays pointed at the same problem.
Staff augmentation, body shopping, and the churn you pay for on purpose
The logical endpoint of the headcount model is the staffing-agency dev team: bodies rented by the month, swapped when the contract renegotiates, optimised for billable utilisation rather than for knowing your system. This is sold as flexibility. What you actually buy is institutionalised amnesia — a team engineered to never accumulate the context that makes a team valuable, because the moment it does, the person carrying it rotates off to another account. You are paying a premium for the precise thing that destroys delivery. The dressed-up version has a name, "staff augmentation," and the honest version has an older one, "body shopping," and the difference between them is mostly the font on the invoice.
This is the part of the argument where I'm not theorising. We built EltexSoft, my software studio, on the opposite bet, and the numbers are the whole point of making it: turnover under 5% a year against that 20%-plus industry norm; of 50-plus engineers hired since 2015, only fifteen have left voluntarily; average engineer tenure around eight years; average client engagement around four. That last pair is not a coincidence. The clients stay roughly half as long as the engineers because the engineers staying is what makes staying with us worth a client's while — the same people are still on the same system, still carrying the context, year after year. With MyFlyRight we've been the engineering partner since 2016; the platform we built from scratch has since processed over a million claims. You do not get a decade-long partnership out of a rotating bench.
What a real dev team actually is
Strip away the headcount framing and a real dev team has three properties the org chart never shows. First, it retains: the people who carry the context are still there next quarter, so the context compounds instead of evaporating. Second, it shares context deliberately rather than hoarding it — at our shop every pull request is reviewed by at least one other senior engineer before it merges, which is partly about quality and just as much about making sure no single person is the only one who understands a corner of the system. Third, it owns the whole thing: the people writing the application code also own the deploys, instead of throwing it over a wall to a department that has never read the code. None of that is visible in "we have ten engineers."
How to actually judge a dev team — yours or one you're buying
Stop asking how many engineers and start asking how long. How long has this team existed in roughly its current shape? What's its annual turnover — and if the honest answer is "the industry average," understand you're buying a team that resets a fifth of its memory every year. If you're hiring a studio or an agency, ask whether you get the same people month after month or a roster that rotates with their utilisation targets, and treat a vague answer as a no. The right question is never "can you scale up?" Anyone can throw warm bodies at a problem. The question is "will the people who learn my system still be here in three years?"
So take the position plainly: a dev team is not a headcount, and treating it as one is the most common, most expensive mistake in software. The number on the org chart is a vanity metric. The asset is the accumulated, mostly-undocumented understanding of a specific system, and that asset is created by people staying and destroyed by people leaving. Optimise for retention and continuity and the velocity follows. Optimise for headcount and flexibility and you will spend years discovering, expensively, that you bought a team designed to forget.
Last updated June 29, 2026