Fund the question before the answer

The story

Twelve hundred hours, marked P1.

By the fourth month, Maya Okafor had learned to read a request the way a doctor reads a chart: not for what it says, but for what it assumes.

The request came from Priya Natarajan on a Thursday. Warranty Claims had a new problem. Regional offices had begun to add handwritten amendments in the margins of annex pages, changing the terms of a warranty by a line and a signature. The shared document base could not read them reliably. Priya's proposal was thorough, and she had done her homework. She wanted to fine-tune the base on thirty thousand past annexes, which would need 1,200 GPU-hours. It was marked P1.

Twelve hundred hours was sixty percent of the quarterly envelope that Helen Brandt had delegated to Maya: 2,000 GPU-hours and 30 specialist-days. It would also put Tomás Reyes on the problem for most of a month. Maya could have said yes, because the case was plausible and Priya had good reason to be anxious. She could have said no, citing the envelope. She did neither. She asked a different question.

"What do you think you'll find out?"

Priya paused. "That the model can read the notes."

"Right. And what if it can, some of them?"

That pause was longer. It was the first time Priya noticed that her request had a plan for success and none for the middle. A fine-tuning run is an answer. It answers a question that had not yet been asked, which is: what exactly is failing, how often, and is it the kind of failure that more training fixes?

Maya took her through a short ladder, five rungs, on a single page. Is this known here? Dispatch's scanners had, it turned out, a licensed handwriting mode that nobody in Warranty had heard of. Is it known elsewhere? Yes, the same licence. Does it pass Priya's own test? Nobody knew. So it was an unknown, and the smallest test that could change the decision was cheap: run the licensed mode on 200 annexes, 34 of which had handwritten amendments, and look at what it missed.

The test took three days and 40 GPU-hours. It caught 31 of the 34 amendments, about 91 percent, and that was not good enough for Priya, who needs all of them. But the three misses told a story. All three came from the same regional office, which used a form template with a narrow margin, and the handwriting ran off the edge of what the reader looked at. That was not a model problem. It was a template problem, with a narrow technical fix.

Priya got her development, but a smaller one. A 150-hour run on the one regional template, with a stop rule: if the misses did not fall to zero on a fresh sample of fifty by the checkpoint, the work would stop and the amendments from that office would go to a human. Forty hours for the test, plus 150, came to 190. Priya had asked for 1,200. Hartwell kept 1,010 hours for something else.

The same week, someone in R&D asked for a larger run: training a document reader from scratch on Hartwell's own corpus, because the shared base was "not ours". Maya declined, in writing, with her reason on a single page: the base already existed, the test showed what was missing, and no evidence suggested that a from-scratch model would fit better. She noted what would reopen the question. R&D has not asked again.

The problem

A request for an answer hides the question.

Most requests for scarce resources arrive as answers. Give us 1,200 GPU-hours. Approve this vendor. Let us hire a specialist. Behind each is an uncertainty, and the person asking has usually compressed it into the one option that seems certain. A bigger training run feels like action. It is also the most expensive way to find out whether it was the right action.

The cure is simple to say and hard to do: fund the question before the answer. Ask what is unknown. Ask what the smallest thing would be that could change the next decision. Ask whether the work already exists, here or elsewhere. Spend a little to learn, then decide how much to spend to build.

There is a second problem, a quieter one, and it has a name in every operations team: when everything is P1, nothing is. Hartwell had twenty-three requests marked P1 out of twenty-six. Nobody was lying. A priority label is free to write and it helps your request win, so everyone writes it. The label stops carrying information. A review process built on top of it ends up measuring how loud people are.

What the research shows

Urgency is free to claim; a test is worth what it can change.

