The charter

The story

One year on.

Twelve months after Helen Brandt gave Maya Okafor the job, the two of them sat down for an hour with a blank page. Helen had asked for a charter. She did not want a strategy deck. She wanted one page she could hand to the board that said what ACM was, who held which key and how she would know whether to stop.

Maya drew a page with eight blocks on it, numbered in the order she would fill them. She had been circling the questions all year without naming them. What need are we serving? Which teams share it, and what does each keep? How do they come in? What is ACM made of, and who holds each job? What is built once, and who holds the keys? Who pays? How do we know it works? When does it end?

They filled them in together, and the page took just under an hour. The first surprise was how short the answers were. The second was how many of them were new. The last block, when it ends, had been blank all year.

Then Helen asked the question the page was built to answer. “What worked, and what didn't?”

The framework

The ACM Canvas.

This is the tool I would give a new owner on her first day. Eight blocks, sized by how much they matter, filled in one order that never changes. The need comes first and is the largest. Then the teams that share it, and the three ways they come in, which sit across the line between the teams and ACM because that is where the two meet. Then what ACM is made of: which jobs sit inside, who holds each one, and the setting that follows, from a conversation to a department. Then what is built once and who holds the keys. Last, standing on a heavy base line, three plain questions: who pays, how do we know it works, and when does it end. Beside the canvas sit the rules of the game, one for each block: the question, the options, how I would choose, and the research the choice rests on.

Here is Hartwell's, filled in.

I always show a canvas filled in. A blank form invites platitudes. A filled one invites argument: Why is Finance out? Why no chargeback? Why is the review run by Helen and not Maya? Each of those has a reason, and the reason is the part worth reading.

The units and counts on this page belong to Hartwell, a fictional company, and are illustrative. The canvas is a proposal of mine, not a research result. It borrows its shape from a well-known business-design tool and its contents from the earlier chapters.

What worked

Less friction, measured two ways.

Maya's ledger for the year was short. Three duplicate efforts were caught before money was spent on them. Thirty-one requests went through the fast lane and five through the full pitch. Two tests were stopped on their stop rules. On the shared document base, the time from a team's request to a use the team accepted fell from 11 weeks to 5. The wait for Tomás fell from about six weeks to two.

I want to be careful about what that proves, and so did she. Hartwell is a story I made up to illustrate a way of working. In a real company, a fall in wait times might be ACM, or a quiet year, or the contractor, or Tomás working weekends. The research is explicit that ACM earns no premium for its name. In every model, a capable local team with the same records, rules and rewards does as well. So the honest question is which rules did the work: the two-lane review, the reward for tested lessons, the written exits, the loans with reserved time. That is a better question than “did ACM work?”.

Helen's measure was simpler. “Does the next project arrive faster and smarter than the last, carrying less friction?” For the document base the ledger said yes. For R&D it said no.

What failed

Two honest failures.

R&D went around us. In the fourth month, Maya had declined R&D's request to train a document reader from scratch, in writing, with her reason on one page. The decision was right on the evidence. The shared base already existed, and the test showed what it was missing. But she declined with a page when she should have declined with a conversation. At the six-month review she learned that R&D had trained a small reader anyway, on research credits that sat outside every budget she could see. It scored worse than the shared base on Priya Natarajan's test. The money was small. The damage was that a capable team had concluded the quickest route was around her. A route that is easier to go around than to use will be gone around.

The shared evaluation set had no owner. Platform said it was not theirs. Warranty said it was not theirs. For three months it went stale, and two teams measured themselves against an out-of-date test. By the six-month review, the checklist you will meet below showed two yeses: a team routing around ACM, and a shared asset nobody would accept to maintain. The rule said shrink or close.

Helen did not close it. She narrowed it. For two quarters ACM stopped offering funded development outside the Warranty and Dispatch work, and the page said so. Priya accepted the evaluation set for Warranty, because its main users were hers, and Platform was to take it over once it was stable. Maya wrote the failure up in the review itself, in her own name, and went to see R&D in person. At the twelve-month review there was one yes left, and it was a known one.

I put these in because a charter that cannot lose is not a charter. And there is a third thing I will not call a failure but would not call a success. Finance and Customer Support never used the shared base. Finance's documents were spreadsheets, and Support had bought a chat product that did its job. Maya left them alone on purpose. That is the Buy and Leave of chapter 3, and it was the right call. It also makes the dashboard look worse.

