The second invoice

The story

Two invoices, one failure.

Maya Okafor was reconciling vendor invoices on a Tuesday in March. It was not her job. She was chief of staff to the COO of Hartwell, a company of six thousand people that makes and services industrial pumps and compressors in thirty countries, and Helen Brandt had asked her a simple question: what are we spending on AI, and what are we getting for it?

Hartwell had bought or built something in the last eighteen months almost everywhere. Warranty Claims had a model that reads contracts and scanned annexes to decide whether a repair is covered. Field Repair Dispatch had one that reads manuals and service logs to route crews. Customer Support had a multilingual chat product. The Finance Analysts had document tools. Platform was a small team keeping the lights on. R&D had two machine learning engineers, one of them Tomás Reyes, whom everyone else queued for.

Maya built a spreadsheet, one row per line item, and sorted it by description. Two rows landed next to each other. The first, from last autumn, was a contractor and a block of rented GPUs: eleven weeks of work, about 40 units (in this book a unit is about $5,000, so roughly $200,000), to find out why the Warranty Claims model sometimes missed an exclusion. The second, from February, was a different vendor and a different team: seven weeks, about 40 units, to find out why the dispatch model sometimes routed a crew to a repair that the warranty did not cover.

She opened the two reports. They described the same failure. The document reader dropped scanned annex pages that had a two-column layout or a faxed stamp across the text. Whatever was printed there, including the exclusion, never reached the model. Warranty Claims had found it first and fixed it for itself. Nobody had told Dispatch, and nobody at Hartwell had been responsible for telling them.

Here is the part I want you to notice. Nobody had done anything wrong. Priya Natarajan, who runs Warranty Claims, had written up her diagnosis carefully. Dan Whitfield, who runs Dispatch, had hired a reasonable vendor and managed the work well. Each team made a sensible decision with the information it had. The company still paid twice.

Then Maya counted the requests in the same quarter for GPU time and outside help. Twenty-six had come in. Twenty-three were marked P1. Tomás had nine open, and when she asked him which mattered most he laughed, politely, and said that they all did, according to the people who sent them.

She took the spreadsheet to Helen. Helen read it for a minute and asked the question this chapter is about: "Do we need an AI department?"

The problem

The second invoice is the cheapest symptom you will ever see.

I have seen some version of this scene in many companies over twenty-five years, long before AI. A team learns something expensive. The lesson stays inside the team, because nothing is arranged to move it. Six months later, another team pays to learn it again.

AI makes it worse for three reasons. The lessons cost more: compute, scarce specialists and months of calendar time, not just a few developer-days. The lessons are harder to see: a model that misses one clause in two hundred looks fine in a demonstration. And the people who can recognize a mistake are few, so they become the queue.

Note what I am not saying. I am not saying that every company needs an organization to prevent this. The second invoice has a cure that costs a conversation, and sometimes the right answer is to have the conversation and move on. This chapter is about how to tell the difference, with a test you can run in an afternoon.

One more word on scope, because it changes who should read this book. When people say "AI capability" they often mean building models: GPUs, training runs, research teams. That is one case, and an important one. But the same problem appears when a company only introduces, adopts and uses AI. The scarce thing might be a vendor budget, a security reviewer who must approve every tool, or the one person who understands how to test whether a chatbot is safe to release. Hartwell mostly buys and tunes. Its scarce things are Tomás's time, GPU hours and Priya's patience. If your company only buys, translate "GPU hours" into whatever your teams queue for.

What the research shows

Sharing pays when the same hard problem recurs, and it is never free.

The research lessons on this site make the problem precise, and I am going to lean on four of their results. None of them says "build an AI department". That is the first thing to understand about the evidence, and it is why this book is a judgment and not a proof.

The sharing equation. The first lesson, when does doing it once beat doing it n times, reduces the question to one line. Doing a thing once, for everyone, beats doing it separately when the saving per team, multiplied by the number of teams, is larger than the fixed cost of building the shared thing plus the costs of coordinating, waiting and the mistakes the shared version causes. Every later lesson takes one of those costs apart.

An optional shared route cannot hurt a single planner. If a shared route is free to offer, optional to use, and equally well informed as the local one, a single decision maker is never worse off for having it. Losses come from three places: the shared route's cost, forcing teams through it, and incentives. In games between teams, even a better option can make everyone worse off. I treat this as the reason to keep every shared service optional unless I can name the harm that compulsion prevents.

