Faster work can make a slower company.

A wire in-tray sits on a desk at the end of a corridor, and thirty proposals lie in it, each with a sticky note that says READY. The company, the desk and the proposals are invented, and so is every number that follows. Until this week, the team that writes these proposals could draft ten a day. Then it was given an AI assistant, and now it drafts twenty. The two people who review proposals before they go to customers can still clear ten a day between them, as they always could. On Monday morning the tray was empty. It is now Wednesday evening, and the tray holds thirty.

Ask the team whether the assistant worked and they will say yes, truthfully: they draft twice as many proposals as before. Ask how many more proposals reached customers this week and the answer is none. My argument is that an AI investment should be judged by what the whole operation can finish, and that two measures which look alike need to be kept apart. One is local production speed, how fast a single step turns out its work. The other is end-to-end completion rate, how many requests the operation carries all the way to an accepted result in a day. When a step speeds up in front of a constraint that has not changed, the first measure rises and the second does not. What grows instead is the pile of work waiting.

This is not a claim that AI makes companies less productive, or that faster drafting is worthless. It is a claim about a mechanism, and it comes with a condition. Where the step that got faster was the one limiting the whole operation, completion rises. Where it was not, the gain turns up as waiting work, and the useful question becomes a narrower one: where would the next increment of effort change what the operation finishes?

Follow one proposal

Pick a single request and follow it from the moment a customer asks for a proposal to the moment the customer accepts one. Its life has four kinds of time in it. There is active work, when someone drafts it or reviews it. There is waiting, when it sits in a queue for the next person. There is rework, when a reviewer sends it back for a correction and it goes around again. And there is the customer's own time to read and sign.

The assistant changes the first of these, and only for one step. Suppose, in the invented team, that drafting a proposal used to take a writer most of a working day and now takes half of one. That is a real saving in the writer's day. But the proposal written on Wednesday now joins a tray holding twenty other proposals, and the reviewers take them in order at ten a day. It will wait two days before anyone reads it. Halving the drafting time saved a few hours of a trip that lasts most of a week, and the part of the trip that grew, the wait, is the part nobody on the drafting team sees.

There is a general rule behind this. In 1961 John Little proved that, for a system in a steady state, the average number of items in it equals the rate at which items pass through multiplied by the average time each one spends inside.⁴ Turned around, the time a proposal spends in the tray is the number in the tray divided by the rate at which reviewers empty it: thirty proposals at ten a day is three days. An earlier essay here, on queues as part of the price, used the same law. The tray in this story is not even in a steady state, because it gains ten proposals a day. A proposal drafted on Friday will wait five days.

The factory in the novel

The clearest account of this trap is a novel. In The Goal, first published in 1984, Eliyahu M. Goldratt and Jeff Cox tell the story of Alex Rogo, the manager of a failing manufacturing plant, who is given three months to turn it around before headquarters closes it.¹ His plant is full of half-finished parts, and its orders are still late. The book's turn comes when Rogo and his team find that a few resources, a machine called the NCX-10 and the heat-treat operation, have less capacity than the plant's work requires.² Every other machine can run faster and busier, and all that does is pile more parts in front of those two.

The lesson, which Goldratt later developed into what he called the theory of constraints, is a challenge to local efficiency. Improving a resource is not the same as improving the system. Only an increase in flow through the constraint can raise the system's output, and an hour of extra capacity anywhere else buys nothing until the constraint can use it.³ Goldratt also insisted on measuring output in a particular way. In his framework, throughput is the rate at which the system generates money through sales.³ A part that has been machined but not sold is not throughput. It is inventory.

That definition needs translating before it can be used in an office. A proposal team does not sell its proposals, and an accepted proposal is not yet revenue: the work still has to be delivered, and one proposal may be worth fifty times another. So in what follows I count proposals that a customer has accepted, as the nearest stand-in for Goldratt's throughput, and keep the difference in mind. Counting drafted proposals would be the office version of counting machined parts.

The novel has limits, and they matter here. It is a teaching story, not a controlled test of anything, and it certainly is not a test of AI. Its factory has stable routings and parts that are either good or bad. Office work is messier. Quality varies continuously, the constraint can move from week to week, and several resources can bind at different times: the reviewers one week, the legal team the next, the customer's procurement office after that. The idea survives that messiness, but the specific answers do not transfer. Each office has to find its own constraint.

Twice the drafting, the same output

Now the model, with its assumptions in the open. Customers ask for at least twenty proposals a day, so there is always more work to start. Before the assistant, writers could draft ten a day and reviewers could clear ten. After it, writers draft twenty and reviewers still clear ten. For now, assume that no proposal is ever sent back.

Before the assistant, ten proposals a day reached customers, and unanswered requests waited in the team's email. After it, ten proposals a day reach customers, and the backlog sits in the tray instead, growing by ten a day. The drafting rate doubled. The completion rate did not move. The waiting moved from one place to another, and it became more expensive, because a request now spends its wait in the tray after a writer has already put hours into it.

Rework makes this worse, and it is worth seeing why. Suppose one proposal in five comes back from review with corrections and has to be reviewed again. Then each accepted proposal costs the reviewers one and a quarter reviews on average, and their ten reviews a day finish only eight proposals. If faster drafts carry more errors, the extra drafting is no longer merely wasted. It spends the time of the one resource the whole operation is waiting on.

Three places to spend the next increment

Suppose the team has budget and attention for one more improvement. Three candidates make the logic clear. They are options to evaluate against a real process, not prescriptions.

