The platform team trap: building internal products nobody asked for

I do not think platform teams are the enemy.

That matters, because it is easy to turn this argument into a cheap dismissal of every internal platform, every developer portal, every shared deployment service, and every team trying to make infrastructure less miserable. This is not that argument. Some organisations desperately need platform work. They have ten product teams solving secrets management ten different ways. They have build scripts copied from abandoned projects. They have cloud accounts that only one person understands. They have compliance checks performed through folklore. They have deployment paths that require a senior engineer, a Slack thread, and the quiet hope that nobody changed the load balancer since last Tuesday.

A good platform team can remove real pain. It can turn repeated toil into a paved path. It can make the right thing easier than the risky thing. It can give product teams enough stable ground that they spend more time on customers and less time rediscovering how to ship software.

The trap starts after that legitimate mission is approved.

Someone creates a platform team. The team writes a roadmap. The roadmap needs visible milestones. Visible milestones need artefacts. Artefacts need adoption. Adoption becomes a number. The number becomes a goal. Soon the team that was created to reduce friction is asking every other team to attend migration workshops, fill out intake forms, align to a platform governance model, and move work onto abstractions they did not request.

The platform is no longer there to help teams deliver. Teams are now there to prove the platform is working.

That is the platform team trap: the moment an internal enablement function becomes an internal product organisation whose primary customer is its own plan. The symptoms are familiar. The platform roadmap is more detailed than the user research. Success is measured by number of services onboarded, not by whether developers move faster with less confusion. Adoption is enforced through policy because the platform has not earned pull. A portal appears before the underlying workflows are worth centralising. Product teams are told the new path is self-service, then discover that every exception still requires a ticket.

The language sounds modern. The operating model is old. It is centralised IT with better branding and a React interface.

The mission is real

Platform teams became popular because the pain they address is real.

Matthew Skelton and Manuel Pais made platform teams one of the four fundamental team types in Team Topologies. The point was not to create a glamorous central engineering group. The point was to reduce the cognitive load on stream-aligned teams so those teams could deliver value with substantial autonomy.¹ In their 2019 discussion of team cognitive load, Skelton and Pais framed the platform as something that should keep product teams focused on business problems rather than forcing every team to carry the mental overhead of infrastructure mechanics.²

That is a serious idea. Cognitive load is not a metaphor for developers feeling annoyed. It is a constraint on what a team can safely understand, own, change, and operate. If every team must understand Kubernetes, network policy, audit logging, IAM, observability, CI configuration, incident escalation, dependency scanning, release orchestration, and the product domain at the same time, something will give. Often the thing that gives is quality. Sometimes it is delivery speed. Sometimes it is the engineer on call at 02:00 trying to remember which dashboard belongs to which half-migrated service.

The platform argument is that not all knowledge should be duplicated. Some knowledge should be turned into a service, a tool, a workflow, a template, a library, or a support model that lets delivery teams work with less accidental difficulty. Evan Bottcher's 2018 article on digital platforms describes an internal platform as a foundation of self-service APIs, tools, services, knowledge, and support arranged as a compelling internal product.³ The phrase matters less than the direction: self-service, useful foundations, and product teams moving with less coordination.

If that is what the platform team builds, it can be one of the healthiest investments an engineering organisation makes.

The best platform teams do not start with a portal. They start with observed repetition. Three teams are copying the same brittle deployment script. Five teams are solving certificate renewal badly. Every new service needs two weeks of coordination because account provisioning, DNS, monitoring, and CI are spread across different human queues. A senior engineer keeps answering the same questions because the organisation has never turned the answer into a capability.

That is platform work.

It is not a department name. It is not a job-title upgrade for operations. It is not a reason to move every infrastructure decision away from the people building the product. It is a way to remove non-differentiating friction from teams whose real work is somewhere else.

The distinction is important because the trap does not begin with bad intentions. It begins with a good pattern applied with organisational incentives that reward the wrong visible outputs.

Once a platform team exists, it must justify its existence. It needs a backlog, quarterly planning, leadership updates, stakeholder management, and adoption metrics. That machinery is not automatically harmful. Platforms do need product discipline. Puppet's 2023 State of DevOps platform engineering report makes that point directly: effective platform teams need user research, feedback, roadmaps, maintenance, and communication, not just infrastructure engineering.⁴

But product discipline is not the same as product theatre.

Product discipline asks what users need, what behaviour should change, what friction should disappear, and what evidence would prove the platform helped. Product theatre asks how many teams have adopted the thing, how many services are on the thing, how many plugins exist in the portal, how many internal launches happened this quarter, and whether the roadmap looks executive-friendly.

