Keep what you learned

The story

A quiet quarter.

After the annual warranty-renewal wave, the requests stopped. The template onboarding service, the small team Tomás Reyes and Kofi Mensah ran for Warranty Claims, had nothing to onboard. Its job was to tune the shared base to each new contract template and re-run Priya Natarajan's 400-annex test, and no new template had come in. For three weeks nobody opened a ticket. In a company of six thousand people, it was the quietest corner on the map.

Helen Brandt noticed, because Helen notices lines in a budget that do not move. She asked Maya Okafor, politely, why she was paying for a team that had no work. She added that she was not asking for a closure. She was asking for the reason.

Maya had expected the question and had brought two numbers. In the research's own illustrative units, which she read for the story as engineer-months, keeping the service team warm through a quiet quarter cost 1. Closing it and reopening it when work came back cost 1.5. That was the cost of letting people go, finding them again, retraining them and rebuilding the habits and the access.

“So keeping them costs less,” Helen said.

“For one quiet quarter. For two it costs more.”

The forecast said one. A product recall that would generate new annex work was scheduled for the next quarter. Maya kept the team.

The recall slipped. A regulator asked for more time. Instead of a second busy quarter, Hartwell faced another three quiet ones. At that point the arithmetic changed: three quarters at 1 each is 3, against 1.5 to close and reopen. Maya closed the service. She kept the failure record, kept Kofi on half time with Platform, and kept the human fallback procedure that Warranty used when the model could not be trusted. The service team stopped. The capability did not.

The wrong forecast cost one unit. Had she closed at the start she would have paid 1.5; as it happened, she paid 1 for the first quarter and 1.5 for the closure. Helen asked whether that was a mistake. “It was a bad forecast and a good rule,” Maya said. “I would make the same decision on the same information, and so should you.”

The problem

The cost of closing is the number managers leave out.

When demand falls, there are two easy mistakes. One is to protect everything, because anything idle might be needed later. The other is to cut anything idle, because it looks like waste on a spreadsheet. Both come from comparing the wrong things.

The honest comparison has two sides. On one side is what it costs to keep a capability available while nothing is using it. On the other is what it costs to close it now and rebuild it later. The second figure is usually missing. People price the saving from closing, and they forget the invoice for reopening.

A second problem sits behind the first. Some things a company keeps are valuable precisely because they are rarely used. The backup procedure for the day the model cannot be trusted. The record of a failure that will recur in two years. The one person who knows how the old system worked. Nobody would pay for these out of their own budget on the strength of today's use. The benefit goes to whoever needs them on the day, and that is usually somebody else.

What the research shows

A short lull keeps the service. A longer one closes it.

The lesson on keeping capability has three results, and I find them more useful together than separately.

First, the quiet-gap rule. Take a service that is needed, goes quiet, and is needed again. Suppose that keeping it running costs a fixed amount per quiet period, and closing and reopening it costs a fixed amount once. Then keeping it is the better plan exactly when the running cost over the gap is below the close-and-reopen cost. In the lesson's checked cases the answer flips with the length of the gap: with one quiet period it is cheaper to keep the service, with two it is cheaper to close it. Lean checks both cases. The rule needs an honest premise: that the assets survive the closure and the restart works. If people leave or knowledge decays during the gap, the rebuild costs more.

Second, a band where you do nothing. Opening a service and closing one have different costs. That makes a band of situations where the best move is to leave things as they are. The lesson states this as a general idea, not a proved result, so I treat it as a proposal. It is still useful. A company that opens and closes in response to every wobble in demand is paying the switching costs over and over.

Third, insurance has no buyer. The lesson's preservation game has two teams. Each could pay for a backup record or an apprentice, and each would benefit from the other's. In the checked case, neither invests, even though investing together would be worth it. Two things fix it, and neither is a department. A shared budget pays for it. Or an enforceable agreement between the teams splits the cost. Both work, but not for free: if the governance for the shared option costs more than the gain, the gain reverses. The decision is whether the insurance is worth its upkeep, not whether to create a body to hold it.

As always, the models give the same answer to an equally capable local arrangement with the same information and costs. Nothing here says ACM must hold the insurance. It says someone must pay for it.

The framework

The Capability Portfolio.

The category managers at consumer-goods companies had a good insight, which I have borrowed: do not manage a pile of things, manage a portfolio in which each item has a job. At Hartwell, the thing being managed is document-reading ability. It is not one model. It is a shared base, local adaptations, tests that check the answers, a collection of failure notes and a human fallback for when the machine is not to be trusted. They do different jobs, and it would be silly to judge them by the same measure.

Two questions sort them. How often is it used? What does it cost when it is not there?

Workhorse. The shared document-reading base is used every day and would hurt to lose. It deserves a standing team and a hard measure: how long from a team's request to a use the team accepts.

