For much of its short history, platform engineering has focused on building the technical foundations that make software delivery faster, more reliable and more consistent. Internal developer platforms, standardized workflows and self-service infrastructure have all been designed around a central goal: Reducing friction for developers.
But as platform engineering matures, a new challenge is emerging. Building the platform is no longer enough. Platform teams increasingly need developers to use what they’ve built.
That shift is changing how organizations evaluate platform engineering success. Traditional measures such as deployment frequency, uptime and infrastructure standardization remain important, but they no longer tell the whole story.
Measuring Outcomes, Not Output
One of the biggest changes is how organizations assess platform effectiveness.
Aaron Beals, CTO at Flux, says platform teams have historically focused on measuring their own output rather than the outcomes experienced by developers.
“Metrics usually measure the platform team’s output rather than developer outcomes,” he says. “If the platform team is doing their job well, developers will voluntarily adopt. If getting them to follow platform best practices comes from a mandate, then you’re measuring compliance, not value.”
That distinction is becoming increasingly important as platform engineering expands beyond infrastructure provisioning into areas such as developer experience, governance and artificial intelligence (AI) enablement.
Beals argues that adoption itself may be one of the most valuable indicators of platform success.
Metrics such as voluntary versus mandated adoption rates, the frequency with which developers bypass platform services and the time required for developers to become productive on a platform can provide a clearer picture of whether the platform is helping teams move faster.
While DORA metrics remain useful, Beals notes they often fail to establish a direct connection between platform investments and improvements in software delivery outcomes.
Why Developers Leave the Paved Road
Many organizations have successfully launched internal developer platforms, yet adoption remains inconsistent. Developers often continue to use their own tools, workflows and deployment paths even when a standardized platform exists.
According to Beals, platform teams frequently approach this problem from the wrong direction.
“Platform teams aren’t well-served by approaching this problem by making guesses,” he says. “It’s all about measurement and observation.”
Developers rarely bypass platform services out of defiance. More often, they do so because alternative approaches are faster, easier or better aligned with immediate goals.
“If devs are bypassing the paved road, it’s not likely due to disobedience,” Beals says. “They generally bypass when the bypass is more convenient or gets to a result faster.”
The temptation for organizations is to solve adoption problems through mandates. Beals warns that such approaches often create exactly the kind of friction platform engineering was intended to eliminate.
“The fastest path to friction and resentment is to put a mandate in place,” he says. “If you’re doing that, you’re just policing, not serving the developers.”
Instead, platform teams should adopt a product mindset focused on listening, prototyping, building and measuring. Adoption, he argues, should be earned rather than enforced.
Thinking Like a Product Team
The growing emphasis on adoption is one reason platform engineering is increasingly being described as an internal product discipline.
In this model, developers become customers, and platform teams become responsible for understanding user behavior, prioritizing needs and communicating a roadmap.
“It’s a product, and your customer is the developer,” Beals says.
That does not mean blindly implementing every feature request. Instead, platform teams must combine user feedback with product judgment and long-term strategy.
“Product judgement is about synthesizing what users actually do into a product direction,” he says. “Product thinking also means having a vision and saying no.”
The shift also requires stronger change management capabilities. Platform teams must understand how developers interact with their platforms, identify points of friction and continuously refine the experience based on observed behavior.
“You need to measure their adherence to the platform, watch their behaviors when they bypass, and then make product improvements accordingly,” Beals says. “Everyone likes to say they are ‘data driven,’ but platform teams absolutely need to be.”
AI Raises the Stakes
The rise of AI-powered development tools is adding another layer of complexity. Organizations are rapidly introducing coding assistants, agents and automated development workflows.
At the same time, security, governance and compliance requirements remain non-negotiable. Beals says he believes many organizations are framing the issue incorrectly.
“I think that autonomy vs. governance is a false dichotomy,” he says.
The greater risk, he argues, is attempting to govern AI-driven development by forcing it to operate at human review speeds.
“The biggest risk here is governing AI by slowing it down to human speed,” he says. “That takes away all of the benefits of agentic development.”
Instead of adding more approval gates, organizations should focus on visibility and continuous observation of AI-generated outputs.
“The solution here is more visibility: Fewer gates and more continuous observation,” he says.
From Platform Provider to Strategic Guide
As AI accelerates software delivery and development environments become increasingly complex, platform engineering has an opportunity to move beyond its infrastructure roots.
Whether that transition happens will depend on a platform team’s ability to demonstrate measurable business impact.
“I’d like to see platform engineering become more strategic,” Beals says. “But the only way for that to happen is to prove impact in business terms.”
The organizations that succeed may be the ones that stop treating platform engineering as a collection of technical services and start treating it as a product designed to influence how software gets built.
As Beals puts it, platform teams should focus on “building conditions where the best choice is the easiest choice” while ensuring they can measure the resulting impact on developer outcomes and business performance.