The first makes delivery teams better off. The second makes the platform team easier to report on.

The platform becomes the customer

The platform team trap usually arrives through a sequence that looks reasonable from the inside.

At first, the team solves shared problems. It standardises deployment. It creates templates. It makes observability easier. It documents golden paths. Product teams are grateful because the work removes pain they already recognised.

Then the platform team grows. More people need more coordination. More coordination needs planning. Planning needs a roadmap. The roadmap needs commitments. Commitments need scope. Scope needs prioritisation. Prioritisation starts to happen inside the platform team because the platform team owns the platform.

That sentence is where the failure hides.

The platform team owns the platform, but it does not own the consequences of using it in each product context. A stream-aligned team owns the awkward customer workflow, the regulatory deadline, the legacy integration, the performance constraint, the partner API, the incident history, and the delivery promise. When the platform team makes an abstraction without that context, it can optimise the centre while increasing work at the edge.

The platform's roadmap can become an internal product roadmap in the worst sense: a plan made by a team that needs to ship its own features, even when those features are not the most important work for its users.

This is why adoption is such a dangerous metric. Adoption sounds customer-centred. It can be useful when adoption is voluntary and when users have alternatives. If teams choose the platform because it makes their work easier, adoption says something. If teams adopt because leadership has made the platform mandatory, adoption says very little. It may only prove that the organisation can issue a mandate.

A dashboard that says 80% of services use the platform does not tell you whether lead time improved. It does not tell you whether teams understand their systems better. It does not tell you whether incident recovery is easier. It does not tell you whether developers spend less time waiting for central teams. It does not tell you whether the new abstraction hides useful detail or merely moves the confusion behind a nicer interface.

It tells you that the denominator moved.

Puppet's 2023 platform engineering report is useful because it shows both the promise and the weakness. The report found underinvestment in product-management capability, while also reporting priorities such as increasing awareness of platform capabilities and setting realistic expectations for the platform team's role.⁴ The accompanying Perforce release was more enthusiastic: respondents saw platform adoption as a move in the right direction and reported benefits around velocity, reliability, productivity, and standards.⁵ Read together, the material shows an industry confident about the category and still uneasy about whether platform teams have the product discipline to keep pace with the teams using them.

That tension is the whole story. Platform engineering can help. Platform engineering can also become a team that knows it needs product discipline while still operating like a project office.

The difference is whether the platform treats product teams as users or as inventory.

Users can say no. Users can explain why a general abstraction does not fit their situation. Users can request changes based on real work. Users can keep using a local solution when it works better, at least until the platform earns migration. Inventory gets counted. Inventory gets onboarded. Inventory gets scheduled into migration waves so the programme can report progress.

Many platform teams say they want to treat developers as customers, but their operating model says otherwise. A customer is not forced to attend a migration ceremony for a product that makes their job harder. A customer is not told that all future work must route through the platform team's prioritisation process. A customer is not blamed for lacking maturity when the platform does not meet their needs.

The language of internal customers is cheap. The discipline of internal customers is expensive.

It requires research with the teams doing the work. It requires acknowledging that one team may have a genuinely different context. It requires saying no to impressive platform features that do not remove meaningful drag. It requires maintaining unglamorous interfaces. It requires support. It requires changing the platform when users struggle instead of changing the users to fit the platform.

Most importantly, it requires the platform team to measure the user outcome, not the platform output.

Portals are not the product

Developer portals became the visible face of platform work because they are easy to recognise.

Backstage is the obvious example. Spotify released Backstage into open source in 2020, and by March 2023 the Backstage project was describing three years of growth from an internal developer portal into a broad open-source ecosystem.⁶ The appeal is understandable. A good portal can make services discoverable. It can collect ownership metadata. It can expose templates. It can connect documentation, dependencies, deployment state, and operational signals. In a messy organisation, that can be genuinely useful.

The danger is that the portal becomes a proxy for the platform.

A portal can show the catalogue. It cannot make the catalogue truthful by itself. A portal can expose templates. It cannot make the underlying deployment workflow safe by itself. A portal can gather links. It cannot remove the need for eight approvals if the organisation still requires eight approvals. A portal can show ownership. It cannot repair an ownership model where nobody is accountable for the old service that keeps paging everyone.

The shiny surface arrives before the hard operational work is complete, then leaders mistake the surface for the capability.

