On this page
A platform team is meant to be leverage.
You hire it once, pay it once, and it multiplies the output of every other engineer in the organisation. That is the business case. That is why the board signs off on it.
Sometimes it works. Sometimes the platform team becomes the opposite: a tax on every change, a bottleneck on every decision, a line item that costs more every quarter without producing more.
If you are an engineering leader and you cannot answer, in one sentence, what your platform team made possible last quarter that wasn’t possible the quarter before, the team is probably drifting from asset to tax.
What “Tax” Actually Looks Like
A platform team becomes a tax when the cost of having it grows faster than the value it produces.
That cost is not just salary. It is:
- Developer wait time spent queuing for the platform team to provision something, approve something, or debug something.
- Decision drag caused by inconsistent infrastructure: every architectural decision becomes a per-team conversation because there is no shared default.
- Risk overhead from a team that has become the single point of failure for changes nobody else understands.
- Opportunity cost from senior engineers who joined to build a platform and are now firefighting one.
The salary line is the smallest of these. A platform team of ten that costs fifty engineers four hours of waiting each week is, in real terms, a platform team of fifteen - and that ignores the slower decisions and lost senior attention that come with it.
When leaders evaluate platform investment, they usually look at the salary line. The salary line is the wrong number.
How Platform Teams Drift Into a Tax Position
Nobody decides to build a platform team that drags. It happens gradually, through a sequence of individually reasonable choices.
They keep saying yes
The first version of a platform team is small, helpful, and close to the developers. They say yes to everything because saying yes is how they build credibility. This works at small scale.
It stops working when the organisation grows. By the time the platform team is supporting fifty teams, every “yes” from earlier has become a permanent maintenance commitment. The team’s capacity is now divided across dozens of bespoke configurations, none of which they can deprecate without breaking someone.
They own outcomes they don’t control
Platform teams often inherit ownership of things they can’t actually change. Reliability of an application they didn’t write. Cost of workloads they don’t run. Security of a configuration the application team set.
This produces a team that is accountable for outcomes but not authorised to enforce the conditions that would produce them. They end up doing low-leverage cleanup work because that is the only work available to them.
They confuse busyness with value
A heavily loaded platform team feels productive. There is a queue. There is on-call. There is an incident channel that never stops moving.
But if the queue is full of tickets that should not exist - manual provisioning requests, repeated configuration questions, exception handling - the team is busy because the platform is broken, not because it is succeeding.
Leadership stops asking what it produces
Once a platform team exists, leadership tends to evaluate it on inputs (people, budget, tickets closed) rather than outputs (engineering throughput, time-to-production, infrastructure consistency). The team becomes load-bearing in the org chart. Nobody questions whether it should exist; they only question how to make it bigger.
This is the point at which the team has fully transitioned from asset to tax. The cost is institutionalised. The value is assumed.
Signs Your Platform Team Has Become a Tax
You can usually tell within a week of looking honestly:
- Ticket volume grows with headcount, not with capability. Each new engineer added to the team produces a roughly proportional increase in support load, suggesting the team’s job is mostly reactive.
- Routine developer workflows still require platform team involvement. Deploying a service, creating an environment, or rotating a credential should be self-service operations. If they are not, the platform team is the bottleneck on every change.
- The platform team owns multiple ways to do the same thing. Two deployment models. Three observability stacks. Four secret management approaches. Every duplicate is a permanent multiplier on operational cost.
- Senior platform engineers are leaving. The most expensive engineers in the team are the first to notice when their job has shifted from building leverage to maintaining drag. They leave for places where the work is still strategic.
- You can’t articulate the team’s last six months of impact. If the team’s most recent achievements are framed as “we kept things running” or “we managed an upgrade”, they are operating, not platforming.
- Cost per supported team is rising. As the organisation grows, the platform team’s cost per developer served should go down. If it is going up, the team’s leverage is decreasing.
Any one of these is a warning. Three of them together is a pattern, not bad luck.
What to Do When You Recognise the Pattern
The reflex when a team isn’t delivering value is to cut it or restructure it. With platform teams, both reactions usually make the problem worse.
The platform team is not the problem. The complexity the platform team is absorbing is the problem.
Reduce variance before reducing headcount
Every supported pattern, every legacy workflow, and every accepted exception is a permanent claim on the team’s capacity. Reclaiming that capacity is faster than hiring more people.
A useful exercise: list every supported deployment model, observability tool, and infrastructure pattern the platform team maintains. Rank them by usage. Most organisations find that 70% of their teams are using 20% of the patterns. The remaining patterns are consuming most of the platform team’s capacity.
Deprecating those patterns - with firm timelines and migration support - is the single highest-leverage action available to most platform leaders.
Move the team out of the critical path
If a platform team is required for routine developer operations, every one of those operations is a tax. The work to convert a manual workflow into a self-service one is usually small relative to the recurring cost of doing it manually forever.
The order of operations is: identify the most-requested workflows, automate them, then declare them off the platform team’s plate. The team’s job is to operate the automation, not the requests.
Give the team a product mandate
Platform teams that report to operational leaders tend to absorb operational work. Platform teams that report to engineering leadership and have an explicit product mandate tend to make strategic investments.
The mandate should include the authority to say no, the authority to deprecate, and a clear definition of what the platform is and is not responsible for.
Measure outputs, not inputs
Replace “tickets closed” with “developer workflows enabled without us.” Replace “incidents handled” with “incidents the platform now prevents structurally.” Replace “headcount” with “engineers served per platform engineer.”
These are uncomfortable measurements because they expose whether the team is producing leverage. That is precisely why they are the right measurements.
The Takeaway
The question to ask of any platform team is not “are they busy?” or “are they capable?” or “are they nice to work with?”. They are usually all three.
The question is: does the rest of engineering move faster because this team exists?
If yes, the team is an asset, and the right response is to protect it. If no, the team has become a tax, and the right response is not to cut it - it is to reduce the complexity it is being asked to absorb.
Most platform teams that look like they are failing are actually being failed by the operating conditions around them. Fix those, and the same team will produce leverage again.
If you are not sure where your platform team sits on that spectrum, we can help you work it out honestly.