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 actually 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. That's the gap this post is about.

The rockstar problem

Picture a senior backend engineer. Full-stack when he has to be, but his real strength is data — specifically Postgres. He doesn't need a tutorial. He knows exactly what extensions he wants, exactly how he'd partition the tables, exactly what 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.

Now put him inside a 4,000-person enterprise and ask him to get that same 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 — a question he answered 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 himself could have finished from the CLI in the time it took to write the ticket.

Or — the other version of this story, 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.

That's the part that stings on a spreadsheet: those hours aren't just lost, they're lost doing 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 actual value-generating work the business is paying a senior backend engineer's salary for. The org doesn't just lose the time — it loses the time from its most expensive, highest-leverage person, spent on a skill it didn't need him to have.

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 — either way, 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.

That's not a story about a slow ticket queue. It's a story about an organization that never designed the thing this post is naming — it just 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 — just the actively-blocked hours). That's 38,400 hours a year — roughly 19 FTEs' worth of time — spent not on the database, but on the process of getting to 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 real 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, not just another restatement of it.

The stages, named properly

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 actually 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 specific shape the engineer needed: extensions, sizing, networking, 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, access scoping — defaults that are already correct, not defaults that are already wrong and get flagged.
• 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 part that's still 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 actual difference between a golden path and a portal — a portal can make request self-service and still leave the other six stages exactly as manual and disconnected as before.

What "self-service" actually has to include

Self-service infrastructure that only handles request and provision isn't self-service — it's a faster on-ramp to the same manual process, because the engineer still has to manually configure, manually chase security sign-off, manually set up monitoring, and manually 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 already solved them once, as defaults he could opt into, instead of solving them himself, again, on this particular Tuesday.

That's the actual measure of a platform's maturity: not how fast the request stage is, but how many of the seven stages the engineer never has to think about at all — and, by extension, how much of his time stays on the work he was actually hired to do.