Platform teams fail for organisational reasons

Britain’s best documented internal platform was closed while it was working.

GOV.UK PaaS was set up in 2015 so that public sector organisations could host digital services without having to think about infrastructure. By the time the Government Digital Service announced its end, it was carrying 172 digital services for more than 60 departments, agencies and local authorities, with 99.95% uptime and only one major incident in its seven years. Across some 3,200 applications, teams were deploying through it more than 122 times a day.

On 12 July 2022, Tom Read and Clara Barnett wrote the post explaining why it would be decommissioned over the following eighteen months. The reasons they gave were that the large cloud providers had upped their game and reduced the barriers to entry for digital teams, that departments had built their own cloud engineering capability, and that the platform had not seen the rapid and continued growth achieved by some of their other platform products. Then the fourth reason, which is the one that decided it. They faced a choice, in their words, either to invest heavily in some significant technical architecture changes or to make the difficult decision to sunset the product, and they took the second.

Read those four together. Three are about the world around the platform rather than the platform. The fourth is about the platform, and even that is a statement about the size of the next bill rather than about whether the thing worked, because the reliability record was better than most commercial services publish and the platform was in use. What settled it was that the cost of the next phase had to be justified by adoption, and adoption had not grown. That is a judgement about demand with an engineering invoice attached to it, which is a more uncomfortable finding than a clean verdict either way.

That is the finding this whole subject turns on. A platform’s viability is decided by adoption, and adoption is an organisational variable that platform engineers do not control and are rarely asked to measure.

The word doing the work is compelling

The definitional literature is clearer about this than most practitioners are. Team Topologies describes a platform team as one providing a compelling internal product to accelerate delivery by stream-aligned teams, interacting with them mostly through an X-as-a-Service mode, and recommends building the thinnest viable platform rather than the most complete one.

Compelling is not decorative. It presupposes that the consuming team could choose otherwise and chose this. An internal product that teams are obliged to use cannot be compelling, because the word has no meaning where there is no alternative, and the platform loses the only honest signal available to it.

This is where most platform initiatives go wrong, and the mistake is usually made by well-intentioned people trying to protect the investment. Adoption is slow, so use is mandated. Mandating produces a rising adoption chart and destroys the feedback loop that would have told anyone whether the platform was any good. From that point the platform team is measured on uptake it cannot lose and receives complaints it cannot distinguish from ordinary friction, so it optimises for whatever leadership asks about, which is usually cost.

DORA’s research points the same way from the other side. Its work on platform engineering found that developer independence produced a measurable improvement in productivity at both the team and individual level, and that platforms can lead to a decrease in throughput and change stability if they are not carefully managed. A platform that inserts itself into every path, without letting teams route around it, is exactly the configuration in which that risk materialises.

Three funding models, three predictable failures

Nobody discusses the funding model at a platform engineering conference and it determines more outcomes than the technology stack.

Central cost centre. The platform is funded from a corporate budget and provided free at the point of use. Adoption is easy and demand is unbounded, because nothing a consuming team asks for costs that team anything. The platform accumulates bespoke requests until it is a bespoke system with a platform’s name, and the first serious cost review cannot show a return because no consumer ever gave up any budget to fund it.

Full chargeback. Teams pay for what they consume. Costs become visible, demand becomes disciplined, and two new problems appear. The platform now competes on price with a public cloud account that a determined team can open with a corporate card, and it acquires an incentive to grow consumption rather than to reduce it, which is the opposite of what an internal platform is for.

Tax. Every product team contributes a fixed share regardless of use. Predictable, and it produces the worst politics of the three, because teams that use the platform lightly are visibly subsidising teams that use it heavily and they say so at every budget round.

There is no correct answer, which is precisely why the choice should be made deliberately and reviewed. Most organisations arrive at one by accident, usually the first, and then wonder why the platform’s roadmap looks like a list of favours.

The platform has no product manager

The most common structural defect is simpler than any of the above. The platform team has a lead engineer, a backlog and a set of consumers, and no one whose job is to decide what it will not do.

The consequence is a platform that says yes. Every stream-aligned team asks for the one thing that would make its migration easier, each request is individually reasonable, and the aggregate is an interface with forty options, a document set nobody maintains and defaults that no longer suit anybody. The thinnest viable platform is not an engineering discipline. It is a refusal discipline, and refusal requires someone with standing to disappoint an internal customer, which is the argument set out in product management, in about three minutes.

The corollary is that platform teams need the boring product apparatus that consumer-facing teams take for granted. A statement of who the platform is for. A written position on what it will never support. A deprecation policy with dates, published in advance, that the team actually honours, because a platform that never removes anything eventually spends all of its capacity on compatibility.

What the platform’s product actually is

Platform engineers tend to describe their product as infrastructure. It is not. The infrastructure is bought, and the difference between a platform team and a bill from a cloud provider lies almost entirely in three things that are not infrastructure at all.

The interface, meaning the path a developer takes to get something running, and how many decisions they are required to make that have no bearing on their service. The defaults, meaning what happens to logging, secrets, network policy, backups and alerting when a team does nothing special, because defaults are how a platform delivers security and reliability without holding a meeting about it. And the documentation, which is the actual user interface for most consumers most of the time.

A useful diagnostic: measure the elapsed time from a new engineer’s first day to their first change reaching production, and find out how much of that time was spent waiting for a human. Platforms are sold on that number and rarely measured on it.

Government’s own guidance approaches team composition from the same direction, requiring a multidisciplinary team with a range of skills, sustained into the live phase rather than assembled for a build and dispersed at launch. Platform teams are commonly staffed the other way round, generously during the build and thinly afterwards, at which point the documentation ages, the defaults drift from current practice, and consuming teams quietly start building their own arrangements again.

The variable that got sharper

One recent DORA finding deserves separate attention from anyone weighing platform investment against something more fashionable. Its research reports that platform quality conditions the return on adopting artificial intelligence: where platform quality is high, the effect of AI adoption on organisational performance is strong and positive, and where it is low, the effect is negligible.

If that relationship holds, it reframes a budget argument that has been running in most large organisations for two years. Platform work is usually the thing deferred to fund the AI programme. The research suggests the deferral removes the conditions under which the AI programme could pay for itself, which is an uncomfortable sequencing point for a technology function that has already committed to a delivery date.

What to measure instead of adoption

Three numbers are more informative than an uptake percentage, and all three are obtainable.

The proportion of teams that use the platform and could leave it within a quarter. If that figure is near zero, uptake is telling you about lock-in, not value.

The time from a new service’s first commit to its first production deployment, tracked over time. This is the platform’s core promise expressed as a duration.

And the share of platform team capacity spent on bespoke requests for individual consumers. Above roughly a quarter, the team has stopped building a product and started operating a service desk, which is a legitimate thing to be, but should be a decision rather than a drift.

The costs that platform work is meant to contain sit mostly in consumption billing now, which is covered at consumption pricing and who carries the forecast. Related infrastructure coverage is under cloud and infrastructure, and this desk’s wider work is at SaaS and enterprise software.