This is not a Backstage problem. Backstage is a tool, and tools deserve to be judged by how they are used. The problem is a familiar procurement-shaped fantasy: buy or build the visible thing, then assume the invisible organisational work will follow. The portal becomes the executive demo. The demo becomes evidence of progress. The product teams still have the same broken release path, but now they can click into it from one place.

The platform team trap loves a portal because a portal makes platform work legible to people who do not feel the original pain.

Reduced cognitive load is hard to demo. A product team no longer needing to open a ticket is hard to demo. A new engineer finding the right deployment path without asking in Slack is hard to demo. A team spending less time reasoning about IAM edge cases is hard to demo. A portal is easy to demo. It has cards. It has ownership metadata. It has a create-service button. It looks like progress.

Sometimes it is progress. Often it is a catalogue of unfinished integration.

Developer-experience research should make platform teams more careful here. Greiler, Storey, and Noda's 2022 framework treats developer experience as a multi-dimensional concern involving productivity, satisfaction, engagement, work environments, barriers, and coping mechanisms.⁷ That matters because the platform team is not improving developer experience merely by adding a tool. It is improving developer experience only if the tool changes the texture of the work.

Does the platform reduce waiting? Does it reduce uncertainty? Does it make the right path clear? Does it help teams recover from mistakes? Does it preserve enough visibility that teams can still understand the systems they own? Does it remove repeated toil without hiding essential domain or operational knowledge?

Those questions are less convenient than adoption dashboards, but they are closer to the truth.

The platform may also create new cognitive load while claiming to reduce it. A delivery team used to understand its deployment path directly. Now it must understand the product, the service, the platform abstraction, the exception process, the portal, the generated configuration, and the circumstances under which the platform team will override defaults. That can be a good trade if the abstraction is stable and useful. It can also be a hidden tax.

The worst platform abstractions are thick in the wrong places. They hide details that teams need during incidents but expose configuration knobs that only the platform team understands. They standardise the happy path but make edge cases politically expensive. They reduce local duplication by creating central coupling. They promise autonomy while moving important choices into a queue.

That is why the thinnest useful platform is such a useful discipline. Skelton and Pais argued for a thinnest viable platform: build only the platform layer needed in the current context, keep it compelling, and avoid building more than necessary.⁸ That advice sounds modest. In practice it is a hard constraint against platform ambition. It says the platform team should not build the grand internal product it can imagine. It should build the smallest reliable thing that removes actual pain.

Small is not a lack of ambition. Small is respect for the teams that must live with the abstraction.

Mandates hide weak products

The easiest way to make a platform successful is to remove choice.

Mandate the deployment platform. Mandate the portal. Mandate the templates. Mandate the service catalogue. Mandate the approval process. Mandate the observability package. Mandate the language runtime. Mandate the golden path even when the path is not golden for the team standing on it.

Some mandates are defensible. Security requirements are not optional. Compliance constraints are not a matter of taste. Production ownership needs standards. If an organisation has allowed dangerous fragmentation for years, some central rules may be necessary just to make the estate operable. The argument is not that every team should choose everything.

The argument is that a mandate is not evidence of platform value.

Mandates are sometimes used because the platform is not yet good enough to win voluntary adoption. That is the moment to slow down, not to accelerate the rollout. If the first teams struggle, listen. If the abstraction does not fit, narrow it. If teams keep bypassing the platform, find out whether they are avoiding useful discipline or escaping bad design. If onboarding requires heroics from the platform team, the platform is not self-service yet.

Forced adoption can make these signals disappear. Teams stop complaining because the decision has already been made. They build local workarounds. They route around the platform quietly. They overfit their services to the standard path and carry hidden risk elsewhere. They waste time in exception processes. They learn that platform feedback is a political activity, not a product conversation.

The platform team then sees fewer objections and calls the rollout successful.

The same pattern appears in organisational-model copying. Jeremiah Lee's 2020 critique of the Spotify model argued that companies copied a simplified story about squads, tribes, chapters, and guilds while missing the context, tradeoffs, and problems inside Spotify itself.⁹ Platform engineering has a similar risk. Organisations copy the visible structure: platform team, internal developer portal, golden paths, paved roads, adoption metrics. They miss the conditions that make those structures work: strong feedback loops, genuine autonomy, product thinking, operational maturity, trust, and a willingness to keep the platform thin.

Copying the nouns is easier than copying the discipline.

Conway's 1968 paper is still relevant here because platform teams are an organisational shape before they are a technical one. Conway argued that organisations designing systems are constrained to produce designs that mirror their communication structures.¹⁰ A platform team that sits apart from product teams, controls core delivery paths, and communicates through roadmaps, tickets, and governance meetings will tend to produce a platform shaped like that relationship.

