Forty statements about your internal developer platform, each scored 1 only if you can point at the artifact that proves it. Eight sections, a total out of 40, and four bands that decide the next quarter: pave one path, fix adoption, prove the dividend in money, or stop and go fix delivery first.
The trap most platform teams walked into: pick the tool, stand up the catalogue, then look for something to put in it, so success gets measured in services registered rather than in time saved, and every consuming team quietly keeps its own pipeline because the golden path only ever covered the greenfield case.
What the platform teams who get adoption do: start from the four slowest steps between commit and production, delete the ticket queue instead of wrapping it in a nicer form, and pave the boring middle so that going off the path stays allowed, recorded, and genuinely slower than staying on it.
Score 1 only if the statement is true today and you can produce the artifact beside it. Planned, partial, true for one team, or true in a runbook nobody follows all score 0. There are no half marks, because half marks are the mechanism by which platform teams talk themselves into believing they are further along than they are.
Run it with the platform lead and a senior engineer from a consuming team who does not report to them. Score separately, then compare. Every gap between the two sheets marks a capability that exists on paper and not in practice, and those rows tell you more about the coming quarter than the total ever will.
The most expensive pattern we see is a strong AI score sitting on top of weak scores in sections A to D. It means AI has been added to a delivery system nobody measured, producing more code, faster, into a pipeline that cannot test it or roll it back. DORA measured stability falling as AI adoption rose.
Median lead time for change from the pipeline, the ticket count to ship one service, time to first commit for a new joiner, and a dated top-five list of developer complaints. The platform product owner brings them. A number estimated in a meeting is not a number, and section A scores zero without them.
Platform lead on one sheet, a senior engineer from a consuming team on another, forty statements each, no discussion until both are finished. Then walk only the rows where the two disagree and record each one in the weakest-statement column of the roll-up table. That column is the actual output.
Under 13 you have a delivery problem rather than a platform problem, and a portal would bury it. Thirteen to 22, pave one path end to end for one workload type. Twenty-three to 31, adoption is the job. Above 32, prove the dividend in money before the next budget round.
Take the three lowest-scoring statements and write the smallest change that turns each into a 1, with a named owner and a date inside the quarter. Anything longer than a quarter is a programme, not a next step, and it needs splitting before it goes anywhere near the platform roadmap.
No, and a low score is useful either way. Under 13 the assessment tells you to spend the quarter on lead time, ticket count and rollback rather than on a platform at all. That answer is considerably cheaper to receive now than two quarters into portal work nobody adopts.
Fair objection, with one difference. Every statement names the artifact that proves it and the condition that scores zero, so the sheet cannot be filled in from intent. Maturity models ask what you have adopted. This asks what a developer got without filing a ticket, which is the only question adoption answers.
That is the point. The gap is the finding, not an error to reconcile. Each disagreement marks a capability that lives in a runbook rather than in practice, and those rows go straight into the weakest-statement column. Teams whose two sheets match usually never asked anyone outside the platform group.
Two hours of scoring, plus the week it takes to gather the four numbers in section A. Most of the pain sits in that week, because the lead time median and the ticket count usually do not exist anywhere. Gathering them tends to surface the first fix before anyone scores a statement.
VPs of platform engineering and the people who fund them. It assumes you have an internal developer platform or a budget line for one, adoption you cannot fully explain, and a need to say in one page whether the next quarter goes on building, on adoption, or on delivery basics.
Drop your details and we'll send 80% Of Engineering Organisations Will Run A Platform Team. The Ticket Queue Survives. straight to your inbox - no spam, unsubscribe anytime.
Book a 30-minute platform review (logiciel.io)
Download the assessment