The Blueprint Was the Easy Part

In a previous article I argued that most data organizations have a platform but no developer experience on top of it, and that an Internal Developer Platform (a self-service layer of templates, golden paths, and guardrails) is the missing piece. Suppose I convinced you. You got the funding, assembled a small platform team, built a genuinely good blueprint. The demo where a data product goes from nothing to deployed-hello-world in four minutes got applause from the architecture board.

Eighteen months later, three teams use it, two of them because they were told to, and the platform team is quietly being asked what they’ve delivered lately.

I wish this were a hypothetical. The industry data says it’s the median outcome. The State of Platform Engineering Volume 4 survey found that developer adoption is the number one challenge platform teams report, ahead of anything technical. Over a third of platforms are adopted by mandate rather than because anyone wants them. And 40.9% of platform teams can’t demonstrate measurable value within twelve months, which the CIO-facing analysis of that data politely describes as “risking defunding.”

None of these failures are about the blueprint. This article is about what they are about. Almost none of it is technical, which is exactly why technical teams keep losing to it.

The ticket queue does not want to die

Here’s a fact from the Volume 3 survey that I find quietly devastating: 44% of platform teams cite “lack of developer self-service, ticket ops” as a founding reason their team exists, yet only about a third of them have actually achieved self-service with real user autonomy. The thing the platform was created to kill is the thing it still does. Port’s survey of engineering teams puts numbers on the experience from the other side: 78% of developers wait a day or more for infrastructure help, and 94% are dissatisfied with their self-service tooling.

Why does the queue survive its own replacement? Because a ticket queue is legible. Tickets closed per week is a metric a manager can screenshot into a quarterly review. A well-adopted golden path produces the opposite: silence. Nobody files a ticket, nobody escalates, and the platform team’s work becomes invisible precisely when it’s working. For an infrastructure engineer whose career has been measured in requests handled, self-service is not obviously good news. I’ve watched platform engineers keep “just this once” manual provisioning paths alive for months, always for a friendly team in a hurry, never quite getting around to automating that last case. Each exception feels generous. Collectively they are the queue, reconstituting itself.

The cost of leaving it alive is not just slowness. Evan Bottcher’s essay on platforms (the one that gave us “compelling internal product”) measured tasks requiring cross-team coordination at ten to twelve times slower in elapsed time than tasks a team could do alone. That multiplier is what your data teams are quietly paying every time the golden path has a manual step in the middle.

Golden paths read as central control, especially in the data world

The second killer is stated most often as a compliment: “this is great, but our domain is different.”

Data organizations have spent the last five years being told, via data mesh, that domains should own their data products end to end. Then the platform team shows up with standardized blueprints, and to a domain team that fought hard for autonomy, a golden path doesn’t look like convenience. It looks like the recentralization they were promised was over. Researchers who interviewed practitioners across real data mesh implementations found the top challenges were exactly here: the transition to federated governance and the shift of product responsibility to domains. The IDP walks straight into that unresolved tension.

The CNCF’s platform maturity model gives us clean vocabulary for what happens next: adoption is either extrinsic (mandated, incentivized) or intrinsic (teams pull the platform because it’s obviously better). Mandated adoption is how a third of platforms get their users, and it produces compliance theatre: teams run the scaffolding once to satisfy the dashboard, then work around it. The tell is a fleet of repositories created from your blueprint with no commits after week two.

Spotify, whose Backstage is the most-copied portal on earth, learned this internally before any of us: part of the reason they open-sourced it was that they didn’t want to force another internal migration on their own engineers. If the company that invented the golden path treats mandates as a last resort, the enterprise rolling out its first data IDP should assume mandates buy dashboards, not adoption.

Governance arrives with a gate in hand

In the first article I argued the IDP enables governance by design: classification, quality checks, and audit trails baked into the blueprint, so compliance is the default state rather than a review outcome. I stand by it as architecture. What I underestimated is that governance by design threatens governance by review, and governance by review is somebody’s team.

When the governance function first understands what the platform does, its instinct is rarely “wonderful, our checklists are now code.” It’s “wonderful, a chokepoint; let’s add an approval step to it.” One approval step becomes an intake form, the intake form becomes a fortnightly review meeting, and your four-minute data product creation now has an eleven-day median because a committee meets twice a month. The platform didn’t remove the bureaucracy. It gave the bureaucracy an API.

The evidence against gate-style approvals is old and damning. The research behind Accelerate found that external approval bodies like change advisory boards correlated with slower delivery and had no correlation with lower change failure rates. The approval doesn’t buy the safety it charges for. In the data world the pull toward gates is stronger than in software, because the fear is sharper: a bad deployment gets rolled back, a data leak gets reported to a regulator. And right now data teams rank quality and trust as their top problem while AI adoption accelerates past their governance capacity, which makes clamping down feel responsible even when it’s counterproductive.

