Platform engineering is supposed to be the answer. Reduce cognitive load, give developers self-service golden paths, and watch deployment frequency climb. Gartner predicted that by 2026, 80% of large software engineering organisations would establish dedicated platform teams. That prediction has largely come true.
Here is the uncomfortable part: industry surveys from The New Stack and byteiota consistently report that 60-70% of those initiatives fail to deliver measurable impact. Almost half of platform teams are disbanded or restructured within 18 months. That means most organisations are investing significant money and headcount in something that will disappoint them.
We have worked with platform teams at various stages — some thriving, many struggling, a few already in the process of being shut down. The failure patterns are remarkably consistent. This post documents the seven we encounter most often, with practical guidance on how to avoid each one.
The Paradox: Mass Adoption, Mass Failure
Before we walk through the patterns, it is worth sitting with the contradiction for a moment.
Gartner’s forecast of 80% adoption was not wrong. Organisations genuinely need something to bridge the gap between “you build it, you run it” DevOps ideals and the reality that most developers do not want to become infrastructure experts. The CNCF Platform Engineering Maturity Model acknowledges this by providing a progressive framework across investment, adoption, interfaces, operations, and measurement.
The problem is not that platform engineering is a bad idea. The problem is that organisations treat it as a technology project rather than an organisational change programme. Understanding how platform engineering differs from DevOps and SRE is the necessary first step, but it is not sufficient.
With that context, here are the seven failure patterns.
1. No Product Mindset
The pattern: A platform team is formed, given a mandate to “build an internal developer platform,” and immediately starts architecting infrastructure. No one asks developers what they actually need. No one defines success criteria. There is no roadmap, no backlog prioritisation based on user research, and no feedback loops.
How common it is: According to the State of Platform Engineering Report Vol. 4, 44.3% of organisations lack a shared vision or product mindset for their platform initiative. Only 21.6% have a dedicated platform product manager. And yet, the most successful platform teams universally include this role.
What we see in practice: Platform teams staffed entirely with infrastructure engineers who assume they know what developers need. They build what they find technically interesting rather than what removes the most friction. Six months later, they have an impressive Kubernetes abstraction layer that nobody uses because the real bottleneck was environment provisioning.
The fix: Treat the platform as a product. Appoint a platform product manager — or at minimum, assign someone to own user research, prioritisation, and a public roadmap. Conduct regular developer interviews. Track adoption metrics the same way a product team tracks feature usage. The Team Topologies concept of “platform as a product” is not optional; it is the foundation everything else depends on.
2. Developer Adoption Crisis
The pattern: The platform is built. It works. The documentation exists. Developers ignore it. Adoption stalls at 10-15% of teams. Leadership grows frustrated. The platform team starts lobbying for mandates.
How common it is: 45.3% of platform teams cite developer adoption as their number-one challenge. This is not a secondary concern; it is the primary one. Meanwhile, 36.6% of organisations rely on top-down mandates to drive adoption — which creates compliance without genuine buy-in.
What we see in practice: Developers avoid the platform for rational reasons. The platform introduces a new workflow that is slower than their current one. The abstractions break for edge cases. The self-service portal requires three Jira tickets and a Slack conversation to accomplish what a Terraform apply does in minutes. Developers are not resistant to change; they are resistant to worse tooling.
The fix: Start with the thinnest viable platform — the smallest set of capabilities that genuinely removes friction. In early engagements, we often recommend solving one high-pain workflow end-to-end rather than building a broad but shallow platform. If your platform cannot save a developer at least 30 minutes per week compared to their current approach, adoption will be a constant battle.
Measure adoption as a leading indicator, not a trailing one. Track which golden paths developers actually use, where they drop off, and what they do instead. DevOps automation done well reduces friction; a platform that adds friction is worse than no platform at all.
3. Cannot Demonstrate ROI
The pattern: The platform team ships capabilities. Some teams adopt them. But when leadership asks “what is the return on our investment?”, the answer is vague hand-waving about developer experience and reduced toil. Budget conversations become existential threats.
How common it is: 40.9% of platform initiatives cannot demonstrate measurable value within their first year. Even more alarming, the State of Platform Engineering report indicates that a significant proportion of teams do not systematically measure any metrics at all. Nearly 30% of platform teams in 2025 reported measuring nothing — an improvement from 45% the previous year, but still unacceptable.
What we see in practice: Platform teams that track deployment frequency but cannot connect it to business outcomes. Teams that know developers are “happier” but cannot quantify what that means in pounds or hours. When budgets tighten, these teams are the first to be restructured.
The fix: Define success metrics before writing a single line of platform code. The most widely adopted framework is DORA metrics (used by 40.8% of platform teams), followed by time-to-market measures (31.0%) and the SPACE framework for developer productivity (14.1%).
We recommend a layered metrics approach:
- Efficiency metrics: Onboarding time, environment provisioning time, self-service adoption rate
- Quality metrics: DORA four keys (deployment frequency, lead time, change failure rate, mean time to recovery)
- Experience metrics: Platform NPS, developer satisfaction surveys, cognitive load assessments
- Business metrics: Time-to-market for new features, infrastructure cost per team, incident reduction
Understanding what DevOps consulting actually costs helps frame the ROI conversation in terms leadership already understands.
4. Over-Engineering and the Perfection Loop
The pattern: The platform team attempts to build a perfect abstraction layer that hides all infrastructure complexity from developers. They spend months designing an elegant API that covers every possible use case. The scope keeps expanding. Version 1.0 never ships, or ships so late that organisational priorities have shifted.
What we see in practice: A team spent nine months building a custom Kubernetes abstraction that supported multi-cloud, multi-region, and multi-tenant configurations. Their organisation ran a single cluster in one AWS region. When we asked why, the answer was “we want to be ready for the future.” That future never arrived, and the platform was shelved when the team lead left.
The InfoWorld analysis of platform engineering anti-patterns describes this as the “abstraction trap” — trying to abstract away every possible use case creates a rigid, complex system that blocks power users and requires the platform team to maintain an enormous surface area.
The fix: Ship something useful in the first 4-6 weeks. The thinnest viable platform concept from Team Topologies is instructive: a TVP could be as simple as a wiki page with documented conventions and a few scripts. Start there. Add abstraction layers only when you have evidence that developers need them.
We advise teams to adopt two-week iteration cycles with mandatory demos to developer stakeholders. If the platform team cannot show something a developer would willingly use every two weeks, the scope is too broad.
5. Portal-First, No Backend (The Portal Trap)
The pattern: The organisation purchases or builds an internal developer portal (Backstage, Port, Cortex, or similar) and declares the platform engineering initiative “launched.” The portal looks impressive in demos. It has a service catalogue and some documentation links. But clicking any button that should provision infrastructure, spin up an environment, or configure a pipeline leads to… a form that creates a Jira ticket.
What we see in practice: This is one of the most common patterns we encounter. A beautifully designed portal sits on top of manual processes. Developers quickly learn that the portal is a front-end for the same ticket queue they were already using, just with extra steps. The portal becomes a symbol of the gap between the platform team’s ambitions and their actual capabilities.
As platformengineering.org makes clear, the portal is not the platform. The portal is an interface layer. The platform is the set of self-service capabilities, APIs, and automation underneath. Without the backend, the portal is an expensive directory.
The fix: Build capabilities before interfaces. Start with one fully automated workflow — perhaps environment provisioning or CI/CD pipeline creation — and wire it end-to-end. Only then build or configure a portal to expose it. Each portal action should result in automated execution, not a human in the loop.
A useful test: if removing the portal would not change how long it takes a developer to accomplish a task, the portal is not adding value.
6. Top-Down Mandates and Cultural Resistance
The pattern: Leadership decides that all teams will use the internal platform by Q3. An email goes out. Compliance is tracked. Developers are told to migrate their workflows. There is no explanation of why, no evidence that the platform is better, and no input from the teams being mandated.
How common it is: 36.6% of organisations rely on mandates to drive platform adoption. Cultural resistance remains a persistent barrier, with CIO.com reporting it as one of the top factors that separate platform engineering winners from losers. Meanwhile, 76% of organisations admit their software architecture’s cognitive burden creates developer stress and lowers productivity — the very problem platforms are meant to solve.
What we see in practice: Mandated adoption creates two outcomes, neither good. Some teams comply minimally: they route their deployments through the platform but maintain shadow processes that do the real work. Other teams resist openly, creating political friction that consumes leadership attention. Both outcomes poison the well for the platform team’s future efforts.
The fix: Earn adoption; do not mandate it. Focus on one or two early-adopter teams that have genuine pain the platform can address. Solve their problems visibly and let them become advocates. When other teams see colleagues shipping faster, they will ask to join — this is the 28.2% of organisations that achieve “intrinsic value pull” in the survey data.
A proper DevOps strategy and assessment should identify which teams will benefit most from platform capabilities and in what order. Sequencing matters more than speed.
7. Underfunding and the Budget Mismatch
The pattern: The organisation commits to platform engineering in principle but funds it as a side project. One or two engineers are pulled from existing teams and told to “build the platform” on top of their existing responsibilities. There is no dedicated budget for tooling, no headcount plan, and no executive sponsor who will fight for resources.
How common it is: 47.4% of platform initiatives operate on budgets under $1 million while expected to deliver broad organisational impact. This creates a structural mismatch between expectations and capabilities that almost guarantees underdelivery.
What we see in practice: A two-person platform team trying to serve 15 product teams. They spend all their time on support requests and have no capacity for building new capabilities. They cannot hire because there is no approved headcount. They cannot buy tooling because there is no budget. They burn out, leave, and the initiative collapses. This is how you end up in the “50% of platform teams disbanded within 18 months” statistic.
The fix: Be honest about what different funding levels can achieve. A two-person team can maintain a thinnest viable platform for 3-5 product teams. Serving an entire engineering organisation of 100+ developers requires a dedicated team of 4-8 platform engineers, a product manager, and a meaningful tooling budget.
If the organisation is not prepared to fund a proper team, it is better to invest in consulting expertise to establish the foundation and train internal staff, rather than setting up an underfunded team for failure.
What Successful Platform Teams Do Differently
After documenting what goes wrong, it is worth examining what the 30-35% of successful platform teams have in common. Based on our engagements and the survey data, these teams consistently:
Start with Developer Pain, Not Technology Choices
They interview developers before selecting tools. They identify the three most time-consuming workflows and automate those first. They do not start with “we need Backstage” — they start with “our developers spend four hours provisioning test environments.”
Apply Product Management Discipline
They have a product owner or product manager. They maintain a public roadmap. They hold regular user research sessions. They measure adoption and satisfaction. Only 21.6% of platform teams have a dedicated product manager, and those teams dramatically outperform the rest.
Ship Incrementally
They follow the thinnest viable platform approach. Their first delivery is often embarrassingly simple — a set of Terraform modules and a README, or a few GitHub Actions workflows with good defaults. They iterate based on feedback rather than building in isolation.
Measure Relentlessly
The top-performing teams combine DORA metrics with developer experience data. They track onboarding time (how long from first day to first deploy), self-service adoption rate (percentage of workflows that require no tickets), and platform NPS (would you recommend this to a colleague). As The Register reports, proving value through metrics is what separates platform teams that survive from those that get disbanded.
Invest in Documentation and Onboarding
They treat documentation as a product feature, not an afterthought. Every golden path has a quickstart guide that a new developer can follow in under 30 minutes. They run regular office hours and maintain a Slack channel with fast response times.
A Diagnostic Checklist
If you are running or planning a platform engineering initiative, ask yourself these questions:
| Question | Warning Sign |
|---|---|
| Do we have a dedicated platform product manager? | No PM = no product thinking |
| Can we demonstrate platform ROI in business terms? | Vague answers = budget risk |
| What percentage of developers actively choose to use the platform? | Below 40% = adoption problem |
| How long until a new developer can deploy to production? | Over 1 week = onboarding failure |
| Does every portal action result in automated execution? | Manual steps = portal trap |
| Are we funded for the scope we have been asked to cover? | Under $1M for 100+ devs = underfunded |
| Can we ship a useful improvement every two weeks? | No = over-engineering |
If you answered “yes” to three or more warning signs, your initiative is at serious risk. The good news is that these patterns are fixable — but only if acknowledged early.
The Path Forward
Platform engineering is not a fad. The underlying problems it addresses — cognitive overload, slow onboarding, infrastructure complexity, inconsistent developer experience — are real and growing. The CNCF Platform Engineering Maturity Model provides a solid framework for progressive improvement, and organisations like those documented by Martin Fowler’s engineering blog demonstrate that platforms can deliver extraordinary value when built thoughtfully.
The 70% failure rate is not inevitable. It reflects a predictable set of mistakes that organisations keep making because they treat platform engineering as a technology problem rather than a product and organisational design challenge.
If we could distil our consulting experience into a single recommendation, it would be this: start smaller than you think you should, measure everything, and earn adoption rather than mandating it.
Build a Platform That Developers Actually Want to Use
The difference between a thriving internal developer platform and an expensive shelf project comes down to product thinking, honest measurement, and disciplined execution — not technology choices.
Our team provides comprehensive platform engineering consulting to help you:
- Avoid the seven failure patterns through structured assessment and gap analysis before you write a single line of platform code
- Design a thinnest viable platform that solves real developer pain in weeks, not months, with incremental expansion guided by adoption data
- Establish metrics and governance that connect platform investment to business outcomes leadership actually cares about
We have helped organisations at every stage — from pre-platform assessment through to rescuing initiatives that have stalled. Whether you need a full platform strategy or a targeted intervention on a specific failure pattern, we bring the consulting experience to get your initiative on track.