A lean AI team earns praise only when critical workflows can be recovered by more than one person. If one exhausted engineer is the only person who can restore the product when it fails, the team is lean on paper and exposed in practice.
The compliment came during a board meeting: we had kept the AI team small while shipping. That sounded like discipline. In a market where runway can disappear while you are waiting for a customer decision, it is usually the right instinct.
Then someone asked who could recover a critical workflow if it failed during a customer session.
There was one name.
He knew the model prompts, the fallbacks added after earlier failures, the customer-specific exceptions, and the part of the workflow that required a human approval before anything reached a customer. He had earned that knowledge by carrying the product through releases. He was also tired.
The board conversation changed quickly. The problem was not headcount. It was that our operating model had turned one person’s memory into production infrastructure.
The team that saved Apollo 13 had to make the fix usable
In 1970, Apollo 13’s crew faced rising carbon dioxide levels after an explosion crippled the spacecraft. The lunar module had lithium hydroxide canisters, but the command module’s square canisters would not fit the lunar module’s round receptacles.
At NASA’s Manned Spacecraft Center in Houston, Ed Smylie led engineers working on an adapter made from materials already available to the astronauts, including cardboard, plastic bags, tape, and a flight plan cover. The crew had to assemble the solution in space from instructions relayed from Earth, while the mission’s outcome was still uncertain.
NASA documents the episode in its Apollo 13 mission history. The famous improvised adapter mattered because it could be understood and used under pressure. A brilliant fix sitting in one engineer’s head would not have brought Jim Lovell, Jack Swigert, and Fred Haise home.
That is the standard a critical AI workflow should meet. When the person who knows the recovery path is unavailable, someone else must be able to identify the failure, make a safe decision, and restore service.
Lean teams need shared recovery paths
The AWS-commissioned study of more than 3,400 startup leaders points to a real shift: AI-native companies are growing with smaller teams, and 68% report having a formal AI strategy. Smaller teams can move quickly because they make fewer handoffs and carry less coordination overhead.
But a formal strategy does not tell you who owns recovery at 9 p.m. when an agent gives the wrong output, an integration stops returning data, or a customer-specific workflow starts routing work to the wrong place.
In an early-stage company, the person who built the system will often be the fastest person to fix it. That is normal. The risk begins when speed becomes an excuse to avoid documenting the decision path.
We had treated the engineer’s ability to intervene as evidence that the workflow was under control. It was evidence that he was under control. Those are different conditions.
A resilient workflow needs more than code review. It needs a named owner, an escalation path, a clear record of which actions require approval, and a recovery procedure that another engineer or product lead can follow without guessing. What Happens When Everyone Approves the Code but Nobody Owns the Workflow? gets at the ownership gap from another angle.
Turn one person’s knowledge into an operating asset
We did not respond by hiring immediately. A new hire would have added capacity, but it would not have removed the single point of failure on its own.
We started with the workflow most likely to create customer damage if it failed. We mapped its inputs, model instructions, integrations, approval points, fallback state, and the customer-facing consequences of each failure mode. Then the engineer who knew it best walked another person through recovering it.
The test was deliberately unglamorous: could the second person restore the workflow from the written record while the original builder was present only to correct omissions afterward?
The first pass exposed the real issue. Important decisions lived in shorthand. A note saying “use the usual fallback” meant something to the builder and nothing to anyone else. A prompt change had been made for a specific customer problem, but the reason was absent. An approval step existed in the interface without a clear explanation of what should happen if the approver was unavailable.
Those are manageable gaps when you find them before a failure. They become expensive when a customer is waiting and the only person who understands the system is asleep, travelling, or already working on another incident.
Board reporting should include recovery risk
The next board update needed a different measure of leanness. We could still report what the small team shipped. We also needed to report which critical workflows had a documented owner, a tested fallback, and at least one trained backup.
That changes the conversation from “How few people can we run with?” to “What can this team safely carry?”
For founders in Accra, Lagos, Berlin, London, or the US, the pressure to keep payroll tight is real. So is the pressure to ship an AI demonstration before a larger competitor takes the meeting. Neither pressure disappears because you add a runbook.
What changes is your ability to make a responsible trade. You can decide to keep a team small while knowing exactly where the risk sits. You can delay a feature because the workflow behind it has no recoverable path. You can also see when hiring is genuinely necessary, rather than treating every incident as proof that you need more people.
Apollo 13’s adapter worked because the ground team translated expertise into instructions astronauts could execute with what they had. Your version may be a recovery checklist, an approval rule, a test environment, or a second engineer walking through an incident. Build it before the compliment reaches the board deck.
Comments
No comments yet.