No premium for the name. Every model on this site gives a capable local team the same information, people and rules as the shared route. So an organization called "ACM" earns nothing by existing. Any gain has to come from something specific: a record that moves, a scarce expert's time used once instead of five times, a rule that makes honesty pay. That is a design rule, not a finding, and it shapes this book: I describe mechanisms and jobs, never a box on an org chart.

Better expertise can lose to better fit. The second lesson, better expertise, worse fit, shows that a method with more accumulated experience can still lose to a local method once the job differs enough from what the shared method was built for. The warning applies to Hartwell directly. A shared document reader that suits Dispatch may not suit Warranty Claims.

For the executive version of the same argument, written for people who will read nothing else, see the business article. What follows is my version: what I would do about it.

Two convictions

Count symptoms before you design anything.

The five symptoms

Five questions, answerable from records.

Here is the check I give to a leadership team on the first day. It takes an afternoon. You need one person from finance, one from the team that manages compute or vendors, and one expert. For each symptom, answer yes or no from records, not from memory.

How to read the result. These thresholds are my judgment; no model produced them.

Zero or one yes. Do not build anything. Fix the one symptom with a conversation. If it is the second invoice, put the two team leads in a room. If it is the orphan, give the thing an owner today. Check again in six months.

Two or three yes. Name one person to own the connections, part time, with a short written mandate. This is the subject of the next chapter. You do not need headcount, a budget line, or a new reporting structure to begin.

Four or five yes. You have a real problem, and a part-time AI Capability Manager may not be enough. Name her anyway and start there, but write down what would make you add capacity: a specific gap, such as missing depth in one domain or too many urgent jobs landing on the same person at once. Chapter 2 covers both.

Why these five? Each one corresponds to a cost in the sharing equation. The second invoice is the saving you are not collecting. Everything is P1 is a waiting cost made invisible: when every request is urgent, the label cannot tell you what to do first, and the research on the priority game shows why. In its small game, calling a request urgent costs nothing, so each team does better claiming top priority whatever the other does. The label goes quiet by itself. The queue for one person is the staffing problem, and the staffing lesson treats it: a queue is a signal, not a hiring plan. Failures that vanish waste the records that the lesson on records says are worth something when they are accessible and correctly diagnosed. And the orphan is the continuity problem, taken up in the lesson on keeping capability.

Back at Hartwell

Four yes, one no.

Maya ran the count over three days. Symptom one: yes, the two invoices. Symptom two: yes, twenty-three of twenty-six. Symptom three: yes, Tomás had nine open requests and no deputy. Symptom four: yes, and this one stung. When Maya asked for the written record of why a document-summary pilot in Finance had been stopped the year before, the answer was a chat thread that had been archived with the person who started it. Symptom five: no. Platform was small, but it had a rule, and everything that ran in production had a named owner. She wrote that down with some pride on Platform's behalf.

Four out of five. She sat down with Helen and made a proposal that I will return to in the next chapter, but the shape of it matters now. She did not propose a department. She asked for a name on a page, a small envelope of GPU hours and specialist days, and three months.

Helen asked what would make Maya say it had been unnecessary. This is the most useful question a sponsor can ask, and Maya had an answer prepared. If, after the first quarter, teams were already finding each other without help, if the P1 share had fallen without anyone enforcing it, and if the second invoice did not recur, then the arrangement had done its job or was not needed, and she would say so. She would put in writing the one result that would prove she was wasting Helen's time: a quarter in which nothing she did changed a decision.

The other answer

How to tell you do not need this.

I want the symptoms check to be able to say no, and often. Here is what a no looks like.

Teams already know each other's work. The company is small enough that the person who solved a problem is a hallway away. The requests for scarce time are few and genuinely different, so the priority label still carries meaning. A platform team already owns the shared pieces and teams like using them. Nothing has been paid for twice that anyone can find. In that company, adding a role costs attention and returns little, and the sharing equation says so: the saving per team times the number of teams is small, and the fixed cost is not.

Notice also what is not on the list. Company size alone is not a symptom. Whether you are "doing AI" is not a symptom. Having a chief AI officer is not a symptom, and it is not a cure. I have seen a three-hundred-person company with all five and a ten-thousand-person company with none. The symptoms measure friction, not scale.

And "we're not sure" is a legitimate result. If you cannot answer a symptom from records, that is itself a finding, usually of symptom four. Start by making the records answerable.