Name the owner before the department

The story

A page, not a department.

Helen Brandt did not announce anything. She wrote a page. On a Monday morning, three weeks after Maya's spreadsheet, the COO sent a note to the heads of Warranty Claims, Field Repair Dispatch, Customer Support, Finance Analysts, Platform and R&D. It ran to about three hundred words. It named Maya Okafor as the company's first AI Capability Manager, "a role, not a department", and it listed what she could do on her own, what she could do only with someone else's yes, and what she could not do at all.

Priya Natarajan read it twice and phoned Maya within the hour. Priya runs Warranty Claims, where a missed exclusion in a contract is a real financial loss and sometimes a legal one. She is not an enemy of AI; she is the person who found the annex failure in the first place. But she had seen two earlier "centres of excellence" arrive with a logo and leave with a slide deck.

"What exactly can you stop?" she asked.

"A test I funded," Maya said. "And nothing of yours."

"What can you make me use?"

"Nothing. If you won't accept something in your product, I can't release it there. That key is yours."

There was a pause. "Okay," said Priya. "Then what do you actually do?"

It was the right question, and the page Helen had written answered it with jobs, not with a chart. Maya would make three decisions happen in the right hands. Who may spend scarce compute and specialist time. Who vouches for a shared piece of work. Who says yes in the product. Helen called them the three keys, and she had thought carefully about who held each. The page also named, in two short lists, which jobs Maya held herself and which stayed with other people. This chapter is that page, opened up.

The problem

Without owners, a company gets one of two failures.

When a company decides that its AI work needs connecting, it tends to jump to an organization chart. A department, a centre, a council, a title. Then it spends months arguing about the chart instead of doing the connecting.

The alternative failure is the opposite. Nobody is named, so everybody assumes someone else is watching. The second invoice recurs. The expert becomes a queue. The model nobody agreed to maintain keeps running. Practitioners who advise on this describe the same pattern: in a 2019 article in Harvard Business Review, three McKinsey partners argue that the main obstacle to getting value from AI is organizational and cultural, not technical (sources). That matches what I see. I do not use the article for more than that.

The way out of both is to separate three things that are usually bundled: the decision (who may do what), the job (what work the connecting is made of) and the person (who or what does it). Get the first two right and you will know whether you need a department at all. Get them wrong and a department will not rescue you.

Jobs, not boxes

ACM is a set of jobs. A job can sit in many places.

Here is the idea the rest of this chapter hangs on. I do not start from a box on an organization chart. I start from a list of jobs that connect the AI work of a company, and I ask of each one: who holds it? A job can be held by someone inside ACM. It can be held by a person in their home team, lent on reserved hours. It can be done by an agent under a named human. Whether there is a department at the end is a result, not a starting point. The research gives the conditions under which each job is worth having at all; I will name them as we go.

Six jobs that can sit inside ACM

AI Capability Manager

The lead, and the name of the discipline, as the category manager is at a consumer-goods company. Owns the portfolio of shared capabilities, runs discovery, chairs allocation and reports to the sponsor. This job always exists. At the smallest company it is a hat worn by an executive.

Portfolio Manager

The allocator, the investment partner of the fund. Decides which pitches get the envelope, meters the money out, stops bets, and keeps the ledger of every bet, including the stopped ones. It becomes a job of its own when enough requests compete for a scarce envelope that gaming appears (the priority game) and when a record of failures is worth keeping (learning from records).

Technical Owner

Builds and vouches for the shared base. Its quality is the Technical Owner's to defend, independent of whoever accepts it. The job exists when several teams share a need that fits closely enough to pay for one base (the sharing equation, expertise versus fit).

Prototype Owner

Owns a prototype that ACM itself built, like a product owner, until it is handed to a product team. The job exists only when ACM builds for needs that no product team owns yet (promises and honesty, support that lets go).

Specialists

