The Platform Engineering Trap: Why Developer Experience Is Becoming the Most Important Reliability Metric 

Every engineering organization I’ve worked with says reliability is its highest priority. Say it in the all-hands. Put it in the OKRs. Nobody disagrees with reliability — it’s the corporate equivalent of being in favor of breathing. And yet when you actually trace the outages, the near-misses, the 2 a.m. pages that could have waited until Tuesday, a strange pattern emerges. The infrastructure mostly held. The database didn’t fall over. The load balancer did its job. What broke was a developer’s ability to get a change out safely, quickly, and with any confidence about what it would do once it landed. The incident didn’t start in prod. It started three weeks earlier, in a platform team’s backlog, when somebody deprioritized a paved-road update because a bigger initiative needed the sprint capacity. 

Platform engineering was supposed to fix this. That was the pitch, anyway — internal developer platforms, self-service infrastructure, golden paths, all of it converging on a simpler mental model for the people writing application code. In a meaningful number of organizations I’ve consulted with or simply watched from the outside, it has produced the opposite. The platform grew more capable and, in the same motion, more opaque. Developers now navigate a system that is ostensibly built for them but frequently feels built around them — a scaffold of Backstage catalogs, Terraform modules, GitOps pipelines, and Slack bots that answer questions nobody asked, layered on top of the actual work of shipping software. 

The Measurement Problem Nobody Wants to Own 

Here’s the uncomfortable part. Most reliability programs still measure the thing that’s easiest to measure, not the thing that’s actually predictive. MTTR, error budgets, SLO burn rates — these are lagging indicators of infrastructure health, and they’re fine as far as they go. But they say almost nothing about whether the twelve engineers who touched the code before it broke understood the system they were touching. DORA’s own research got at this obliquely, years back, when it found that deployment frequency and change failure rate correlate more tightly with organizational factors — psychological safety, tooling clarity, the number of approvals standing between a commit and production — than with raw infrastructure sophistication. Nobody built a dashboard for that. Dashboards like clean numerators and denominators. Cognitive load doesn’t offer either. 

I want to name something specific here, because “developer experience” has become mushy enough to mean everything and therefore nothing. What I’m actually pointing at is platform legibility — the degree to which an engineer can look at the system in front of them and correctly predict what a given action will do, without consulting someone else or discovering the answer via incident. Legibility is not the same as documentation, though the absence of the former often gets misdiagnosed as the absence of the latter. You can have exhaustive docs and zero legibility, because the docs describe the platform as designed rather than the platform as it currently, actually behaves after eleven quarters of drift. 

Where the Fracture Actually Happens 

Picture the onboarding flow for a mid-tier fintech, one I’ve seen some version of a dozen times with the serial numbers changed. New backend engineer, competent, has shipped production code before. Week one: provision access to four separate systems, none of which share an identity model cleanly, because the platform team integrated them at different points in the company’s history and never went back to unify the seams. Week two: first PR touches a service that depends on a shared library maintained by a team that no longer exists in its original form — reorganized eighteen months ago, ownership technically transferred, but the transfer was a Jira ticket, not a transfer of understanding. Week three: first on-call shift. The runbook references a dashboard that was migrated to a new observability vendor and never updated. The engineer pages someone. The someone pages someone else. Forty minutes pass before anyone remembers that the actual metric lives somewhere else now. 

None of this shows up as an infrastructure failure. Every system involved is, technically, up. What failed was the connective tissue — the shared mental model that lets a developer act with appropriate speed and appropriate caution simultaneously. I’d call this coordination latency, distinct from network latency in that it doesn’t show up in your tracing tool at all; it shows up as the gap between “I could ship this” and “I actually understand what shipping this will do,” and that gap is where most of the expensive incidents germinate. 

Platform teams, to their credit, usually see part of this. What they tend to miss is scope. They’ll fix the identity model. They’ll consolidate the observability stack. Both good, necessary work. But the underlying problem — that the platform’s rate of change now exceeds any individual developer’s rate of comprehension — doesn’t get addressed by consolidation alone, because consolidation is still additive. Every golden path you build is one more abstraction someone has to hold a model of. At some threshold, and I don’t think anyone has a clean formula for where that threshold sits, the marginal golden path stops reducing cognitive load and starts adding to it, because now there are two ways to do the thing and the developer has to know which one is current. 

The AI Acceleration Wrinkle 

