Platform engineering fundamentals

Treat the internal engineers who use the platform as customers with a choice, not as a captive audience. Concretely, that means the platform team runs discovery before building a feature, tracks adoption rather than assuming a mandate will produce it, and accepts that a paved road nobody chooses to drive on has failed regardless of how well it was engineered. The alternative — building whatever the platform team believes infrastructure should look like and then mandating its use — produces compliant but resentful usage, and resentful usage is the leading indicator of the workaround that shows up eighteen months later.

An infrastructure team provisions and operates the underlying compute, network and storage; a platform team builds the self-service layer and the golden paths on top of it that let other engineers use that infrastructure without filing a ticket. The distinction matters because it changes who is being served: infrastructure serves the organisation's operational requirements, while a platform serves other engineers' daily workflow, and is measured by how much friction it removes from their work rather than by uptime alone. Many organisations run both functions inside one team, but conflating the two goals inside one roadmap is a common cause of a platform that is reliable and unloved.

Uptime alone tells you the platform didn't break; it says nothing about whether it's actually helping anyone, which is the number that determines whether the investment was worth it.

Metric                          What it actually tells you
-------------------------------  ---------------------------------------------
Weekly active users / eligible   Adoption, not just availability
Time from request to first use   Whether onboarding friction is real
Support tickets per feature      Where the self-service model is leaking
Deploy frequency, lead time      Whether teams are shipping faster because
                                  of the platform, not despite it
Voluntary opt-out rate           Whether teams leave the golden path and
                                  why, tracked explicitly rather than guessed

The metric worth resisting is a vanity number like total services onboarded, because it counts adoption at generation time and says nothing about whether those services still use the platform six months later. Voluntary opt-out is the uncomfortable one to track and the most honest, because a platform team that only measures what it built will never notice what got quietly abandoned.

A paved road is the platform team's recommended, supported way of doing something — the default CI template, the standard deployment pipeline — built to be clearly the easiest option without being the only one. It has to stay optional because forcing it onto a case it genuinely doesn't fit produces either a broken deployment forced into a shape it wasn't designed for, or a team that quietly forks the template and stops receiving any of its future updates. An enforced road produces compliance; an attractive one produces genuine adoption, and the two look identical in a rollout announcement but behave very differently a year later.

Because every speculative feature is built without a real user validating it, and it competes for the same limited engineering time as the feature an actual team is currently blocked on. A platform roadmap driven by "teams will eventually need multi-region support" instead of the specific team asking for a faster local development loop right now produces a platform that is broad and thin, technically covering many scenarios while poorly serving the scenario someone actually has today. The corrective discipline is building for a named team's named problem first, and generalising only once a second team hits the identical need.

Weigh the cost of integration and ongoing maintenance against the cost of building and then owning the equivalent forever, and weight that comparison by how close the capability is to your actual differentiator. A service catalog, a CI runner fleet, or a secrets vault are commodity problems solved well by existing tools, so building one from scratch is usually rebuilding something a vendor has already hardened against edge cases you haven't hit yet. The build case strengthens sharply when the requirement is genuinely specific to your organisation's constraints — a compliance rule no vendor product encodes, or an integration with a legacy system no product anticipates.

Rank by the product of how many teams are blocked and how completely they're blocked, not by who asked loudest or most recently, because a squeaky-wheel backlog optimises for internal politics rather than organisational throughput.

Request                        Teams blocked   Severity          Priority signal
------------------------------ --------------- ------------------ ---------------
Faster CI feedback loop        30 of 40 teams  Slower, not stuck  High reach, moderate severity
New compliance gate mandated   40 of 40 teams  Legally required   Non-negotiable, schedule first
Custom deploy target for 1 team 1 of 40 teams  Fully blocked      Low reach, high local severity

The genuinely hard case is the third row: one team fully blocked is a real problem for that team, but building a one-off integration to unblock it sets a precedent that the platform builds bespoke features on request, which does not scale as the number of teams grows. The usual resolution is to unblock that team with a manual workaround while declining to generalise the platform around a single team's need, and being explicit with that team about why.