The priority game. The lesson on the priority game solves a small version exactly. Two teams compete for a scarce slot. Requesting high priority costs nothing and improves the chance of getting the slot, so each team does better claiming top priority whatever the other does. Both claim it, and the label goes silent. This is a result about incentives, and it matches the twenty-three out of twenty-six. The lesson also keeps a case that matters for this chapter: a screen can sort strong requests from weak ones correctly and still lose money once the preparation and the assessment are counted. Reviews cost something. Good projects can be discouraged from entering at all.

Choosing tests. Learning from records covers the other half. A test earns its cost only when the decision it informs is worth enough, and only if its answer could change that decision. The next test can depend on the last result, which is why the flexibility to stop, to reuse an existing method or to buy no evidence at all is worth something. The lesson also keeps the trap: if teams report successful demonstrations and quietly drop failures, a planner can choose perfectly for the picture it sees and still lose in the world it faces. More records do not cure biased records.

Available hours are not a reason. From how much to invest: the best amount of shared practice can sit below the capacity limit, and sometimes the learning never recovers its setup cost. Priya's 1,200 hours were available. That was not an argument for them.

What the research does not say is that a two-lane review, a ladder or any budget rule I describe below is best. These are my designs for acting on the results. The results are narrower than my recommendations.

Four convictions

How I run a request.

The Question Ladder

Five rungs, in order, with a fast lane at the top.

The ladder turns the conviction into a habit. A request for scarce time or money climbs it from the first rung, and stops at the first rung that answers it. The order is the point: the cheapest answer comes first.

Known here. Someone in the company already does this. Reuse it. The main work is finding out; this is the discovery job from chapter 2, and it is why the record has to be searchable by someone who does not know what to look for.

Known elsewhere. Someone outside has solved it. I use three verbs: buy it, borrow it, learn it. Buying means a licence or a service. Borrowing means a person, or a colleague's time. Learning means a short, paid period of practice. Before any of them, the product team runs its own acceptance test on its own documents.

Unknown. Nobody knows, so find out as cheaply as you can. The smallest test is the one whose result could change what you fund next. If you can't describe a result that would change the decision, you don't have a test yet; you have a demonstration. Demonstrations are cheap, and they test the wrong uncertainty: whether the model can do it once, rather than whether it can do it reliably, at the cost of being wrong.

Worth developing. A test has shown a gap worth closing. Develop it, with a stop rule: a checkpoint, a measure, and an agreement in advance on what happens if the measure is not met. Priya's 150-hour run had a fresh sample of fifty and a zero-miss threshold. The loop arrow in the figure is the stop rule: when the checkpoint fails, the work goes back to a cheaper test, not forward to a bigger budget.

Decline. A decline is a decision, and it needs a record: the reason, and what evidence would reopen it. A request that was declined without a reason returns in three months in a louder voice.

The pitch

One page, five lines.

For the expensive or hard-to-reverse bets, the ladder is the conversation and a short written pitch is the record. I ask for five lines, no slides.

The need, in the user's words: what work are people trying to do? What has been tried, here and elsewhere? What is unknown? What is the smallest test that would change the next investment? And what will we stop, and when, if it does not work?

The pitch has to be short enough to be useful to the person writing it. The best ones are written in an hour and change the writer's mind in the course of writing. A pitch that takes a week is a project, and a polished presentation is not evidence of anything except effort.

Keep a ledger of every request, including declined ones and stopped ones. It is the cheapest antidote I know for the records that vanish, and it makes the next Portfolio Manager's job possible. What was asked, what the ladder said, what was funded, what the result was.

Who raises the fund

Raising, allocating and pitching are three jobs.

Everything so far assumes that an envelope exists. Someone has to put it there, and I have come to think that this is a different job from spending it. Venture funds draw the same line. The investors who commit the money, the limited partners, are not the partner who raises the fund, who is not the investment partner who chooses the companies, and none of them is the founder who pitches. Gompers and Lerner, in The Venture Capital Cycle, study fund-raising, investing and exits as separate stages of one cycle (sources). I borrow the shape and nothing more. A company fund has no carried interest, no ten-year clock and no outside investors to please, so this is an analogy for roles, not a model of finance.

