The Platform Nobody Asked For

A platform team has customers, and its customers cannot go anywhere else. That is the whole problem, and almost everything that goes wrong afterward is a consequence of it rather than a separate mistake.

Consider what a product team ordinarily learns from. Somebody evaluates the thing and does not buy it, and if you ask why you get an answer. Somebody buys it and stops using it, and the usage curve tells you before the renewal does. Somebody picks a competitor and you can go and look at what the competitor did instead. Every one of those signals is generated by the customer's ability to walk away, and none survives a mandate. What you get instead is a compliance rate, which measures enforcement and says nothing about whether the platform is any good.

A paved road wins on cost to the person choosing. The test is narrow and it is not about the organization's cost. Is the platform path cheaper, in effort and elapsed time, for the specific engineer standing at the fork this week? If deploying through it takes an afternoon and rolling your own takes a fortnight, nobody needs to be told. If it takes a fortnight either way and one of them is mandatory, you have a policy and you should call it one.

A mandate removes the pressure that would have made it easier. This is the part that compounds. The platform team that has to win each adoption spends its time on the friction, because friction is what loses arguments. The team whose adoption is guaranteed has no such forcing function, and the backlog fills instead with the things the team finds interesting or that its own leadership asked for. The road stops getting paved on the day it stops needing to be chosen.

The good version makes compliance the lazy path. Where a control genuinely must be universal, and some must, the move is to put the control inside the easy path rather than to require the path. Secrets handling, provenance, audit logging: make the paved road the way you get those for free, and the compliant route becomes the route of least resistance. That is a mandate that never has to be announced, and it is the only kind I have seen hold.

A platform serving every business unit has to serve units whose constraints genuinely differ. One is regulated and needs an approval gate and an evidence trail before anything reaches production. One is latency-sensitive and cannot accept a proxy hop it did not ask for. One carries a legacy estate that does not containerize and will not be rewritten this decade because the rewrite has no business case. These are not preferences and they are not immaturity. They are correct local responses to different environments.

Build for all of them and the platform becomes a configuration layer. Everything it does is optional, everything optional has a flag, and the flags multiply until the real product is a large YAML file each team fills in differently. It saves nobody the hard part, because the hard part was always the specific decisions, and it adds the cost of learning a new way to express them. Skelton and Pais have a phrase for the good version of thin, the thinnest viable platform, and its point is that thin is a choice about scope, not the residue of accommodating everyone.

Build for one of them properly and you get something excellent that a large fraction of the organization is right to refuse. The regulated unit cannot use the fast path because the gate is not in it. The latency-sensitive unit is not being difficult. Their refusal is not a change management problem and treating it as one is how a platform team ends up in a two-year argument it cannot win, because the people on the other side are correct.

There is no architecture that dissolves this. Plugin models push the specificity down a level and reproduce the same choice inside each plugin. Tiered platforms are two platforms with a shared logo and twice the maintenance. What is available is a decision: name who the platform is for, say out loud who it is not for, and let the excluded units keep their own tooling without being treated as a compliance failure. That is not a resolution. It is choosing which horn to be impaled on, in public, which is the part organizations avoid.

A product with an indefinite life is funded as a project with an end date. The platform gets a budget, a scope, a delivery date and a program manager, because that is the machinery an organization has for authorizing work. Then it is delivered. Something is declared complete, the team is thanked, and the funding rolls off to the next initiative on the assumption that operating it is a rounding error, which it never is for anything with users.

The worst state is decaying and still mandatory. Staffed down does not mean removed. The platform is still the required path, still between every team and production, and now nobody owns the upgrade of its dependencies, the deprecation of its oldest interface or the diagnosis of its slow days. Every month it drifts further from what the teams using it now actually need, and every month the cost of leaving it rises. This state is extremely common and nobody ever decided to be in it.

There is one published data set worth arguing with here, and it cuts against the enthusiasm. The DORA report published in October 2024 found that internal developer platforms made people feel more productive, individuals by about 8 percent and teams by about 10 percent, with organizational performance up around 6 percent. It also found, in the same population, that throughput fell by roughly 8 percent and change stability by about 14 percent. More people shipping more comfortably, and less software actually getting through, at lower quality.

Take those numbers with their construction attached. It is a self-report survey of nearly three thousand professionals, recruited partly by snowball sampling through the authors' own channels with a supplementary panel to fill gaps, with respondents randomly assigned to one of three question flows, published by a cloud vendor that sells the components these platforms are built from. Perceived productivity and measured throughput are different instruments and the gap between them may be an artifact. It is still the most useful thing anyone has published on this, precisely because the result is one nobody wanted.

And one finding inside it is hard to explain away. Respondents who reported being required to use the platform exclusively for the whole application lifecycle showed a further decrease in throughput, on top of the general effect. That is the mandate, appearing as a number, in a survey run by people who were looking for a reason to be positive about platforms. It is the single strongest piece of evidence I know of that the compliance problem and the product problem are the same problem.

Conway was describing this in 1968. In Datamation, April 1968, Melvin Conway wrote that organizations which design systems "are constrained to produce designs which are copies of the communication structures of these organizations". A platform spanning business units is an attempt to build one system across several communication structures that do not connect. The law does not stop applying because the intent was good, and it predicts exactly what you get: a system with the seams of the org chart in it.

The unit with its own P&L will optimize for its own P&L. A business unit with its own targets, its own margin and its own board conversation is behaving correctly when it prioritizes its own delivery date over a shared roadmap. It is not being parochial. It is doing the job it is measured on, and no amount of architectural elegance changes the incentive. Any plan whose success requires four units to voluntarily deprioritize their own quarter is not a plan.

Count what duplication actually costs before dismissing the idea. Every business unit standing up its own deployment pipeline, its own secrets handling, its own base images, its own observability stack and its own answer to how a service gets a certificate. That is not five implementations of one thing. It is five upgrade backlogs, five sets of undocumented decisions, five different answers when a vulnerability lands, and five teams learning the same lessons in sequence. The organizations that got this right have a durable advantage that is very hard to catch.

So the failure is in governance and funding, not in the idea, and the piece would be wrong if it read as an argument against shared infrastructure. What I am arguing against is narrower: resolving a product problem by removing the customer's choice. That move looks like acceleration and is actually the destruction of the only feedback that could have made the platform worth choosing, and it is the single most common thing I have watched organizations do at exactly the moment adoption stalls.

The concession is that mandates sometimes work, and I should be specific about when. Where the thing mandated is genuinely uniform across every unit, and being the same is most of the value, a mandate is fine and the resentment is survivable. One identity provider. One certificate authority. One artifact registry with provenance attached. Nobody's competitive position depends on having their own. My claim covers the rest of the platform, the part where units differ for real reasons, and that is smaller than the claim I started with.

The diagnostic is one question and it needs no tooling. If the mandate were lifted tomorrow, how many teams would stay. Nobody wants to ask, because the answer is either that the platform is good, in which case the mandate was never doing any work, or that it is not, in which case the mandate is the only thing holding the product up. The organizations I would bet on already know their answer. The ones I would not are those where the number cannot even be estimated, because the question has never been allowed.