Platform Engineering & Internal Developer Platforms

The bill that came due

For about ten years we told every team the same thing: you build it, you run it. It was the right correction at the time. The wall between developers and a separate operations group had become a place where empathy went to die, and tearing it down shortened feedback loops, gave engineers a real stake in production, and ended a lot of the finger-pointing that used to pass for an incident review.

But the bill for that arrangement was paid quietly, in a currency nobody put on a dashboard. To run what they built, a product team now had to carry Kubernetes, Terraform, CI pipelines, secrets, observability, networking, IAM, cost controls, and the dozen brittle tools that hold those together. None of that ships a feature. It is the price of admission, and every team paid it independently, over and over, until the cost of ownership compounded into something the industry could no longer pretend was free.

I have watched a team meant to build a checkout flow spend its week debugging an ingress controller. No ticket ever said “blocked by accidental complexity,” so the slowdown stayed invisible while it spread everywhere at once. That is the real failure mode, and it has a name: cognitive load.

Attention is the scarce resource

The useful frame, borrowed from Team Topologies, is that a team’s mental capacity is finite and splits into three buckets. There is intrinsic load - the domain logic you are actually paid to build. There is germane load - the patterns that make the domain tractable, worth a bit of investment. And there is extraneous load - remembering kubectl flags, wiring CI YAML by hand, decoding IAM policy syntax. That third bucket is pure overhead, and every hour it grows is an hour stolen from the work that matters.

Platform engineering, stripped of the conference gloss, is the discipline of shrinking the extraneous bucket. Not by giving developers more power - they already have too many levers - but by giving them back the attention they were spending on things that were never their job.

The reframing that changes everything

Here is the shift that separates platforms that get used from internal tools that get resented. Stop thinking of the platform as infrastructure. Start thinking of it as a product whose customers are internal developers - and, crucially, customers who can say no.

In a healthy organization, your users are volunteers. A stream-aligned team can ignore your platform and assemble its own pipeline if yours is worse. Engineers raised on mandatory infrastructure find this deeply uncomfortable, and that discomfort is exactly the point. Because adoption is voluntary, you have to earn it. Earning it forces you to build something genuinely better. The moment you make the platform mandatory to paper over the fact that it is not good enough, you destroy the one feedback signal that would have told you so. Mandates hide failure. Voluntary adoption surfaces it. If you ever feel the urge to mandate your platform, file that urge as a defect report against the platform itself.

Golden paths, not gates

The mechanism that makes voluntary adoption work is the golden path - Spotify’s term, what Netflix called the paved road. A golden path is a supported, opinionated, well-documented route through a common task, create a service, add a database, ship to production, that is so much easier than the alternatives that developers take it willingly. The standardization is real, but it arrives as a side effect of convenience rather than coercion. A golden path you are forced onto is a policy. A golden path you choose because it is the fastest way to get your job done is a platform. The words are identical; the engineering could not be more different.

This is also why the strongest anti-pattern is the platform that quietly becomes a gate. It starts innocently - all deploys must pass through our pipeline so we can enforce security - and ends with the platform team as the bottleneck every change waits on. That is the operations wall DevOps tore down, rebuilt in YAML. Enforcement is legitimate, but it belongs in guardrails, not gates: policy-as-code that rejects an insecure config at commit time, defaults that are secure unless deliberately overridden, paved roads that are compliant by construction. The developer never waits on you. The system simply makes the right thing the easy thing.

Build the thinnest thing that helps

The most expensive mistake I see is ambition. A team sets out to deliver a portal, a scaffolder, Crossplane, GitOps, and a CLI in the first quarter, and two years later has a beautifully architected platform that nobody uses. The antidote is the thinnest viable platform: the smallest thing that actually reduces a real team’s cognitive load. It can begin as a curated wiki page and one script. It earns the right to become software only by proving the path is wanted.

So pick one golden path - usually create a service and get it to production, because every team does it and most do it badly. Pick one or two friendly pilot teams. Make the path end to end and real, because a half-path that drops a developer into manual steps is worse than no path at all; it breaks trust. Then let demand pull the next thing into existence. When a third team asks to use what the pilot has, without being told to, you have product-market fit, and only then do you build path number two.

And build only what is specific to you. Your company has no special way of running a container, so adopt that. It does have a particular compliance regime, service catalog, and set of golden paths - so build that, and integrate the commodity parts. Prove it with delivery metrics and developer experience together, never one alone, because speed bought by burning out the platform team is a loan that always comes due.

A platform has succeeded when developers reach for it without being told to, when the easy way and the right way are the same path, and when delivery gets faster while developers’ days get lighter at the same time. Everything else is just plumbing.