Three sizes

The same canvas, in a startup and in a very large company.

People ask whether this works for a company of forty. It does, with less on the page. And people ask whether it works at the scale of the largest technology companies. It does, with more machinery and the same eight blocks. Both are designs, not descriptions of real firms.

The startup needs no department and no review committee. One person owns the question “has anyone here already solved this?” and has one day a week to answer it. The keys are held by a few people wearing two hats. That works if you say so, and it fails if you pretend the hats are separate.

At very large scale, the new problem is the number of teams that could be paying twice. The answer is a department made of named jobs rather than a crowd: one AI Capability Manager for the company, a Portfolio Manager for each unit’s share of the fund, a Technical Owner for each large capability area, Prototype Owners where ACM builds, and clear keys. I plan a team of five to eight people for each large area, a proposal with no evidence of an optimum. The central budget exists for the one thing local budgets will not pay for, which is the backup everyone needs and nobody buys. The Capability Tensor from chapter 3, with business units, functions and capability programs on its three axes, is how the AI Capability Manager in this setting sees where the duplicate work hides.

What changes with size is mostly who is on the page, and the setting in block 4. The blocks and their order stay.

The start

The first 180 days are three decisions.

New owners tend to plan phases of work. I would plan decisions. Three of them, at roughly 30, 90 and 180 days, each with a question you must be able to answer. The work in between exists to answer the question.

Hartwell's first 30 days produced a canvas with several questions unanswered, a list of nine AI efforts nobody had listed in one place, and two willing adopters, Warranty and Dispatch. At day 90 the shared base was running with both, and the first failure notes were in. At day 180 came the review where the two yeses showed up. It was the review that mattered, because it was the first time the charter was used against its owner.

The 30, 90 and 180 day spacing and the three questions are a proposal of mine. The research does not say that 180 days is the right length. It says only that a decision with a deadline is better than a drift. Set your own, and write them down.

The ending

Write the kill checklist before you need it.

Each question looks for a different failure. The first finds the team that has quietly gone around you. The second finds a function that is not faster than the alternative, which is its only reason to exist. The third finds a shared base nobody wants as it is: they copy it and change it. The fourth finds an orphan, the thing everyone agrees is important and nobody will carry. The fifth finds a function that has turned inward and is funding itself.

The count of two is my judgment. It is not a threshold from the research. I chose it because one yes is usually a local problem you can fix, and two together usually means something about the design. Choose your own and keep it fixed before you look at the answers.

I also want the list run by the sponsor. A function that scores itself will always find a reason. Helen ran Hartwell's, with Maya in the room and Priya and Dan to contradict her. And I want one more line added at the bottom, which Maya wrote: What would show that ACM is unnecessary? If nothing could, you have built a department. If something could, you have a charter.

Where each thing is in its life

Open, keep, transfer, close.

The last chapter gave every shared asset four stages. A year in, Hartwell's were spread across all four, which is the sign of a healthy portfolio. The two-lane review was new and still open, with a review date. The shared document-reading base was in its keep stage and being prepared for Platform. The evaluation set had moved to Warranty. The regional chatbot prototype and the template onboarding service had closed, with their records archived and an owner named for each.

If every asset you have sits in “keep”, you are not managing them. The exits are the proof that someone is.

A fair question

How is this different from a center of excellence or a platform team?

A center of excellence usually owns delivery, and it tends to become the queue that everyone waits in. A platform team owns a product and its roadmap. ACM, as I mean it, owns neither. Its job is to know who else has learned this, to hold the rules for sharing and to make the sharing worth the sharer's while. Its authority is the keys on the canvas, and no more. That is a judgment about design, and you can build an ACM that has become a center of excellence by another name. The checklist exists to catch you.

Where this fails

What I would not claim.

This chapter, like the book, is judgment. I mark it here once. The research gives the logic and the size of the trade-offs under stated assumptions. The charter, the three company designs, the 180 days, the count of two and the story of Hartwell are mine. I have invented Hartwell. I have not measured anyone's savings, and I do not know your company.

What I do know is that the same pattern shows up everywhere I look. Someone learns something costly. The next person pays for it again. The fix is almost never a bigger department. It is a person who asks the question, rules that make answering worth it and a date on which to stop. That is the whole book, and it fits on a page.