Who runs it?
The demo shipped. The repo is green. The staging environment holds. The CI passed. The system is in production, in a cloud account, serving real traffic.
Now a question nobody asked during the sell arrives at the door.
Who runs it?
The tactical version of that question is easy. Who maintains it. Who patches a CVE. Who is on call this weekend. Those answers have standard shapes. The strategic version is harder. Over the next year, as this system changes, scales, grows new features, takes on new clients, connects to upstream systems, survives an outage, drifts from its original architecture and eventually needs a successor, who holds it?
This is Step 3. Most AI content stops at Step 2 and treats Step 3 as a training problem that happens after the real work. It is not. And the traditional answer to it is backwards.
Step one and step two
You know Step 1. AI gave it to everyone for free: an assistant in your editor, a notebook, a prompt that generates a starter project in twenty minutes. Step 1 is the demo, the prototype, the screenshot, the look-at-this moment. Almost every post about AI is about Step 1.
Step 2 is the long jump. Step 2 is the running system: a real Git workflow, pull requests reviewed by people, the work decomposed in Jira, deployments to real infrastructure, tests that catch real regressions, and observability that catches what the tests missed. Most coverage stops celebrating somewhere inside Step 1 and never names Step 2.
Step 3 is the mature team. It is a gap as wide as Step 2 was, hidden behind the Step 2 victory.
The gap nobody writes about
A production system is not the end of the work. It is the start of a different kind of work. The Principal who shipped it knows the shape of every file: which phase wrote which module, which decision explains which part of the architecture. They can open any log and read what happened there, because they were there when it happened.
None of that transfers through a README.
When the system is handed to the next person, it goes over as a working build and a set of written instructions. The next person has to derive the shape by reading it, running it and repairing it. That takes months, and during those months the system is fragile in ways that are not anyone’s fault. It is a fragility of context.
Scale that across a team. A head of engineering who inherits a production system from a small build team faces an uneven transfer. The builders hold context gathered while building. The inheriting team has to unpack it in the weeks before the next thing has to ship.
The traditional answer, and why it is backwards
The usual response to Step 3 is: train the team on cloud operations first, then hand them the system. AWS, Kubernetes, infrastructure as code, observability stacks, incident response, capacity planning, cost and compliance. A course catalog and a certification path. Then, and only then, “it’s yours now.”
This is backwards, and it fails for two reasons.
First, the training is abstract. People learn the cloud on a sandbox account that looks nothing like the account they will run. The habits they build do not map to the habits they will need on the first day they actually hold the system. They come out of training feeling ready and discover on the first incident that ready was a feeling, not a capability.
Second, the timeline does not work. The system is in production now. Clients are using it now. Every day the team is not yet ready is a day of continuity risk sitting on the person who built it, who cannot move on because they cannot yet leave.
Backwards from the solution
So we start from the running solution and form the team around it.
The system is built to run in a cloud account the team will hold, and the handover transfers it. Its secrets live in the account’s secret store, never in an image. On Madstone’s build, the service went into a cloud account behind a sign-in gate, its secrets into Secrets Manager, and the two keys it runs on stayed theirs (a launch engagement, handed over).
Read · a launch engagement, handed over
Nothing is reached by opening it up. Every machine we run has no inbound rules, no SSH key and no password; it is reached through the cloud provider’s own session service, and its credentials come from the customer’s account, never ours. We call that a Wormhole.
A new operator does not start by learning “what is Kubernetes.” They start by watching what this system is doing: what is running, where each piece was sent, what each machine is for, and what it costs to keep it up. The account view shows every machine the Fleet runs, running or asleep, and says when one has been stopped with no reason recorded. Each person can have a Ghost: their own StellarView in the cloud, behind their own login.
Read · Every claim cites a fact
This is not a training program. It is an operating environment that produces trained operators as a side effect of holding the systems they are supposed to hold. Competence grows by operating, not by rehearsing.
The team forms around the system
The order of operations matters.
In the old model, the company has a team, the team has skills, and the skills decide what the team can hold. If the team does not know AWS, the company cannot hold an AWS-native system, and hiring for AWS comes first.
In this model, the company has a system, the platform provides the operating surface, and the team grows into it. The skills are shaped by the system, not the other way around. A team does not need to know Kubernetes before it can hold a Kubernetes-native system. The platform holds those parts while the team develops an instinct for this system, and the fluency builds up from operating the real thing.
The team is trained in the meetings it already holds: Sprint Planning, refinement, the Sprint Review and the retrospective, with the agents at the table and a person deciding. What it learns from is the record of how the system was built.
Read · The Living Curriculum, the handover
What the handover holds
When the work changes hands, what moves is everything it produced: the repository and its record, the films, and the cloud it runs in. On Madstone’s build that meant a company wiki in their own Confluence, with the platform, the runbook, the path from a page to Git to the cloud, a security control matrix and the first ninety days for a new hire. Where the wiki describes something not built yet, it says so.
The cost of getting Step 3 wrong lands in two places. For a builder, it is the build that will not let go: still on call long after the work was supposed to be done. For a team inheriting a platform, it is continuity risk: the system runs because it was built to, but nobody can say why it was built that way, and the first change to it happens by accident. Accidental changes to production are how outages start.
The question to ask before you build
If Step 3 is a real concern for you, the question to ask is not “who will we train to run this?” The question is:
What shape of system is my team going to form around?
That question reframes the build. It changes what you architect for: observability over elegance. What you document: how it is operated, not only how it was implemented. What you hire for: people who can read a system under load, not people who memorized the runtime.
The Modern Principal does not ship a system and then ask who runs it. They ship it with the answer already forming around it: backwards from the running solution, with the team growing into the shape of the thing.
That is Step 3. Most of the practice is still ahead of us, because most of the industry has not yet noticed the gap is there.
Enter the practice
- If you want who builds this way: read The Modern Principal.
- If you want how a team learns it: read The Living Curriculum.
- If you want a handover on the record: read a launch engagement, handed over.
- If you have a system to build, or one already running: bring your documents.