Raising. Gathering the budget. This means finding money in the lines that are already being spent, persuading the people who control those lines, and putting the result in one envelope with a review date. The skills are those of a budget round: a case in money, patience with the finance chief, and the standing to ask peers to give up something. At Hartwell, Helen Brandt did this before Maya had a title. She did not ask for new money. She pointed to the lines that had paid twice, moved a share of them into one quarterly envelope of 2,000 GPU-hours and 30 specialist-days, and said when she would look at it again.

Allocating. Deciding on pitches. This means reading five lines and a test result, knowing what would change the next decision, and saying no kindly. The skills are judgment under uncertainty and a good memory for earlier requests. It is the Portfolio Manager's job. At Hartwell Maya wears that hat, inside the envelope, and takes the expensive and hard-to-reverse bets to the investment committee: the AI Capability Manager, the Portfolio Manager and one product owner who rotates (chapter 2).

Two corporate-finance papers say why allocating needs a real mandate. Jeremy Stein argued in 1997 that headquarters can add value by moving scarce resources between competing projects, even when it cannot add capital, and that this can work better over a small, focused set of projects (sources). David Scharfstein and Stein showed in 2000 the dark side: when division managers can lobby for a larger share, rent-seeking can subvert the allocation (sources). A free priority label is a cheap way to lobby, which is why I give the Portfolio Manager a budget and a ledger rather than a ranking. Both papers are models of conglomerates, not of AI queues, so I read them as a reason to care, not a measurement. Eric Ries makes the practical version of the point in The Startup Way: fund internal ventures from a fixed, metered budget of time or money so that scarcity forces choices (sources). That is how I would release the envelope too, in stages, against the last result.

Pitching. Teams write five lines, in their own words, saying what they do not know. The skill is being specific about a doubt, which is rarer than being persuasive about a plan.

I keep the word sponsor for the person who raises the envelope and holds it. That is a little narrower than the word usually is. A sponsor in many companies is a senior name on a slide. Here the sponsor has done the work of raising and still holds the spend key of chapter 2: she settles disputes, changes the envelope, and runs the review.

Who does it at each size

Startup

Raises: the CEO, as a monthly vendor and compute line set in the Monday meeting. Allocates: the cofounder with the strongest judgment on models, one day a week, wearing both the AI Capability Manager and the Portfolio Manager hats. Pitches: the squad leads, in a few lines at the same meeting.

Scale-up

Raises: the COO or the CFO, from budgets already spent twice, as one envelope a quarter. Allocates: the Portfolio Manager inside it (at first the AI Capability Manager wearing that hat), with the sponsor settling disputes. Pitches: the product team heads.

Very large company

Raises: business-unit leaders, including vice presidents, who each commit part of their budget to a pool, under a rule set by the CFO or a compute committee. Allocates: a Portfolio Manager for each unit’s share, and the investment committee for pooled bets. Pitches: teams, to the Portfolio Manager nearest to them.

How the money is gathered

There are three ways, and I would pick them in this order. Re-point what is already spent. The cheapest envelope is the one carved from the second invoice. Ask for commitments. Each unit pledges a share in advance, in proportion to what it expects to use, as limited partners do. A commitment is paid whether or not the unit uses the service, and that is exactly why it does not teach people to hide failures. A per-use charge does, which is why chapter 7 keeps the shared backups out of charge-back. Add a central line. A tax on every unit is the simplest and the one that earns the least goodwill. Use it for the shared base and the backups, and no wider.

A vice president can raise such a fund, and so can the AI Capability Manager if ACM is meant to act as the investor. I would hesitate at the second. A person who both raises the money and chooses who gets it has two reasons to want the fund to look busy. Keep a second name on the page, even if both names sit on the same head at a startup, and say so out loud.

The roles above are a design of mine, drawn from how funds are usually organised. The research is silent on who should raise a company fund. Every cast member is written out in the appendix.