Every Mid-Size Engineering Org Has a Hidden Backend Platform Team. It's Called "Senior Engineers Doing Repetitive Work."
You don't decide whether to have a platform team. You decide whether it's intentional.
The decision already made
The same hour, spent four times, in front of the same audience, looks like four hours of productivity.
Sprint review, Friday afternoon:
Squad 1 demos a wrapper around the HTTP client to standardize timeouts. Clean work, well-named, ships next sprint.
Squad 2 demos a slightly different wrapper, same client library, same problem space, different defaults around retries.
Squad 4 demos an audit-logging helper that almost matches the format the platform-adjacent squad rolled out last quarter.
Squad 6 isn’t demoing platform work at all. They’re shipping a feature, on time, on the back of three engineers who built their own version of the same scaffolding two sprints ago.
The work is real. The work ships. It just ships four times.
The EM running the review nods through all four demos. He’s been the EM for fourteen months. He has not yet noticed that three of the four demos are the same demo.
Neither has anyone in the room. The squad leads aren’t withholding it; they genuinely don’t know what the other squads built. There is no forum where they would have found out.
This is the hidden platform team. It’s called “senior engineers doing repetitive work.”
Nobody in that room would call this a platform investment. It is one.
The decision to not have a platform team has already been made. It was made invisibly, the moment the third senior engineer reached for a problem the first two had already solved. Nobody voted on it. Nobody costed it. It is already on the books. The only thing missing is the line item. And what I’ve seen, again and again, is that the line item never gets added until someone names what’s there.
Where the velocity went
Your headcount has doubled. Your velocity hasn’t. You are hunting for the explanation in the wrong places.
There are several candidates for that gap, and the honest version of this issue acknowledges all of them up front. Sprint planning discipline. Feature-side technical debt. On-call fatigue. Communication overhead from team growth. Hiring quality. Most engineering orgs at this scale have several of these problems running simultaneously, and none of them are wrong. None of them are the only answer either. This issue is about one specific structural cost that almost always sits inside the velocity drop, often unnamed, and almost never on a budget line.
The cost has a shape. Above a certain size — roughly the band where you have four or more product squads — the unnamed cross-cutting work stops being amortized and starts being multiplied. Each squad solves the same coordination problem in isolation, with subtly different conventions, on subtly different timelines. The HTTP client. The retry policy. The audit log shape. The error response envelope. The structured-logging fields. The tracing headers. Six squads, six versions, all roughly correct, none identical.
You’re three years past your last platform conversation. Your headcount has doubled. Your velocity hasn’t. When someone proposes a platform team, the answer in the room is some version of “we’re not big enough yet, and we don’t want to add overhead.” Your senior engineers nod. They’re the ones absorbing the cost.
The redistributed model has a real defense. It deserves to be taken seriously before it gets dismantled.
The defense worth taking seriously
Here is the position to beat. Distribute cross-cutting work across the product squads. Engineers closest to the problem solve it. Don’t form a platform team until the cooperation model is visibly broken. Anything else is premature optimization.
A smart engineer reaches for that position for four good reasons.
It is defensible by experience. Below a certain scale — somewhere in the 20-engineer band — cooperation works without formal coordination, and forming a platform team there creates a ticket queue and makes the rest of the org passive. The right answer at that scale is not to build a platform team. Anyone who has watched a too-early platform team form has seen this fail.
It is defensible economically. A dedicated platform team is real headcount. A redistributed model adds zero. From a CFO seat, “let the engineers self-organize” is the default that doesn’t require a budget conversation, and the default usually wins.
It is defensible ideologically. The position that platform teams fail when they become ticket-driven infrastructure providers is correct, and any engineer who has read this topic for two years has internalized it. The federated, distributed-ownership model has real virtues. Under a manageable number of services, informal coordination genuinely works.
It is defensible psychologically. “Everyone pitches in” is a culture statement most leaders are proud of. Naming the work as platform work feels like admitting the org isn’t lean anymore.
In the rooms where I’ve watched this argument made, it’s always made well. The defense is real. It is also wrong above the threshold, in a way the smart engineer reaching for it has not yet noticed.
The defense conflates internal coordination within a squad with coordination across squads. The federated model handles the first cleanly. It compounds cost on the second.
“Premature optimization” is the wrong frame past the threshold. Below the band, yes — building a platform team there is a textbook over-rotation. Past it, the redistributed work is no longer optimization. It is accumulated debt being repaid, in installments, by the most expensive engineers in the org.
The federated argument also assumes information symmetry the org no longer has. Once you cross the threshold, no senior engineer can hold the state of what every other squad has already built. Squad 4 doesn’t know Squad 2 wrote the audit-logging helper last quarter. They write it again. The cost is the second writing.
Which leaves the structural question the redistributed model can’t answer at this scale: who is responsible for the second writing of the same code? The squad? The senior engineer? The org? The model has no answer because the model has no owner — and the cost lands wherever the answer would have been.
Three approaches, and the pattern
Three approaches are on the table for an org at this scale. Each has a real case. Only one has a pattern that holds up over time.
Approach A: The redistributed model (status quo)
Cross-cutting work is distributed across product squads. There is no formal platform charter. The senior engineer who cares most absorbs the cost. The advantages are real: zero new headcount, no team-formation tax, no bottleneck risk by construction. The disadvantages are also real, and they are the ones leaders have most trouble seeing. Cross-cutting decisions get made N times — once per squad — and converge only by accident or by a single heroic refactor. Quality drift is structural. Onboarding compounds.
One caveat deserves to land cleanly. Some orgs do achieve high platform quality through a federated ownership model — open-source-style internal contribution, strong RFC culture, well-curated shared libraries. The federated path to high platform quality is real, and where it works it is beautiful. It also requires a level of internal-tooling cultural maturity most orgs at this scale do not have. The argument here is about the median org, not every possible org.
Approach B: The virtual platform team
A few senior engineers are designated to spend a fixed fraction of their time on shared infra. No dedicated team. No separate roadmap. No new headcount line. Preserves the “everyone pitches in” culture. Lower political friction.
This approach has one consistent failure mode and you can predict it from the structure alone. Priority collisions are guaranteed — and when feature deadlines slip, the platform allocation is the first thing dropped. There is no continuous improvement because there is no continuous owner. The allocation trends toward zero within two to three quarters under sustained feature pressure, because there is nobody whose performance review depends on defending the platform work. As a transitional state for one or two quarters while a real team is being scoped, the virtual model has a job. As a steady state, it does not.
Approach C: The funded MVP platform team
Two or three engineers, dedicated, with an explicit charter, a roadmap, and kill-criteria, treated as an internal product team. Explicit ownership. Continuous improvement. The cost is now a budget line you can manage.
The cost is real. So is the risk of doing this badly. A significant fraction of platform teams fail to deliver measurable productivity gains, and the failure mode is consistent: over-staffed, over-scoped, and trending toward becoming the ticket queue the model warns against.
Then there is the pattern.
I’ve watched the redistributed model run for two years in orgs at this scale. The cost is consistent. It is several times what a funded MVP team would have cost, and the gap widens with each quarter the work stays unnamed. The redistributed cost isn’t proportional to headcount in the way most leaders intuitively expect — it compounds, because the second writing of the same code is the first installment of a longer payment plan, and the third writing is the second installment, and the cost arrives in disguise as slowed onboarding, missed deadlines, and senior-engineer attrition that nobody connects back to the source.
The gap is also widening, not narrowing, in the orgs I’ve watched recently. AI tooling amplifies whatever organizational system it inhabits. Where the platform foundation is intentional, AI compounds the gains. Where the foundation is fragmented, AI compounds the dysfunction — fragmented patterns get fragmented faster, drift accelerates, cleanup cost compounds.
The redistributed model was expensive two years ago. It is structurally more expensive now. It will be worse next year.
What I’d fund
So here is the position, no hedging.
Past the threshold where you have four or more product squads and the cross-cutting work is visibly fragmenting, fund a two-to-three-person platform team within two quarters. Not eight. Not zero. Two to three engineers, named charter, two-quarter prove-value runway, explicit kill-criteria.
The kill-criteria are what make the bet reversible. If, after two quarters, no measurable adoption metric has moved — golden-path uptake, onboarding-time delta, deduplication of named cross-cutting work — dissolve the team and revert to the federated model.
The two-engineer floor is small enough to make this reversible. Most platform teams that fail are over-staffed and politically irreversible by the third quarter. A two-person MVP can’t lock you in. The constraint is the feature.
On the threshold: I’m committing to the four-or-more-squads frame because that is the point where the redistributed cost first becomes irreversible, not the point where the argument is unambiguous. The argument gets unambiguous later, somewhere around eighty engineers. Below the band, the federated model genuinely works. Inside the band, leaders who wait for unambiguous evidence have already paid a year of redistributed cost they cannot recover.
The argument doesn’t survive serious scrutiny in the other direction. The redistributed cost runs several times the MVP team cost within a quarter at this scale, compounding.
The failure-rate caveat — that most platform teams don’t deliver measurable productivity gains — is real, and the answer is scope discipline, not don’t form the team. Most platform teams that fail are over-scoped, over-staffed, and become the ticket queue the model warns against. A two-or-three-person MVP cannot become a ticket queue. There isn’t enough team to absorb the requests. The constraint forces product discipline.
The political cost I’d accept: forming the team will hurt. Two of your most senior engineers will resist — the cross-cutting decisions are what they’re proudest of, and naming the work as platform work feels like a demotion of their most interesting problems. Their squads will complain. There will be a quarter of trust deficit while the new team finds its footing. Existing implementations will need migration paths, not just new patterns. None of this is free. The argument survives all of it.
I’ve watched this play out in other orgs at this scale, and the variable is never whether the redistributed cost is real. It’s only whether anyone says it out loud.
The pattern beyond platform
Zoom out from platform engineering. Every engineering org has work that does not fit on a sprint board. Cross-service consistency. Compliance review prep. Audit log standardization. Onboarding documentation. Retry semantics. Error response shape. The standard observability footprint. None of this work belongs to a single product squad. All of it gets done — by someone, at some cost — whether the work is named or not.
That is the principle this case reveals.
Unnamed work doesn’t disappear; it gets redistributed. And redistributed cost has a specific operational property: you can’t measure it, you can’t optimize it, and you can’t reduce it — because it isn’t on a budget line anyone is reading. The work shows up in slipped deadlines, in onboarding times that crept from a couple of weeks to several, in a senior engineer’s calendar that’s somehow always full of “infra cleanup” they didn’t plan for. Every one of those signals is the cost arriving in disguise. The signal is not “we need a platform team.” The signal is “nobody owns this, and the org has stopped noticing.”
This pattern repeats outside platform engineering. It is the structural shape of every “we don’t need a dedicated team for that, our engineers self-organize” answer past the threshold where it actually works. Security review past a certain scale. Data quality past a certain number of product domains. Internal documentation past a certain service count. Each one starts as a thing the smart engineers absorb out of professional pride. Each one stops being absorbable at a different threshold, and most leaders cross that threshold without noticing.
Every time I’ve watched an engineering leader try to read this signal, the misread is the same: accumulation gets misread as growth. The threshold is rarely respected because crossing it isn’t a discrete event — it is an accumulation. The leader who learns to read accumulation as cost, not as growth, is the one who saves their org six months of redistributed work.
The question worth carrying
Redistributed cost is still cost. You’re paying it. You’re just not seeing it on a budget line you can manage.
Here is the question worth carrying. Look at your last sprint review. How many of the things your senior engineers showed off were things three other senior engineers also did this quarter — and what is the time cost of that duplication? Don’t estimate. Actually count one example. The number you arrive at will be lower than the real number, and it will still be too big to ignore.
The harder question isn’t whether to fund the team. It is what to call the work once you’ve named it. “Platform” means several different things today, and most leadership conversations stall there — on the language, not the money.
For the EM reader without budget authority, there is a smaller version of the same conversation you can have this week without asking for headcount. Ask one senior engineer how many hours of their last sprint went to work no product squad asked for. Don’t push for a number. Just listen to the pause before they answer.
Over communication is key. I think if there is a culture of sharing idea first instead of implementation - lots of opportunities for healthy collaboration be happening.