The result is not self-service. It is mediated service with a UI.

This is why platform teams should be suspicious of their own centrality. A platform team can reduce coordination by turning repeated work into reliable self-service. It can also increase coordination by becoming the place where decisions accumulate. Every product team now needs to understand the platform team's roadmap. Every exception needs a platform conversation. Every incident involving the abstraction requires cross-team interpretation. Every migration waits for platform capacity. The platform team becomes a bottleneck while describing itself as leverage.

The trap is not centralisation itself. Some centralisation is useful. The trap is centralisation that does not continuously prove it is reducing more drag than it creates.

That proof should not be ceremonial. It should show up in product-team life. Fewer tickets. Shorter lead time for ordinary service changes. Faster onboarding. Clearer ownership. Lower incident confusion. Less duplicated boilerplate. Better compliance with less manual work. More time spent on domain problems. Less time spent asking who owns the thing.

If those outcomes are not improving, platform adoption is just compliance.

Measure the drag removed

The platform team's most important metric is not how big the platform is.

It is how much drag the platform removed from teams doing product work.

This changes the questions. Instead of asking how many services are onboarded, ask how long it takes a team to create, deploy, observe, and operate a simple production service without special help. Instead of asking how many templates exist, ask which repeated decisions teams no longer need to make. Instead of asking how many portal plugins launched, ask which questions new engineers can now answer without interrupting someone. Instead of asking how many teams migrated, ask whether migrated teams spend less time waiting, debugging, escalating, and explaining the platform.

The platform should be measured from the user's side of the interface.

That does not mean every metric must be soft or anecdotal. A platform team can track lead time from service request to usable environment, time to first successful deployment for new services, and ticket volume for common tasks. It can count failed deployments caused by configuration mistakes, incident handoffs, exception requests, and how long new engineers take to onboard. It can watch the age and usage of templates, and whether teams can find ownership and operational information without asking in chat.

But the numbers need interpretation. Lower ticket volume might mean self-service improved. It might also mean teams gave up filing tickets. Faster deployment might mean the path is simpler. It might also mean teams are pushing risk into runtime because guardrails were too weak. More services on the platform might mean value. It might also mean policy pressure.

Metrics are clues, not trophies.

The platform team also needs a deletion instinct. Internal platforms often accumulate features because removing a shared capability is politically harder than adding one. Every plugin has a sponsor. Every template has a dependent team. Every abstraction has a story about why it was once necessary. Without active pruning, the platform becomes another legacy system, except it is now the legacy system through which other systems must pass.

A good platform team asks what can be removed, simplified, or pushed back to product teams. It treats platform surface area as a liability unless that surface area is earning its keep. It knows that every extra abstraction needs documentation, support, compatibility, incident response, and migration planning. It understands that standardisation has carrying costs.

This is where product thinking matters most. Not in calling developers customers. Not in running internal launch campaigns. Not in making the portal look polished. Product thinking means choosing what not to build, learning from usage, prioritising problems over requests, supporting what already exists, and retiring features that no longer justify their weight.

Thoughtworks' 2021 platform execution-gap article makes a similar point from another angle. It argues that platform strategy is an institutionalised way to reduce friction, but that effective execution requires business value, product thinking, operational excellence, software engineering excellence, and healthy teams.¹¹ It also warns that when the strategy goes wrong, platform problems are passed to the whole software development organisation.¹¹

That is the blast radius people understate. A bad tool hurts one team. A bad shared platform hurts everyone who has been forced through it.

This is why the platform should be treated as infrastructure in both senses: it supports work, and it can fail systemically. The risk is not only downtime. It is delivery-time failure. It is an organisation discovering that all product teams are blocked by a central abstraction whose roadmap, support model, and operational maturity were never equal to its mandate.

The platform team should therefore have a lower tolerance for self-indulgence than a product team building for an external market. External products can test appetite through customers, pricing, churn, and competition. Internal platforms can hide weak demand behind authority. That makes internal product discipline more important, not less.

The platform team must earn trust repeatedly because its users cannot easily leave.

Build the boring path people choose

The healthy platform team is quieter than the trap version.

It starts with pain that teams already feel. It builds the boring path that removes the pain. It keeps the path thin enough that teams can understand it. It documents the boundaries honestly. It supports the teams that depend on it. It accepts that some teams will have legitimate reasons to stay off the path. It measures whether users are better off. It removes features that are not earning their operational cost.

It does not need every team to call itself a customer. It behaves as if teams are customers by making their work easier.

