Almost every engineering org over 50 people has tried to create a "platform team." The pitch is compelling: instead of every team solving the same problems, we'll centralize that work in a dedicated team that builds great internal tools.
In practice, this rarely works. The platform team becomes a bottleneck, the tools they build don't match what teams actually need, and everyone ends up frustrated.
We've seen this pattern enough times to understand why it happens—and how to avoid it.
The Failure Mode
Here's the typical trajectory:
Month 1-3: The platform team is formed. They interview internal teams about their pain points and start building tools based on what they hear.
Month 4-6: The first tools launch. Adoption is lower than expected. Product teams say the tools don't quite fit their workflows, or they're missing critical features, or the documentation isn't clear enough.
Month 7-12: The platform team is now maintaining existing tools while trying to build new ones. Feature requests pile up faster than they can be addressed. Product teams start building workarounds.
Month 12+: The platform team is perpetually underwater. They're seen as a bottleneck rather than an accelerator. Leadership questions whether the team was a good investment.
Why This Happens
The core problem is organizational, not technical. Platform teams are expected to serve as a service provider to other engineering teams. But they don't have any of the mechanisms that make service providers work well.
They don't have competitive pressure. If the platform team builds a bad deployment tool, teams can't use a competitor—they're stuck with it. Without competition, there's no forcing function for quality.
They don't have pricing. When something is "free" (paid for by central budget), teams over-consume and under-prioritize. Every team wants their feature request addressed immediately, but no team has to make tradeoffs.
They don't have clear customers. The platform team serves "all engineering," but all engineering has conflicting needs. Features that help the web team might not help the mobile team. Features that help the growth team might actively hurt the infrastructure team.
What Works Instead
The platform teams that succeed do things differently.
First, they treat internal teams as customers with real power. This doesn't mean giving teams everything they want. It means giving them alternatives. If the internal deployment tool doesn't work for a team's needs, they can use something else. The platform team has to compete for adoption.
Second, they use some form of internal pricing. This doesn't have to be literal money. It can be allocation of engineering time. The point is that teams requesting features have to make tradeoffs, which surfaces what they actually need versus what would just be nice to have.
Third, they focus relentlessly on adoption metrics. Not "we launched X features this quarter." Not "we closed Y tickets." The question is: are product teams more productive because of us? If the answer isn't clearly yes, the platform team is failing regardless of how much they shipped.
A Concrete Example
One of our clients had a platform team building internal tools for about 18 months. Usage was stagnant. Product teams were increasingly building their own solutions.
We helped them restructure. The platform team stopped taking feature requests and started doing quarterly "roadshow" interviews with product teams. Not "what do you want us to build?" but "what are you building yourselves, and why?"
This surfaced the real problems. Teams weren't building their own solutions because the platform tools were missing features. They were building their own solutions because the platform tools were too slow to evolve. By the time a feature request was addressed, the team had already moved on.
The fix wasn't better tools. It was enabling teams to contribute to platform tools directly. The platform team's role shifted from "building everything" to "maintaining standards and helping teams contribute."
Adoption tripled in six months.
The Uncomfortable Implication
The best platform teams often produce less code than you'd expect. Their value isn't in what they build—it's in what they enable other teams to build.
This requires a mindset shift. Platform teams often justify their existence by pointing to features shipped. But the real measure is organizational leverage: for every hour the platform team spends, how many hours does the rest of engineering save?
If that ratio isn't at least 5:1, you're probably better off without a platform team.