Platform engineering initiatives often struggle not because of technical shortcomings, but due to organizational misalignment, unclear success metrics, and invisible friction. Understanding where your platform stands through structured benchmarking is the critical first step toward building sustainable, high-performing internal developer platforms that deliver measurable business value.
Main insights:
- Platform engineering initiatives are fragile until they cross approximately 70% maturity, making early-stage benchmarking essential for risk management
- Most teams score around 53% maturity on average, with product management and developer adoption consistently ranking as the weakest areas
- A two-axis maturity model combining organizational readiness with technical capability provides more actionable insights than single-dimensional frameworks
- Weighted scoring based on lifecycle stage (planning, MVP, early production, scaling, fully adopted) ensures context-appropriate assessment and prioritization
Platform engineering teams face a paradox: they're often technically capable but struggle with adoption, alignment, and proving ROI. Mallory Haigh, a platform therapist and workshop host for the Platform Engineering community, brings her background in full-stack engineering, customer success, and engineering management to address this challenge head-on.
You can watch the full discussion here if you missed it.
Why most platform engineering initiatives struggle
The problems platform teams face are rarely about tools or architecture. "Time and time again, no matter the vertical, no matter the size of the company, whether or not they're a medium business, a startup, or even a massive enterprise, I see the same thing," Mallory explains.
Common failure patterns include:
- Stalled adoption after the first few teams onboard
- Developers bypassing workflows despite best intentions
- Leadership questioning ROI without clear answers
- Understaffed teams relative to expectations and developer population
- Golden paths that don't cover what people actually need
The root cause? "Most organizations don't actually know where they are. They don't actually know where they stand," Mallory notes. Without understanding your current maturity level, you can't assess the risks you're carrying or prioritize the right interventions.
The risks of flying blind
Operating without clear benchmarking leads to predictable problems. Organizations tend to overinvest in tooling instead of building things that matter, misdiagnose adoption patterns and place blame, or scale too quickly before the underlying system and team can handle it.
"Platform engineering initiatives are incredibly fragile until maturity crosses what I like to call a platform stability threshold," Mallory emphasizes. Based on benchmarking data from hundreds of teams, this threshold appears around 70% maturity. Below that mark, initiatives remain vulnerable to defunding or abandonment.
Early warning signs teams often miss include:
- Rage-clicking equivalents in platform usage patterns
- User frustration signals in feedback channels
- Falling behind on proving value and ROI
- Disproportionate scaling relative to team capability
Beyond single-dimensional maturity models
Most teams start with existing frameworks like the CNCF platform maturity model or traditional DevEx scoring. While valuable, these approaches share a critical limitation: they focus heavily on technical capability while underweighting organizational maturity.
"Successful platforms require not just organizational readiness but technical capability," Mallory explains. "We need to look at both of these things." The CNCF model, for instance, uses five aspects (investment, adoption, interfaces, operations, measurement) across four grading scales, but treats all organizations within the same context.
This creates problems. "Organizations that are just starting with their first set of MVPs versus ones that have had a platform established for a long time with a lot of users, you can't really measure them in the same way," she points out. A team without adoption in the MVP stage isn't necessarily immature - they're appropriately positioned for their lifecycle stage.
A two-axis framework for platform maturity
The framework Mallory uses daily with teams worldwide addresses these gaps through two distinct axes:
Axis 1: Overall maturity score calculated across six dimensions:
- Organizational alignment and leadership - Does the business support, fund, and align the platform initiative with overall strategy? This goes far beyond simple buy-in.
- Culture and ways of working - How ready is the organization to adopt platform best practices? How do teams communicate and interact, especially between platform engineering, developers, and security?
- Product management and feedback loops - Does the team treat the platform as a product with regular management cycles, roadmaps, and actionable feedback mechanisms?
- Platform team capability - Is the team staffed appropriately with the right skills and positioned correctly within the organization? Do they have capacity to build what's needed?
- Platform technical maturity - What's the technical readiness and capability coverage, particularly for day-one versus day-two operations?
- Developer experience and adoption - How usable is the platform? What's the consumption rate and customer satisfaction among developers?
Axis 2: Lifecycle stage assessment across five phases:
- Planning
- First MVPs
- Early production grade system
- Active scaling
- Fully onboarded/adopted
"Each score for each category is weighted based on the lifecycle stage," Mallory explains. For example, organizational alignment and leadership might be weighted 2x in early stages, while platform technical maturity might be weighted 0.5x, then reversed as the platform matures.
Translating scores into risk profiles
Once you have maturity scores across the six dimensions, you can map them against lifecycle stage to identify risk levels:
- Critical risk - Initiative is almost certain to fail without immediate intervention
- High risk - Major structural gaps across multiple categories
- Medium risk - Targeted intervention required in specific areas
- Controlled risk - Regular monitoring needed to stay ahead of emerging issues
The risk thresholds shift by lifecycle stage. Early-stage initiatives (planning, MVP) need to score above 50% to even reach medium risk, because they have no proof of value yet. "It is very easy to fail at these stages," Mallory warns.
In contrast, teams in active scaling or full adoption phases can tolerate slightly lower scores in certain categories without entering high-risk territory, as long as they maintain strength in critical areas like adoption and technical maturity.
What the data reveals
Analysis of 114 recent platform assessments shows an average maturity score of 53%, with most organizations classified as "developing." The strongest areas across teams are:
- Platform team capability (62% average)
- Culture and ways of working (strong collaboration internally and externally)
The weakest areas consistently are:
- Product management (lowest scores)
- Developer adoption (second-lowest)
- Platform technical maturity (particularly for early production teams)
"What this tells me is that the teams we're working with are usually quite technically capable," Mallory observes. "But the things that are really lagging behind are this area of product management and adoption."
This pattern reveals a critical insight: platform teams tend to build faster than the organization can adopt or support. This puts the entire initiative at risk, which is why the slow, steady, gradual iterative approach to platform engineering is so important.
Common problems by category
Each maturity dimension has characteristic failure modes:
Organizational alignment: Leadership alignment gaps and mismatched expectations between platform teams and executives
Culture and ways of working: Lack of collaboration with security or operations teams, blame culture ("developers are lazy," "security is a roadblock")
Product management: No measurement framework, weak feedback loops that stall progress
Platform team capability: Team too small or overwhelmed relative to developer population they support
Technical maturity: Golden paths cover too few workflows or don't approach workflows correctly
Developer adoption: Poor documentation, inconsistent developer experience, lack of incentivization beyond mandates
Putting benchmarks to work
Gathering baseline measurements is just the beginning. Use your benchmark to:
- Build or modify your roadmap based on identified gaps and strengths
- Prioritize urgent course corrections against the biggest risks
- Establish regular sanity checks by reassessing maturity quarterly or semi-annually
- Communicate business value through risk profiles and ROI projections
- Align stakeholders around shared understanding of current state and needed investments
"You don't have to do this alone," Mallory emphasizes. The Platform Engineering community offers structured assessments combining questionnaires (5-6 questions per category), calibration interviews, maturity scoring, lifecycle classification, risk profiling, and prioritized recommendations across 30/60/90-day or 30/90/180-day windows.
If you enjoyed this, find here more great insights and events from our Platform Engineering Community.
If you want to dive deeper, explore our instructor-led Platform Engineering Certified Leader course and connect with peers from large-scale enterprises who are driving cultural transformation.
Key takeaways
- Benchmark early and often - Platform initiatives are fragile below 70% maturity. Understanding where you stand through structured assessment is essential for risk management and prioritization, especially in early stages when failure is most likely.
- Weight your assessment by lifecycle stage - A team in the MVP stage without broad adoption isn't necessarily failing. Context-appropriate evaluation prevents misdiagnosis and ensures you focus on what actually matters for your current phase.
- Focus on organizational maturity, not just technical capability - The data is clear: teams struggle most with product management and developer adoption, not technical implementation. Treating your platform as a product with proper feedback loops and incentivization is critical.
- Use benchmarks to communicate business value - Translating maturity scores into risk profiles and ROI projections helps you speak the language of leadership, secure appropriate staffing and funding, and align stakeholders around platform success.