The move that works, in my experience, is treating the governance function as a platform customer with the same seriousness as the data teams. Their blueprint deliverable is different: not scaffolded repos but evidence. Auto-generated classification records, quality gate logs, lineage they can hand to an auditor without a spreadsheet safari. Governance stops defending the gate the day the platform makes their audit season shorter. Until then they will defend it, rationally, forever.

The J-curve is where platforms lose their funding

The DORA research contains the single most important chart for anyone sponsoring a platform, and almost nobody shows it to their sponsor. Platform adopters in the 2024 report saw individual productivity up 8% and team performance up 10%, alongside throughput down 8% and change stability down 14%. DORA calls the overall shape a J-curve: things get measurably worse before they get better, as complexity surfaces and workflows resettle.

Now place that dip on a corporate calendar. The platform launches with executive attention in Q1. The dip arrives in Q3, right as budget planning starts. The recovery arrives next year, but next year’s budget was set during the dip. This, I think, is the mechanical explanation for a large share of the 40.9% that never demonstrate value: not that value wasn’t coming, but that the measurement window and the J-curve were misaligned, and nobody had warned the people holding the money.

The warning matters because executive intuition runs the wrong way. McKinsey’s developer velocity research found best-in-class tooling among the strongest drivers of business performance, yet only 5% of executives ranked tools as a top-three enabler. The gap between what drives outcomes and what leadership believes drives outcomes is where platform funding goes to die. And it’s widening: Atlassian’s 2025 survey found 63% of developers say leadership doesn’t understand their pain points, up from 44% a year earlier.

Meanwhile the platform team itself is often structurally incapable of fighting back: nearly half operate on budgets under a million dollars, 38% have no product manager, and 29.6% measure no success metrics at all. A team with no baseline, no PM, and no measurement, hitting a predictable dip it never announced, loses the budget conversation to whichever initiative promised a dashboard by Friday.

Nobody’s OKR: the champion problem

Strip away the surveys and the pattern underneath is simple: platforms get built on borrowed authority. There’s a champion, a director or principal who gets it, who shields the team and talks to finance. Champions change roles on average faster than platforms reach intrinsic adoption. When the champion leaves, the platform discovers that it appears in no one’s objectives. Data teams are measured on data products shipped. Governance is measured on audit findings. Infrastructure is measured on cost and uptime. The platform improves all three sideways and belongs to none of them.

The unglamorous fix is to make adoption someone’s explicit job, with the budget that implies. A Red Hat consultant’s postmortem of stalled platform efforts reports one large organization spending roughly a third of platform team capacity on marketing and enablement: onboarding sessions, office hours, internal sales. Engineers hear “a third of capacity on marketing” as waste. It isn’t. It’s the actual cost of adoption that the demo hid. The same postmortem notes a subtler failure: optimizing for developers while someone else entirely (in data organizations, usually the CDO office or domain leads) controls the adoption decision. Building for the user while ignoring the buyer is a classic enterprise software mistake, and an internal platform is enterprise software with exactly one prospect.

What surviving looks like

If I compress all of this into what I’d actually do differently on the next data IDP: I’d instrument the baseline before writing the blueprint (you cannot show a before/after without a before; 29.6% of teams never can). I’d show the sponsor the J-curve on day one and agree on which quarter the dip is expected, so it arrives as a prediction fulfilled instead of a surprise. I’d staff a product manager before the third engineer, aim the first blueprint at the loudest existing pain, and treat the first three teams as design partners with names, not “the rollout.” I’d ship governance evidence generation as a feature in release one. And I’d write the platform into the goals of the people whose behaviour has to change, because a platform that’s in nobody’s OKR is in nobody’s interest to save.

When this doesn’t apply

Small organizations mostly don’t have this problem; with two data teams, adoption is a lunch conversation, and I argued last time that below a certain scale you shouldn’t build an IDP at all. Mandates, which I’ve been rude about, do have one honest use: a regulated baseline (every data product must have classification and an owner) can legitimately be decreed, as long as the mandated floor stays thin and the platform earns everything above it. And genuinely green-field organizations get a temporary exemption from the ticket queue problem, since there’s no incumbent queue to defend. Give it a year.

Where this leaves us

The first article argued that the missing layer of your data platform is a product. The uncomfortable corollary is that products don’t fail at the feature list; they fail at distribution, pricing, and politics. The blueprint, the portal, the scaffolding, all of it is the feature list. Distribution is the platform team doing internal sales it didn’t sign up for. Pricing is the funding model surviving the J-curve. Politics is the ticket queue, the autonomy fight, and the gate.

Platform engineering keeps relearning what every product company knows: build is the easy half. The organizations whose data IDPs are alive three years in aren’t the ones with the best blueprints. They’re the ones that staffed the boring half.