The healthy platform team also resists the urge to make the platform the centre of the engineering organisation's identity. The platform is not the product, unless the company sells the platform. The platform is a means of making product work safer, faster, clearer, or less repetitive. When platform work becomes the main story, product teams become supporting characters in someone else's transformation deck.

That is backwards.

A useful platform should make product teams more autonomous, not more dependent on a central group. It should reduce coordination, not rename it. It should expose stable capabilities, not require every team to follow the platform team's internal roadmap. It should provide defaults, not erase context. It should make compliance cheaper, not turn compliance into a theatre of approvals. It should let teams focus on their domain, not trap them in platform-specific knowledge that is just as complicated as the infrastructure it replaced.

There is a simple test: if the platform team disappeared for a fortnight, would product teams keep moving because the platform is self-service and reliable, or would they freeze because the platform is actually a central dependency wearing a self-service label?

No platform team wants the second answer. Many accidentally build it.

The fix is not to abolish platform teams. The fix is to keep their mission subordinate to delivery-team outcomes. Give them product skills, but do not let them drift into product vanity. Give them a roadmap, but make the roadmap accountable to user friction. Give them standards, but make the standards earn their weight. Give them adoption metrics, but never let adoption stand alone as success.

The platform is winning when product teams stop thinking about it most of the time.

They can create a service without guessing. They can deploy without ceremony. They can observe behaviour without assembling dashboards from memory. They can satisfy security requirements without becoming security specialists. They can understand enough of the platform to operate responsibly, but not so much that platform internals become their second domain. They can move faster because the organisation removed repeated drag, not because someone renamed central IT.

That is a high bar. It should be.

The industry has enough internal products nobody asked for: portals that catalogue confusion, frameworks that move complexity into generated files, golden paths that only work for teams whose problems were already easy, dashboards that report adoption while developers route around the edges.

A good platform team is not measured by the splendour of the thing it builds. It is measured by the work other teams no longer have to do, the confusion they no longer have to carry, and the autonomy they regain because the common path is genuinely better than inventing another local one.

The platform team trap begins when the platform becomes the point.

The way out is to make the platform boring, thin, useful, optional where possible, mandatory only where necessary, and accountable to the people whose work it is supposed to make lighter.

If teams choose it because it saves them from toil, keep building.

If teams use it only because leadership says they must, stop celebrating adoption and start listening.

---

Footnotes

1. IT Revolution. (2023). 'The Four Team Types from Team Topologies.' IT Revolution. https://itrevolution.com/articles/four-team-types/ ↩

2. Skelton, M., & Pais, M. (2019). 'Monoliths vs Microservices is Missing the Point-Start with Team Cognitive Load.' IT Revolution. https://itrevolution.com/articles/team-cognitive-load-team-topologies/ ↩

3. Bottcher, E. (2018). 'What I Talk About When I Talk About Platforms.' Martin Fowler. https://martinfowler.com/articles/talk-about-platforms.html ↩

4. Puppet. (2023). '2023 State of DevOps Report: Platform Engineering Edition.' Puppet. https://www.puppet.com/sites/default/files/pdfs/report-puppet-sodor-2023-platform-engineering.pdf ↩ ↩²

5. Perforce. (2023). '2023 State of DevOps Report Finds Platform Engineering Unlocks DevOps Success in the Enterprise.' Perforce. https://www.perforce.com/press-releases/2023-state-devops-report ↩

6. Lambert, B. (2023). 'Backstage Turns Three!' Backstage. https://backstage.io/blog/2023/03/15/backstage-turns-3/ ↩

7. Greiler, M., Storey, M.-A., & Noda, A. (2022). 'An Actionable Framework for Understanding and Improving Developer Experience.' arXiv. https://arxiv.org/abs/2205.06352 ↩

8. Skelton, M., & Pais, M. (2019). 'Monoliths vs Microservices is Missing the Point-Start with Team Cognitive Load.' IT Revolution. https://itrevolution.com/articles/team-cognitive-load-team-topologies/ ↩

9. Lee, J. (2020). 'Spotify's Failed #SquadGoals.' Jeremiah Lee. https://www.jeremiahlee.com/posts/failed-squad-goals/ ↩

10. Conway, M. E. (1968). 'How Do Committees Invent?' Datamation. http://www.melconway.com/Home/Committees_Paper.html ↩

11. Garcia Garcia, C., & Ford, C. (2021). 'Mind the platform execution gap.' Martin Fowler. https://martinfowler.com/articles/platform-prerequisites.html ↩ ↩²