The platform capability lifecycle

Every engineering org can recite the software development life cycle in its sleep: plan, build, test, ship, run, learn, repeat. It's the shared vocabulary for how code gets from an idea to production. What almost no org has is the equivalent model for the thing code runs on: how an engineer goes from "I need a database" to a database that exists, is configured correctly, is secured, is monitored, and is someone's problem to keep alive. Call it the platform capability lifecycle: the path a raw infrastructure need takes from request to running capability, and back down to decommission.

Most orgs don't have this path designed. They have whatever happened when the first few engineers needed infrastructure and figured it out themselves.

The rockstar problem

Take a senior backend engineer. He's full-stack when he has to be, but his strength is data, specifically Postgres. He doesn't need a tutorial. He knows which extensions he wants, how he'd partition the tables, and which connection pooling setup won't fall over under load. Give him a terminal and twenty minutes and he'll have a database that's better tuned than what most platform teams would hand him by default.

Put the same engineer inside a 4,000-person enterprise and ask him to get that database provisioned the "supported" way.

He opens a ticket. The ticket routes to a queue he can't see the position in. Three days later someone asks which subscription it should live in. He answers. Two days after that, security asks whether the database needs to be reachable from outside the VNet. He answered that in the original ticket, but the intake form didn't have a field for it, so it got lost. A week after that, he gets access, and the database that shows up isn't the one he asked for: wrong version, no read replica, default parameter group, because whoever provisioned it was following a checklist for "a database," not for his database.

Two and a half weeks, for a task the engineer could have finished from the CLI in the time it took to write the ticket.

The other version of this story is just as common: there's no ticket queue at all. The org's answer to "self-service" is "here's the Terraform repo, go." So the rockstar, who has never had to touch Terraform because Postgres was always someone else's job to provision, now has to learn a second discipline just to practice his first one. He reads the module docs. He gets the provider version wrong. He runs plan against the wrong workspace and spends an afternoon figuring out why the diff shows twelve resources he didn't touch. He finally applies, and it fails halfway through on a resource that already existed, because someone else touched the same state file that morning. None of this taught him anything about Postgres. All of it was tuition he paid to learn infrastructure-as-code tooling well enough to do a task he was already an expert at, one layer up.

Worse, those hours go to work he wasn't hired for. Every hour spent debugging a Terraform state lock is an hour not spent on the schema design, the query optimization, the value-generating work the business is paying a senior backend engineer's salary for. The org loses the time of its most expensive, highest-leverage person, spent on a skill it didn't need him to have.

Whether it's two and a half weeks in a ticket queue or two and a half days fighting a tool he didn't sign up to learn, the failure is the same: the org made "get a database" a task that requires either someone else's queue or a new skill, instead of a task that requires neither.

So the slow ticket queue isn't the story. The organization never designed the thing this post names. It accumulated a process by accident, and the accident happens to everyone who touches it.

Why this scales worse than people expect

One engineer losing two and a half weeks is a bad month. The reason it matters at the company level is that this exact sequence (request, wait, clarify, wait, receive the wrong thing, correct it) repeats per engineer, per capability, per environment, completely independently, because there's no shared path doing it once on everyone's behalf.

cost = engineers × requests/year × hours lost per request × loaded hourly cost

Put real-ish numbers on it for a mid-size enterprise: 800 engineers, each requesting infrastructure a conservative 6 times a year, losing even 8 hours per request to the wait-clarify-correct loop (not 2.5 weeks, only the actively-blocked hours). That's 38,400 hours a year, roughly 19 FTEs' worth of time, spent on the process of getting to the database instead of on the database.

That number doesn't even include the "here's the Terraform repo, go" version of the story. Add the time engineers who aren't infra specialists spend climbing the IaC learning curve (reading module docs, debugging state locks, fixing a plan that touched the wrong workspace) and the number is higher and worse-shaped: it's concentrated in the engineers who are best at other things, because they're the ones who never had a reason to build Terraform fluency before the platform made it a prerequisite. Nobody sees any of this on a budget line, because it isn't one line. It's a thousand small delays and a thousand small detours into a tool that wasn't the job, scattered across every team, invisible to any single manager because no single manager owns the whole path.

This is the same shape of finding as the hidden cost of developer friction, but the capability lifecycle is the mechanism underneath that cost.

The stages

The SDLC has named stages because naming them is what let the industry build tooling, metrics, and shared expectations around each one. The platform capability lifecycle needs the same treatment:

• Request: the engineer expresses a need. In a mature platform this is a self-service catalog entry with real parameters, not a free-text ticket someone else has to interpret.
• Provision: the capability gets created. This is the only stage most "platform" efforts optimize for, which is why so many platforms feel done at 20% complete.
• Configure: the extensions, sizing and networking the engineer needed, the things that make it his database and not a generic one.
• Secure: guardrails applied automatically, not bolted on after a security review finds the gap. Encryption, network isolation and access scoping come with correct defaults, instead of wrong defaults that get flagged later.
• Observe: the capability reports its own health from day one (metrics, logs, cost, ownership) so nobody has to go find it before they can support it.
• Operate: patching, upgrades, backups, on-call. The capability keeps running long after the person who requested it has moved to a different team.
• Decommission: the stage almost nobody designs for, which is why enterprises accumulate thousands of forgotten resources that exist purely because nobody could cheaply confirm they were safe to delete.

A golden path is what you get when all seven stages are designed as one continuous path instead of seven separate teams each owning one link in a chain nobody drew. That's the difference between a golden path and a portal. A portal can make the request stage self-service and still leave the other six stages as manual and disconnected as before.

What "self-service" has to include

Self-service infrastructure that only handles the request and provision stages is a faster on-ramp to the same manual process, because the engineer still has to configure it, chase security sign-off, set up monitoring, and remember the thing exists when it's time to retire it. The rockstar engineer in the story above didn't need help with any of those individually. He needed the org to have solved them once already, as defaults he could opt into, instead of solving them himself, again, on this particular Tuesday.

Measure a platform's maturity by how many of the seven stages the engineer never has to think about, rather than by how fast the request stage is. That also tells you how much of his time stays on the work he was hired to do.