Most platform budgets are approved on enthusiasm and audited never. The result, a year later, is a portal with four monthly visitors and a roadmap nobody defends. This checklist exists to prevent that outcome. Work through it before you commit money or headcount to PlatformOps, and be strict about the scoring: the audit is only useful if a “no” is allowed to stop the project. PlatformOps \u2014 the craft of running a shared engineering platform the way product teams run whatever they own \u2014 succeeds when the ground is prepared and fails loudly when it is not.<\/p>\n
One caution before the items: the audit tests readiness, not ambition. A failing score next to a genuine demand problem usually means “sequence the work”, not “drop the idea”.<\/p>\n
Two assumptions come before any tooling. The first is that DevOps basics already hold: teams run their own CI\/CD, someone owns each service, and delivery metrics exist somewhere beyond anecdotes. A platform cannot amplify practices that were never installed; it can only automate the chaos at higher speed.<\/p>\n
The second assumption is a product mindset. DORA treats platform engineering as a discipline that is sociotechnical at its core, and the operating expectation that follows is concrete: publish service levels, run support tiers, manage upgrades and retire old capabilities on schedule. Bottcher’s framing is the pithiest version \u2014 an internal platform must be compelling enough that teams choose it. And Team Topologies supplies the organisational frame, treating the platform group as one of four team types, with the explicit job of reducing cognitive load for the others. The Ops Atlas PlatformOps guide<\/a> gathers these definitions, and the audit below borrows its 30\/60\/90 adoption arc.<\/p>\n Score each item yes or no. Anything short of evidence counts as no.<\/p>\n Count the yeses. All of the demand signals plus at least three prerequisites: you are ready, and the 90-day plan above is your first quarter. Demand signals present but prerequisites missing: fix the basics first; a platform built on absent ownership inherits the absence. Fewer than three consuming teams with repeated needs: do not build yet \u2014 a documented wiki page and two shared scripts will outperform an idle platform at this size, and nobody should treat that as failure. The threshold matters in both directions, because the wrong “yes” costs two years of funding and the wrong “no” leaves four teams rebuilding the same pipeline forever.<\/p>\n Set expectations for the curve as part of the audit verdict. Delivery metrics typically dip while the platform lands, then climb past the old baseline; DORA’s research shows platforms can actively hurt throughput and stability when the operating model is neglected. A team that scores well but cannot tolerate a lean quarter should wait a quarter, not launch into a panic. Write the expected dip into the business case, with a date after which the metrics are judged \u2014 sponsors who have been warned forgive a trough; sponsors who discover it in a review deck ask whose resignation it carries.<\/p>\n Four patterns recur. The rebrand: an ops team renamed, queue intact, audit unrun \u2014 the pattern Thoughtworks flags as transformation theatre. The portal-first plan: buying interface software before confirming that anything behind it deserves self-service. The skipped inventory: teams build a deployment capability that quietly duplicates two in-house scripts from last year, and the first beta users point out the redundancy within an hour. And the silent mandate: every box ticked privately while the rollout memo already says “mandatory from next month”, which voids the pull assumption the whole model rests on.<\/p>\n A concrete scoring example shows why strictness pays. A 40-engineer company runs the audit: demand signals \u2014 yes, three product teams keep requesting identical pipelines; team shape \u2014 partly, nobody can name the interaction modes; prerequisites \u2014 yes on ownership, no on metrics; product discipline \u2014 yes until the funding question, where the budget covers six months. Verdict: not ready. The six-month funding line alone justifies the pause, because the platform would be abandoned exactly when GA support obligations begin. One budget conversation, held before launch, beats a public shutdown afterwards.<\/p>\n Audit discipline feels similar to trip planning, honestly. You would confirm where reliable local information comes from<\/a> before booking, check how to keep traffic from eating the day<\/a> before fixing a schedule, and only then decide how flexible the itinerary can be<\/a>. Same order of operations: verify the ground, then commit the plan.<\/p>\n Treat the checklist as an instrument, not a gate you pass once. Re-run it every quarter with the same scoring rules and keep the old sheets. Drift between quarters tells you more than any single result: prerequisites quietly decaying signals that ownership discipline is slipping, while a shrinking yes-list on demand may mean the platform is working \u2014 the duplicated toil has stopped appearing. Audit teams that keep history find trends; audit teams that keep only the latest sheet keep only opinions.<\/p>\n Ready means: repeated demand from three or more teams, ownership and metrics already in place, a charter with the thinnest viable scope, and a named person who will run support tiers without flinching. If the audit returns that combination, start the 90-day clock. If it does not, the checklist has already paid for itself \u2014 it told you which gap to close before the money moves, while closing it is still cheap.<\/p>\n","protected":false},"excerpt":{"rendered":" Run this audit before you budget for PlatformOps: demand signals, team shape, DevOps prerequisites, product discipline and a first-90-days plan.<\/p>\n","protected":false},"author":3,"featured_media":61,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-60","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/posts\/60","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/comments?post=60"}],"version-history":[{"count":1,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/posts\/60\/revisions"}],"predecessor-version":[{"id":69,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/posts\/60\/revisions\/69"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/media\/61"}],"wp:attachment":[{"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/media?parent=60"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/categories?post=60"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mumbaiorbit.in\/blog\/wp-json\/wp\/v2\/tags?post=60"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The readiness audit<\/h2>\n
Demand signals<\/h3>\n
\n
Team shape<\/h3>\n
\n
Prerequisites<\/h3>\n
\n
Product discipline<\/h3>\n
\n
Money and mandate<\/h3>\n
\n
The first 90 days, specified<\/h3>\n
\n
Scoring the audit honestly<\/h2>\n
Common audit failures<\/h2>\n
Re-running the audit later<\/h2>\n
PlatformOps readiness, in one line<\/h2>\n