Depth that no single team can justify alone, lent on reserved hours or dedicated. They sit inside when expertise is scarce enough that concentrating it beats spreading it (how much to invest, staffing the work).

Agents

A discovery agent, a brief writer, an evidence reviewer, a record keeper and a hand-over coach. Each is supervised by a named human job. The appendix writes them out with prompts.

Seven jobs that stay outside, always

Outside ACM, and I would keep them outside at any size, sit the people who put money in, who bear the consequences, or who run the machines. The venture comparison fits well enough that I use it for roles, and only for roles.

Sponsor

The partner who raises the fund. Builds the envelope by negotiating with the CFO and the business units, holds it, and answers for it.

CFO

The real one. Sets the fund's terms: the accounting, whether there is a chargeback, the rules of the envelope.

Business-unit heads

The limited partners. They contribute budget and expect returns in their own units.

Product owners

The customers who adopt. They accept or refuse local use and own local tuning and acceptance tests.

Platform owner

Runs the production infrastructure and receives what is transferred.

Lending managers

Lend people on reserved hours, and keep the decision to do so.

Team leads

The founders who pitch. They bring needs, make the case, and consume the library and the consults.

Why keep these outside? Each of them holds either the money, the consequence or the machine, and moving them inside would put two keys on one head. A chief financial officer who sat inside ACM would no longer be a check on it.

Three ways in

A team reaches ACM by a library, a consult or a fund.

Jobs only matter if they are served, so I name the three doors a team can use and who stands behind each. The doors do not depend on the size of the arrangement; who serves them does. Engineers will recognize the shape: Skelton and Pais, in Team Topologies (2019), separate teams that deliver to users from platform teams that provide a service and enabling teams that help for a while (sources). My three doors borrow that distinction and nothing more.

Library

Self-service. The record keeper and discovery agents maintain it; the Technical Owner vouches for what is in it. A team can use it without anyone's time.

Consult

Humans only. The Technical Owner or a lent specialist, on booked hours. This door opens at the Network setting, when specialists can be lent.

Fund

The Portfolio Manager decides, within the sponsor's envelope. Teams pitch with the brief-writer agent's help, and the evidence-reviewer agent pre-screens the evidence.

Notice the mix. An agent can serve a library door, because a library is paper work. An agent never serves a consult, because a consult is a judgment given by someone who will be asked again. And an agent helps a fund pitch without ever deciding it. The jobs sit inside and outside ACM in different combinations: the specialist in a consult is inside ACM only for the booked hours, and her manager outside it still decides whether to lend her.

Raising and allocating

Whoever raises the fund does not decide who gets it.

I borrow one more idea from the venture world, and it matters. A venture fund has limited partners, who commit the money. It has a partner who raises the fund, which is a job of persuasion, patience and standing. It has an investment partner who chooses among companies, which is a job of judgment and of saying no. And it has founders who pitch. These are different people with different skills, because raising rewards persuading peers and allocating rewards the courage to stop. Gompers and Lerner, in their book on the venture capital cycle, study fund-raising, investing and exits as separate stages (sources). A company fund has no carried interest and no outside investors, so this is an analogy for roles and not a model of finance.

In ACM, the sponsor raises the fund and holds it. The Portfolio Manager allocates it. The business-unit heads are the limited partners. Team leads pitch. Chapter 4 works through who does what at each size, and how the money is gathered. Here I only need you to see that they are different jobs, because the Three Keys below assume it.

The investment committee

Expensive and hard-to-reverse bets go to a small committee of three: the AI Capability Manager, the Portfolio Manager and one product owner, who rotates. The AI Capability Manager sees across the portfolio. The Portfolio Manager has read the ledger. The rotating product owner has to live with what ships, and rotation keeps one seat from being captured by one team's agenda. A product owner whose own pitch is on the table steps out for that item. Where one person wears two hats, as Maya does at Hartwell, the committee still needs three voices, so a second name takes the chair of the missing hat for the day.

What the research shows

