Platform teams that don't get resented

Most internal platform teams end up resented by the engineers they serve. The pattern is consistent enough that the causes are identifiable.

the failure pattern#

1. Platform team forms to reduce duplicated infrastructure work.
2. They build an abstraction over the cloud provider.
3. The abstraction covers 80% of cases well.
4. The remaining 20% is impossible, and the escape hatch is either absent or punished.
5. Product teams work around the platform.
6. Platform team responds by mandating the platform.
7. Everyone is unhappy and the platform is now a tax.

Every step follows from the previous one. The root is step four.

the four properties of platforms that work#

1. An escape hatch that is not punished.

The platform covers the common case. It cannot cover every case, and pretending otherwise is what breaks trust.

There must be a supported path for "I need something the platform does not do," and taking that path must not require an exception process, a meeting, or an apologetic Slack message.

The best platforms make the escape hatch cheap and then compete on being better than it. The worst make it forbidden, which does not eliminate the need — it drives it underground.

2. Adoption is voluntary, at least at first.

A platform that teams choose is a platform that is good. A platform teams are required to use never gets the feedback that would make it good, because the feedback mechanism — people leaving — has been disabled.

If you cannot get voluntary adoption, that is information. Mandating it does not fix the underlying problem; it hides it and converts a product problem into a political one.

Mandate later, when it is genuinely better, and the mandate will be uncontroversial because everyone already uses it.

3. The abstraction leaks deliberately, not accidentally.

Every abstraction leaks. The question is whether you planned for it.

A good platform lets you drop a level when you need to: use the paved path for the deployment, and reach the underlying resource directly when you need something specific. A bad one hides the underlying system entirely, so that when it fails you cannot debug it and neither can the platform team, because now there are two systems to understand.

Concretely: if your platform generates infrastructure configuration, let people see it. If it wraps a cloud API, let people access the underlying resource. If it runs their container, give them the logs from the actual runtime, not a filtered view.

4. The platform team is measured on adoption and satisfaction, not on compliance.

If the platform team's metric is "percentage of services on the platform," they will optimize for mandating it.

If the metric is "would you use this if you had a choice," they will optimize for making it good.

Ask that question quarterly, anonymously, and publish the answer.

the specific things that generate resentment#

Slow escape. A team needs something the platform does not support. The answer is "file a request, we will look at it next quarter." Their deadline is Friday.

Breaking changes without migration paths. The platform is infrastructure. Break it and every team stops. Platform teams frequently hold themselves to a lower compatibility standard than they would accept from a vendor.

Opaque failures. The deploy failed. The error is a platform-internal message. The product engineer cannot debug it and must escalate, which means waiting.

Being a gate rather than a service. A platform that must approve things is a bureaucracy. A platform that makes the right thing easy is infrastructure.

Solving the platform team's problems. Standardization is valuable to the platform team and is not automatically valuable to product teams. If the pitch for a migration is "this makes our lives easier," expect a cool reception.

the framing that works#

You are building a product. Your users are engineers. They have alternatives.

That framing produces the right behaviors automatically: user research before building, documentation that assumes nothing, onboarding that works, support that responds, and a roadmap driven by what users need rather than by architectural preference.

The platform teams I have seen work best behave exactly like a startup selling to a skeptical market, and they say so out loud.

The ones that fail behave like an internal standards body, and they are usually correct about the standards and wrong about how to get them adopted.

the measurement that matters#

Time from "a new engineer joins" to "their code is running in production."

That single number captures most of what a platform is for, it is measurable, and it is the thing product teams actually care about. If it is going down, the platform is working, regardless of what the adoption dashboard says.