In growing organisations, developers start spending an increasing share of their time on problems that have nothing to do with the product: fragile pipelines, inconsistent environments, releases that demand esoteric knowledge. The instinctive response is to set up a "platform team" to take care of all of it.
Often that's the wrong answer. A dedicated platform team risks becoming the new bottleneck: the old infrastructure team with a more modern name. Product teams stay dependent, requests pile up in a queue, and the autonomy everyone wanted ends up as just one more dependency to manage.
Platform engineering, when it works, isn't a team: it's a set of shared practices and tools that let every team release independently.
The platform team anti-pattern
The story is a familiar one. The organisation grows, infrastructure problems multiply, and someone suggests setting up a dedicated team. The platform team is born with good intentions: standardise, automate, simplify. Within a few months, though, a predictable pattern sets in:
- Product teams stop looking after shared tools because "there's a platform team for that"
- Every request goes through the platform team, which turns into a bottleneck
- The platform team's priorities stop matching those of the product teams
- Infrastructure knowledge ends up with a handful of people; the rest of the organisation loses the know-how
- When the platform team is overloaded, product teams wait
The result is paradoxical: a team was created to provide autonomy, and what came out of it was a new dependency. It's the same mechanism behind dependencies between teams: every point of centralisation becomes a point of slowdown.
The platform as a practice, not a team
The alternative is to think of the platform not as a team that builds tools for everyone else, but as a set of shared practices that every team knows, uses, and helps evolve.
In practice:
- The CI/CD pipeline is everyone's responsibility: every team knows how it works, can adapt it to its own needs and contributes improvements. It isn't a black box run by a separate team. When CI/CD is done properly, every developer understands it and owns it.
- Infrastructure as code lives in everyone's repository: environments are defined in code, versioned, reproducible. Every team can create, change and tear down its own environments without asking anyone's permission.
- Observability is a shared skill: there's no team monitoring on everyone else's behalf. Every team knows how to read its own logs, metrics and alerts. Debugging is a skill for everyone, not just for a handful of specialists.
- Golden paths emerge from the bottom up: good practices get shared between teams, not imposed from above. When a team solves a problem effectively, that solution becomes the new standard. Not by decree, but because other teams choose to adopt it.
If only one team knows how to release to production, you don't have a platform: you have a dependency.
When centralising makes sense
That doesn't mean a dedicated platform role is always wrong. Past a certain scale (30–40 developers), infrastructure complexity can justify dedicated people. The difference lies in the mandate.
A platform team that works operates as an enabling team: it works alongside product teams, transfers skills, and builds tools that others then own. It doesn't own the infrastructure; it enables others to own it.
Signs that centralising is working:
- Product teams release faster than before, independently
- Requests to the platform team decrease over time as teams become self-sufficient
- Infrastructure knowledge is distributed: if the platform team goes on holiday, nothing grinds to a halt
Signs it's turning into an anti-pattern:
- Requests to the platform team increase over time
- Product teams have stopped understanding how the pipeline and infrastructure work
- The platform team has a backlog of weeks, and everyone is waiting
The impact on the business
Done well, platform engineering has a multiplier effect: every improvement to the platform pays off once for every team that benefits from it. A pipeline that's 5 minutes faster, multiplied by 10 releases a day across 5 teams, adds up to a significant saving every week.
The metrics that matter aren't technical; they're business metrics:
- Time from commit to production: this is the most direct measure of how effective the platform is. If it falls, the platform is working.
- Onboarding time: how long does it take a new developer to ship their first release? An effective platform cuts this from weeks to days.
- Share of time spent on infrastructure problems: if teams are spending 30% of their time on tooling and infrastructure, something's wrong. The target is under 10%.
What to do in practice
Three steps to get started without creating a dedicated team.
In organisations we support through Embedded Teams, the centralised platform team almost always comes from a real frustration: every team has its own pipeline, its own way of deploying, its own environment setup. The obvious answer is to centralise. The result, almost without exception, is a new bottleneck: every infrastructure request becomes a ticket stuck in a queue. What works, in our experience, is building self-service tools so good that teams don't need to ask. The difference isn't technical: it's a question of who serves whom.
- Make the pipeline understandable to everyone: if only two people in the organisation know how the pipeline works, that's a risk. Document it, simplify it, and make sure every developer can read it, understand it and change it.
- Standardise a golden path: pick the operation every team does differently (spinning up an environment, configuring monitoring, releasing a new service) and define a standard route through it. Not imposed from above; built together with the teams and adopted because it works.
- Measure the time lost: for one week, track how much time each team spends on tooling, pipeline and environment problems. If it's above 20%, platform practices are the best investment you can make.
The platform isn't an infrastructure project: it's an investment in the organisation's autonomy. Every skill transferred to the teams is one less dependency. Every shared tool that everyone knows how to use is one bottleneck removed.
If your organisation has grown and teams can no longer release on their own, platform practices get built by working alongside the teams: it's exactly the kind of skills transfer we do through Embedded Teams.