Authority on paper is not authority in practice, and breadth has limits.

Three results from the research bear on who should own this, and two of them pull in different directions. I will say which way I lean.

Formal and real authority differ. Economists Philippe Aghion and Jean Tirole drew the distinction in the 1990s: assigning a decision on paper is not the same as giving someone the information and resources to make it. The sources page lists the paper. It is the reason Helen's page says what Maya can do, but also what she is given: a small envelope of 2,000 GPU-hours and 30 specialist-days per quarter, which is real authority to spend. A title without an envelope is a request for goodwill.

Generalists remove handoffs; they cannot add hours. The staffing lesson finds that each arrangement wins somewhere. One broad person is the right start when the alternative is a handoff between two people. Specialists win when the work needs depth that no generalist has. A mix wins when both appear. The same total hours fit when deadlines are spread out and fail when everything is due on Friday. This is why my default is one person wearing several of the inside jobs: it removes a handoff on day one. And it is why I plan, from day one, for the Friday where two urgent jobs need the same specialist.

A queue is a signal, not a hiring plan. Tomás Reyes had nine open requests. The tempting reading is that Hartwell needs more machine learning engineers. The model reading is that some of those requests are the second invoice, some are the priority label going quiet, and a few are real depth. Count first. The lesson on how much to invest adds that the right amount of shared work can sit below the capacity limit: available hours are not a reason to spend them.

And the design rule from chapter 1 still applies: nothing about the title earns a premium. If Maya's role works, it will be because of what she and the three keys make happen, not because someone put "AI capability" in a signature.

Three convictions

Where I stand on who owns it.

The Three Keys

Spend, vouch, accept.

The three keys are the simplest way I know to prevent both failures. Every important decision about shared AI work turns one of three locks.

The spend key belongs to the sponsor, who raised the budget and holds it. The sponsor lends an envelope of scarce resources, such as GPU hours, specialist days or vendor spend, to the AI Capability Manager's portfolio, and the Portfolio Manager decides within it. The sponsor does not approve each request. The sponsor does settle disputes and change the envelope. Raising the fund and allocating it are different jobs, and chapter 4 keeps them apart.

The vouch key belongs to whoever stands behind the shared piece of work: the Technical Owner. At Hartwell this is Tomás, who says what the shared document reader does, which version is supported, and what evidence he has. He also asks Platform to accept the upkeep. A prototype is not a service until somebody says yes to the maintenance, and the sponsor has funded it.

The accept key belongs to the product team, because it bears the consequences. Priya's team decides whether the shared reader is good enough for warranty decisions, on her tests. Dan's team decides for dispatch, on his. Nobody can turn this key from outside, and the AI Capability Manager never tries. That is the promise that made Priya trust the arrangement.

Each key sits with someone who has the information and the consequences. That is the whole design. Notice that no new title holds a key except the Technical Owner's vouch: the sponsor, the product teams, Platform and a lending manager already exist.

Read the grid across. The Portfolio Manager decides two things: whether to fund a test within the envelope, and whether to stop one. Those are small and reversible. The AI Capability Manager decides none of the seven alone: she chairs, connects and advises, and the keys stay where the information is. Anything that changes the shared base belongs to the Technical Owner, anything that ships to a customer belongs to the product team, and any dispute about money belongs to the sponsor. Lending a person is a decision for the manager who lends them, and it always comes with an agreed change to what that person was going to do. At Hartwell, Maya wears two hats here, AI Capability Manager and Portfolio Manager, and the page says so in as many words.

When I show this grid, someone usually asks where the veto is. There isn't one. The AI Capability Manager cannot veto a product decision; the product team cannot veto a test funded in the envelope. When they disagree, the sponsor settles it, and a dispute that reaches the sponsor twice in a quarter tells you the envelope or the keys are set wrong.

Five settings

The shape of ACM is a result of where its jobs sit.