This gets sharper, not softer, with AI-assisted development in the mix, and I say this having watched teams adopt Copilot and its cousins with real enthusiasm. The tooling makes it trivially easy to generate code that compiles and passes the obvious tests while having no coherent relationship to the platform’s actual conventions — the retry semantics the platform expects, the way secrets are supposed to be sourced, which queue is the sanctioned one for a given workload. A junior engineer with an AI assistant can now produce, in an afternoon, a volume of plausible-looking code that would have taken a senior engineer a week, and a meaningful fraction of that code will be platform-illegal in ways that don’t surface until it’s running. The assistant has read the codebase. It hasn’t read the tribal knowledge, the four Slack threads explaining why that one service still uses the deprecated auth pattern, the postmortem from 2023 that’s the actual reason nobody touches the checkout path on Fridays. 

This is what I mean when I say AI acts as an entropy multiplier inside a platform with weak legibility. It doesn’t create the underlying disorder. It amplifies whatever disorder already exists, at a pace the platform team’s existing feedback loops — code review, on-call, quarterly retros — were never built to absorb. Organizations that had already invested in legible platforms, ones where “the way things are done” is enforced structurally rather than socially, tend to get real leverage from AI-assisted development. Organizations that were coasting on institutional memory get the opposite: faster production of subtly wrong code, at exactly the volume that overwhelms the humans who used to catch it by pattern recognition alone. 

What Actually Predicts Reliability Now 

If I had to bet money on which metric best predicts an organization’s future incident rate — better than uptime, better than error budget consumption — I’d bet on time-to-first-successful-deploy for a new hire. Not because the metric itself matters, but because of what it’s a proxy for: how much of the platform’s behavior lives in someone’s head versus in the system itself. Organizations where that number is measured in hours tend to have externalized their institutional knowledge into tooling, defaults, and guardrails. Organizations where it’s measured in weeks are running on tribal memory, and tribal memory doesn’t scale, doesn’t survive attrition, and doesn’t show up in any SLO. 

Adoption telemetry on the platform itself is the second signal worth watching, and almost nobody watches it properly. Not “how many teams are on the platform” — that number lies, because usage under mandate looks identical to usage under enthusiasm. The signal is closer to: how many developers route around the paved road for tasks the paved road claims to support? Every workaround is a vote of no confidence, cast quietly, usually without a ticket filed, because filing the ticket costs more perceived time than just doing the thing manually again. I’ve sat in platform team retros where the team is genuinely puzzled about low adoption of a feature they spent two quarters building, and the answer was sitting in the support Slack channel the whole time — forty messages from engineers explaining, patiently, workarounds for the thing that was supposed to make workarounds unnecessary. 

What Changes Monday Morning 

None of this argues for less platform investment. It argues for redirecting it. A few things I’d actually do, starting this week, if I were running a platform org that wanted developer experience treated as a first-class reliability input rather than a nice-to-have: 

Stop measuring platform team output in features shipped and start measuring it in cognitive load removed — which is admittedly harder to quantify, but proxies exist. Support ticket volume per feature is one. Time-to-resolution on “how do I” questions is another, cruder but honest. If a platform feature increases either after launch, it failed, regardless of how elegant the underlying implementation is. 

Kill golden paths that have fallen out of currency, actively and visibly, rather than letting them decay in place next to their replacements. Two ways to do the same thing is worse for reliability than one bad way, because the ambiguity itself is the hazard — a developer choosing wrong isn’t making an error, they’re making a reasonable choice given genuinely ambiguous signal. 

Treat the AI-assisted code path as a distinct risk surface requiring its own guardrails — not a policy document nobody reads, but structural enforcement: linting rules that catch platform-illegal patterns before review, scaffolding that makes the sanctioned pattern the path of least resistance rather than something the developer has to know to ask for. If the easiest thing to generate is also the correct thing, you’ve actually solved something. If correctness requires the developer to already know what correct looks like, you’ve just moved the tribal knowledge problem downstream, where it’s more expensive to catch. 

And measure time-to-first-deploy for new hires quarterly, not as an HR metric but as an engineering one, reported alongside your SLOs, because it will tell you things your SLOs structurally cannot. 

The next generation of engineering organizations won’t compete on who runs the most sophisticated Kubernetes clusters. They’ll compete on how effortlessly developers can move from idea to production without needing someone else’s head to borrow along the way. In that future, platform engineering stops being an infrastructure discipline and becomes something closer to a product discipline, with actual users, actual churn, and actual adoption curves that platform teams are accountable for the way product teams are accountable for theirs. The organizations that make that shift first will spend less time managing the complexity they built and more time on the complexity that was actually worth building.