More drafting. A second assistant, or a better one, raises drafting to thirty a day. Completion stays at ten, and the tray now grows by twenty a day. In this model the investment returns nothing, and it lengthens every proposal's wait.

Better inputs to review. Suppose the two reviewers have about eight hours a day for review between them and spend about forty-eight minutes on each proposal, and much of that goes on checking prices against the rate card and finding nonstandard clauses. If the drafting tools are pointed at those checks instead, so that each draft arrives with its prices verified and its unusual clauses flagged, review might fall to thirty-two minutes. The reviewers can then clear fifteen proposals a day, and completion rises by half. The same technology, aimed at the constraint, does what it could not do aimed at drafting.

Narrower approval for routine cases. Suppose half of all proposals are routine: standard price, standard terms, an existing customer. If the company decides that those can be approved against a short checklist, without a full review, the reviewers see only ten proposals a day, which is exactly what they can clear. Completion rises to twenty a day and the tray stops growing. This option is a policy decision, not a technical one, and it is only sound if an error in a routine proposal is cheap and easy to correct. That is a judgment about risk, and someone has to own it.

The third option exposes a step that is easy to forget. Once completion reaches twenty a day, review is no longer the constraint. Demand is: customers ask for twenty proposals a day, and the operation can now answer all of them. Goldratt's method, as the Theory of Constraints Institute sets it out, has five steps: identify the constraint, exploit it, subordinate everything else to it, elevate it, and then go back to the start, because once a constraint is elevated something else becomes the weakest link.⁵ The last step is the one that keeps a company from carrying on improving review after review stopped being the problem.

The ledger below runs the model for five working days. Change the reviewers' capacity and watch what happens to the gap between what is drafted and what is finished.

Measure the trip, not the step

If local speed is the wrong scoreboard, what is the right one? I would pair two measures. The first is elapsed time from request to accepted completion, measured for the whole trip, waiting included. The second is a measure of quality that catches what speed hides: the share of proposals sent back from review, and the share that customers accept. The pair matters because either one alone can be gamed. Elapsed time falls if reviewers wave everything through, and quality rises if the team sends out fewer, safer proposals.

Even careful researchers find this kind of measurement hard. In February 2026 the research group METR explained why it was changing the design of its study of AI and software developers. Its early 2025 study had found that experienced developers took 19 percent longer on tasks when allowed to use AI tools. In the follow-up, many developers declined to take part because they did not want to work without AI, and when surveyed, 30 to 50 percent said they were choosing not to submit some tasks for the same reason. Developers running several AI agents at once also made time on a task hard to measure.⁷ METR's conclusion was that its new data gave an unreliable signal of the current effect. The point I take from it is not about whether AI makes developers faster. It is that time measured at one step, in one setting, can be distorted in ways that are easy to miss, and the trip as a whole is a sturdier thing to measure.

Practitioners are reaching a similar view from the other direction. In an April 2026 McKinsey podcast, Alexis Krivkovich, a senior partner who leads the firm's people and organizational performance practice, contrasted point solutions, which use AI to do one task better and faster, with cases where a workflow can be reimagined in its entirety, and said the second is where AI was producing scalable impact.⁶ She also suggested that agents could take on part of managers' review and quality-control work.⁶ That is practitioner judgment, not causal evidence, and it says nothing specific about any one office. But it points at the same place the model does: the workflow, not the task.

Objections, considered

More drafts means better choices. Twenty drafts instead of ten can be valuable even if throughput stays flat, if a writer can try two approaches and send the stronger one. That is a real benefit, but it is a quality benefit, and it should be measured as one: at the point of selection, and again in customer acceptance. It also has a cost the model makes visible. If reviewers read both drafts, the review load per request doubles, and completion falls.

Review can be automated too. It can, at least in part, and nothing in the argument says the constraint has to be human. Automating review is the second option above in a stronger form, and it is often the right investment. But it moves the question rather than settling it: what does the automated check verify, who answers for what it misses, and where does work wait next?

Slack is not waste. Agreed, and this is not an argument for keeping everyone busy. A writer who has drafted the day's proposals by lunch has not failed. Spare capacity outside the constraint absorbs bad days, gives people time to learn, and stops queues from exploding when work arrives unevenly. The argument is the reverse of "keep busy": extra output from a step that is not the constraint adds to the pile, so a busy writer is not the goal.

Not every job is a flow. In exploratory work, such as research, design or strategy, counting completions can be the wrong objective. Ten finished experiments may be worth less than one good question. The model applies where the goal is to carry well-defined requests to a result. Define the goal first, and only then decide whether flow is the thing to optimize.

The work is not faster until it gets through.

Before you fund the next increment

• Where does accepted work wait? The queue where requests spend the longest, measured in days rather than in the effort spent on them.
• Which investment changes that wait? Whether the proposed tool adds capacity at the constraint, reduces the work the constraint must do, or only speeds up a step that already has enough.
• What would show that quality improved? The rework rate and the acceptance rate, measured before and after, so that a growing pile is not mistaken for progress.
• What becomes the constraint next? The step, or the demand, that will limit completion once this one is relieved, and who will notice when it does.

Back to the in-tray at the end of the corridor. On Monday it was empty; by Friday evening it will hold fifty proposals marked READY. Count instead the proposals that cleared review and went to a customer this week: fifty, the same as in the week before the assistant arrived. The assistant did what it promised. The company did not finish more, because the next hour of effort went to a step that was already fast enough.