Now the question everyone asks first. How big should it be? I used to answer with an organization chart. I now answer with five settings, from a conversation to a department, and I treat the setting as an output. You do not choose it. You read it off, from which jobs have earned a place inside.

Conversation. The AI Capability Manager is an executive's spare hat; the library is a shared folder. This is the right start for a startup, and it is free. Role. A named AI Capability Manager, part-time, with a record keeper and a discovery agent. Network. Add specialists lent on reserved hours, and the consult door opens. Team. The Portfolio Manager and the Technical Owner become jobs of their own, and the fund opens. Department. Add Prototype Owners, dedicated specialists and a budget line of its own.

What moves a company up a setting is never a headcount. It is a named condition that the research can state. Two teams paying twice, and a third who might: a role. Expertise that is scarce and deadlines that collide: a network. Enough requests chasing a limited envelope that the priority label has gone quiet: a Portfolio Manager. A need that several teams share closely enough to pay for one base: a Technical Owner. ACM building things for needs that no product team owns yet: a Prototype Owner. If you cannot name the condition, do not move up.

Hartwell sits at the network setting. It has opened the fund door early, because its pain was money and not advice, and Maya holds both the AI Capability Manager and Portfolio Manager hats for now. A startup would read conversation or role. A very large company would read team or department, and for the very large case I would add one thing: a company that size has more than one place where the same job sits: a Portfolio Manager for each unit's share and one for the pooled bets, and a Technical Owner for each large capability area, so a team of five to eight people in each area is plausible. Those numbers are my judgment. The setting is a proposal built on checked research results, not a finding.

On money, the first two settings run on a small envelope that the sponsor raises, drawn from the budgets that were already being spent twice. At the fourth and fifth, a central budget for the shared base and the people, with product teams paying for their own tuning. Pure chargeback is a trap for the shared preservation of capability; chapter 7 explains why. For now, I keep the envelope central and the tuning local.

One more rule. Between the settings, the gate is the same in every case: a gap you can name. Missing depth in one domain. Too many urgent jobs landing at the same time. An adoption burden worth removing. A queue by itself is not a gap. And keep it only while its own projects do not win most of its own allocations.

The leader

Who should hold the lead job.

I prefer a profile to a job description. The AI Capability Manager needs four things.

Credibility with the people who build. Not necessarily a researcher, but someone who can read a failure report and ask the question that shows she understood it. Maya is an operations person, not a machine learning engineer, and her first weeks were spent earning this. Tomás is the technical half. In my experience, the role has a connecting half and a deep half, and in a small company they are often two people. That is fine, if both are named.

Patience with the unglamorous. The work is notes, comparisons, introductions and saying no kindly. People who want to build things leave.

A record of saving others time. Authority here comes from being useful, and it is earned in weeks.

And a willingness to make themselves unnecessary. If the role works, teams will need it less over time. That is the sign it worked.

What the role is not: it is not a centre of excellence, which owns delivery and standards. It is not a platform team, which owns shared infrastructure and wants everyone to use it. It does not build; the Technical Owner and the Prototype Owner do. It connects, chairs the allocation, and makes the three keys turn in the right hands. If Maya starts building the shared reader herself, something has gone wrong.

Back at Hartwell

The first sixty days.

Maya spent about two days a week on the role and got no headcount. In her first month, she did four things. She sat with Tomás for three hours and wrote down, in plain words, the nine requests and what each team thought it was buying. She introduced Priya's lead analyst to Dan's lead dispatcher, in a room with the two invoices on the table. She asked each of the six team heads for a named contact and a promised four hours a week. And she stopped one thing: a test Finance was running with a vendor whose result she already knew from Warranty's work. It was the first thing she ever stopped, it was within her envelope, and Finance took it well because she brought the reason with her.

At sixty days, Priya sent Maya a note. It said, in full: "The annex fix. Thanks for telling Dan. Next time tell me before the invoice." Maya framed it. It was the best result of the quarter.