Measuring platform engineering: is the platform team actually working?

You staffed a platform team to make every other team faster. The common problem: the promise was that an hour spent there saves many hours here, and nothing in the organization measures whether it did. This page covers how Aurora Coach closes that gap, and ends with the adoption pulse and the wrong-problem signals, free.

Funded on a multiplier, judged on provisioning counts

A platform team is funded on a multiplication argument: an hour spent here saves more than an hour across the teams it serves. It is often the right bet, and it is the only thing that justifies taking senior engineers off work customers can see. The bet is also almost never re-checked, because the cost sits in one headcount line and the return is spread across teams that never attribute it to anyone.

What gets reported instead is provisioning: accounts created, repositories migrated, services onboarded. Those numbers rise whether or not the platform is helping, and they keep rising after it has stopped. Meanwhile the failure mode is rarely a bad platform. It is a competent platform solving a problem the teams do not actually have, adopted on paper and worked around in practice.

The signal that would tell you exists, but nothing collects it. When a team hits a wall, building a narrow version of what it needs is usually faster than waiting for the general one, so it does that and moves on. No ticket is filed. No survey question covers it. From inside the platform team, a year of this looks like a period when complaints went down.

Both halves of the fix are already written down. In Team Topologies, Skelton and Pais make the platform one of four fundamental team types and argue for a thinnest viable platform: only what measurably accelerates other teams, treated as a product with users who could choose otherwise. The CNCF Platforms Working Group turned the measurement side into a Platform Engineering Maturity Model with five dimensions, two of which are Adoption and Measurement. Neither is obscure. What is rare is an organization that revisits either one after the funding decision.

Nobody files a ticket to say they routed around you. They build their own and move on.

How Aurora Coach addresses it

The target is a platform the strongest teams choose. This work lives in Aurora Coach's Alignment domain, team enablement and strategic alignment, which covers tooling effectiveness, developer experience, and the persistent work of removing impediments that are invisible from outside a team. It is one of six domains of team effectiveness alongside Foundation, Product, Engineering, Operations, and Workflow.

  1. Sense + Analyze Context comes from the teams the platform serves, not from the platform team: the AI asks structured questions and each team answers in its own words. Workarounds surface here and almost nowhere else, because building your own is a decision people make in an afternoon and never report. The AI synthesizes it into a strengths-and-gaps read grounded in the actual situation.
  2. Recommend + Refine + Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote and the lead refines to fit reality. The AI’s job is to inform the decision, not to make it. Platform changes become commitments owned by the teams involved rather than roadmap items that outlive their reason.
  3. Execute + Re-evaluate The work happens alongside delivery. The next period’s analysis shows whether the workarounds went away, whether time-to-provision moved, and whether the strongest teams came back. Because every team runs the same loop, you see the platform from six angles rather than one. Context compounds.

The structural advantage is that the platform is assessed by the teams it serves, on the same cadence as everything else, rather than by a survey the platform team writes and runs. Free-text check-ins keep that channel open between periods. If the underlying question is whether the investment produced value at all, see output vs outcome; for the broader developer experience picture, the developer experience survey covers it.

How do you measure a platform team?

Not by provisioning counts, which go up whether or not the platform helps. Measure what the served teams do when the platform is not looking: what they built themselves that the platform was meant to provide, what they do when they hit a wall, how long it takes to go from wanting something to having it, and what they would lose if it vanished. Those are the signals that move before adoption numbers do. The CNCF Platform Engineering Maturity Model covers the same ground more formally, with Adoption and Measurement among its five dimensions.

What is platform engineering ROI?

The multiplication argument: an hour of platform work should save more than an hour across the teams it serves. It is usually a sound bet and it is almost never re-checked after funding, because the cost is visible in headcount and the return is spread thinly across teams that never attribute it. The practical version is to measure the return on the served teams rather than on the platform team.

Why do teams route around the internal developer platform?

Almost always speed rather than quality. If self-service takes minutes and anything outside self-service takes weeks, teams will design around what they can get today, and a strong team can usually build a narrow version of what it needs faster than it can wait for the general one. This rarely generates a complaint, which is why it goes unnoticed until a platform review finds two of everything.

The platform adoption pulse, free

Six questions, asked of the teams the platform serves rather than the platform team. Run it per team; an average across ten teams hides the two that have given up.

  1. What have you built yourself that the platform was supposed to give you? The single most informative question, and the one platform teams almost never ask. Every answer is a feature that exists twice and a team that decided asking was slower than building.
  2. Last time you hit a wall with the platform, what did you do? Filed something, asked someone, worked around it, or gave up. The ratio matters more than any individual story, and only one of those four generates a ticket you would ever see.
  3. What is the platform genuinely better at than what you would do alone? Ask for the positive case. A team that cannot name one thing is complying with the platform, not adopting it, and the difference is invisible in usage numbers.
  4. What would you lose if it disappeared on Monday? A cleaner read on real value than any satisfaction score. "We would be fine in a week" and "we could not deploy" are both useful answers and both actionable.
  5. How long from wanting something to having it? The number that decides whether teams route around you. If self-service takes minutes and anything else takes a fortnight, teams will shape their architecture to stay inside the minutes.
  6. What have you stopped asking for? The quiet end state of a platform that says no too often. Teams stop requesting, stop complaining, and stop counting as dissatisfied, which reads from the inside as things having settled down.

Four signals a platform is solving the wrong problem

None of these is fatal on its own and none of them shows up in a usage dashboard. Two or more together is worth a conversation before the next roadmap.

  • Adoption is mandated rather than chosen A platform good enough to want does not need a policy. Mandates are worth using deliberately, but they also destroy the only honest adoption signal you had.
  • The roadmap comes from the platform team Platform roadmaps built from internal conviction drift toward interesting problems. If you cannot trace the last three items to a specific team that asked, the drift has already happened.
  • Usage is broad and shallow Everyone provisioned, few dependent. Broad-and-shallow usually means the platform owns the easy first step and none of the work that follows it.
  • The strongest teams are the least engaged The most damaging signal on the list. The teams most capable of routing around you are exactly the ones who will, and they are the teams whose time the whole investment was meant to multiply.

Worth saying plainly: none of this is an argument against platform teams. The multiplication argument is usually correct. It is an argument against funding it once and never asking the served teams whether it arrived.

Not ready to change anything today? You already have the adoption pulse and the wrong-problem signals above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.

You have the adoption pulse and the wrong-problem signals above, yours to keep and to run without buying anything. It is also generic, as any page has to be. What it cannot tell you is which of it applies to your team, in your situation, this quarter. That judgement is the actual work.

That judgement is what Aurora Coach does. Your team supplies the context through Coaching Sessions and check-ins, in its own words, every period. The AI works from that context rather than from a template, and recommends specific next steps with the reasoning and how you will know whether it worked. The team decides and commits. The next period shows whether it held. This page is one problem in the Alignment domain. The loop runs across all six, with every team, every period.

What it costs to run: one Coaching Session per person per period, fifteen to twenty minutes, and a period defaults to four weeks with the team setting its own. What the team writes stays private to that person. Only the team-level picture rolls up to leadership.

Map your ROI Start free trial

Both are free. No signup, about two minutes.