Commodity. Finance's document tools are used often and are replaceable. Buy them, or let the platform team run them. Do not give them ACM attention.

Insurance. The human fallback for missed exclusions, the failure notes and Kofi's trained judgment are used rarely. A single missed exclusion would be expensive. These are the things a utilization chart shows as waste. Keep them warm and measure readiness: could they be used tomorrow? The measure is a test of readiness, such as a drill, and not a count of uses.

Let lapse. A regional chatbot prototype from the year before was used once and was cheap to rebuild. Archive its record, write down the date you stopped, and move on.

The shape is borrowed from the familiar growth-share matrix, but the axes and the meaning of the cells are different. It is a reading aid, and the cell a capability belongs in is a judgment you should defend aloud.

An owned conviction

End the engagement. Keep the capability.

The strongest evidence I can offer here is my own research. With Karan Girotra and Stefan Mihm, I studied how companies set their research and development budgets over time. The paper, R&D Spending: Dynamic or Persistent? (2019), reports that firms that moved their spending around more tended to have poorer patent performance. The harm was concentrated in unpredictable changes. Familiarity with the technical base, and how far the new work departed from established methods, changed the picture.

I should be careful about what that does and does not show. It is observational. It is about patents and R&D budgets, not AI teams. It does not prove that flexible service provision is harmful. This chapter draws only on what the paper's abstract states.

What I took from it is a way to organize. Separate the thing that should be stable from the thing that should be flexible. The capability, meaning the people who have practiced, the records and the habits, should be stable and funded predictably. The engagements, meaning who is working on what, for which team, for how long, should be flexible. Ending an engagement need not end a person's practice or erase a record. The expensive mistake is the surprise cut that destroys the capability to end an engagement.

Hartwell's quiet quarter shows it. The engagement, the template onboarding service, stopped. The capability stayed: the record, the human fallback and Kofi's judgment. When the recall work arrives, reopening will be a restart and not a rebuild.

The second framework

Open, Keep, Transfer, Close.

Every asset the AI Capability Manager touches is somewhere in a short life. A test funded in March, a shared base, an evaluator, an onboarding team. The life has four stages, and the question at each is who is accountable for it now.

Open with a question, an owner, a budget and a review date. If you cannot name the review date, you are opening something that never closes.

Keep it while it earns its cost. This is where the quiet-gap rule applies: ride out a lull if idle running costs less than the rebuild, and do not reorganize on every dip.

Transfer when someone else should own it. The receiver must accept the scope, the capacity, the migration and the retirement. Approval to build is not approval to maintain. A shared asset that nobody will accept to maintain has already told you something.

Close deliberately. Archive the record, release the people to work they want, and stop the spend. A closure without an owner for the record is a deletion. Give the record a refresh date, because a record kept in a context that has moved on can mislead the next team.

The loop matters as much as the line. If the work comes back, reopen from the record. That is the difference between a closure and a loss.

The four stages are my framework. The cost comparisons at Keep and Close come from the continuity model; the stages themselves are not a theorem.

When to close

A large department can defend its own workload.

Nothing in this chapter should be read as a case for keeping things forever. The same logic that keeps insurance warm should close the thing that has stopped earning its cost. And an AI Capability Manager, like any owner, has a conflict of interest here. A function that exists to hold things tends to find reasons to keep holding them.

That is why I want the closure test written before the closure is needed, and why it asks questions about the function's own behavior. Are teams routing around the function? Is the time from request to accepted use no better than what a team gets alone? Do most adopters fork the shared base rather than use it? Is there a shared asset nobody will accept to maintain? Does the function win most of its own allocations? These are the five questions in the next chapter. Two yeses mean shrink or close. The number is my judgment.

Helen asked Maya to run them every six months. Maya agreed and asked for something in return: that the question of closing ACM itself be on the list, in writing. She wanted the first person to propose it to feel supported.

Mind one limit on all of this. The records are assumed to survive a closure, and real ones do not unless someone owns them. A record kept in a drawer with no owner decays, and a stale record applied in a new setting can do worse than none. Every record needs a name, a date and a place where people will find it.

Where this fails

What I would not claim.

Most of the framing in this chapter is my judgment, which I mark here once. The research gives me the quiet-gap rule in a clean case and the preservation problem in a small game. It does not tell me how fast real skills decay, how often people leave when a team is closed, or what a real restart costs. Those are the numbers that decide a real case, and I have used the research's illustrative ones only to show the shape.

The quiet-gap rule also assumes you know the length of the gap. Hartwell did not, and a wrong forecast cost it a unit. A forecast is one input. A decision rule is how you act on a forecast you may have to change. Make the rule simple enough that someone else can apply it when you are away.