In April 2004, an Air Force analyst said that at one point nearly half of the C-5 Galaxy transport fleet had been tied up in overhaul at Warner Robins Air Logistics Center in Georgia. The country was at war, and each overhaul kept a giant aircraft in the depot for months. Lean projects had cut the average from 269 days to 226, and the depot was aiming lower still.
In 2005 the depot added a method called Critical Chain to its Lean work, and the most visible step ran against instinct. “We have reduced our work in progress from 12 to seven jets,” the C-5 production section chief said, “which allows us to use the same number of technicians to work fewer C-5s simultaneously.”
On 3 February 2006 a C-5B left the depot after a record-low 159 days. A year earlier the same work had taken more than 200. The case has the rest.
The longest chain
The method comes from Eliyahu Goldratt’s 1997 business novel Critical Chain. Every project has a longest chain of steps that depend on each other, and the project cannot finish faster than that chain. Project managers already knew this as the critical path. Goldratt’s addition, as the project management scholar Shlomo Globerson explains it, was to count people too. If two tasks need the same engineer, one has to wait for the other, and the wait becomes part of the chain even though neither task depends on the other’s output.
Guard the longest chain of linked work, people included. Stop juggling; pool the slack.
Think of a house renovation where one electrician is shared by three jobs. The plumbing and the plastering may be ready, but every house waits for that electrician. Speeding up the plastering will not move the finish date.
Three moves
The first is to stop multitasking. A white paper from Scitor, a project software company, works through four four-week projects. If the same people rotate a week on each, every project drags. If they finish them one at a time in priority order, the most important project is done nine weeks sooner and the last one finishes on the same date as before, even assuming switching costs nothing. The same logic runs through Warner Robins’ seven jets.
The second is about safety time. Goldratt argued that people pad each task’s estimate and that the padding tends to be wasted, often through the student syndrome. His remedy, as a 2012 research review for the Project Management Institute summarizes it, was tighter task estimates, with the safety pooled into a shared project buffer at the end and feeding buffers where side chains join the main one.
The third is to watch the buffer instead of every task. The Scitor paper splits it into thirds. While the work has eaten into only the first third, do nothing. In the second third, work out a plan. In the last third, act. It is a fuel gauge for the schedule.
What the critics say
The method has its doubters. The same PMI review summarizes a 2003 critique by Raz and colleagues: proponents had not provided scientific evidence that task owners pad their estimates by a set factor and then use up the time, had no clear basis for sizing buffers, and relied on task owners’ estimates of time remaining, which could hide padding just as the original estimates did. Globerson notes that Goldratt’s claim that estimates run at about twice the median time has no scientific data behind it. He also cites research arguing that the main cause of late projects is queues of work waiting at busy departments, not bad estimates. That point, oddly, supports the multitasking half of the method more than the buffer half.
Imagine a five-person design studio with eight client jobs open and everyone touching all of them. Every client sees a little progress each week, and almost nothing ships. Cutting to three open jobs might make the other five clients wait longer to start, but each job could finish sooner once it begins.
Waiting on the slowest agent
Goldratt’s story about padding and putting work off is a story about people, so the buffer half of his method may not carry straight over to software agents. The chain half carries over well.
Anthropic’s research feature uses a lead agent that sends out subagents to search in parallel. In a 2025 write-up, the company said the lead agent waits for each set of subagents to finish before going on, so “the entire system can be blocked while waiting for a single subagent to finish searching.” The slowest subagent sits on the chain. Anthropic also reported that moving from sequential searches to running three to five subagents at once, each using several tools in parallel, cut research time “by up to 90% for complex queries.”
The same question applies to any team of agents. If every agent’s output waits on one human reviewer, that reviewer is on the chain, just as the electrician was. Making the agents faster might barely move the finish date.
At Warner Robins, the chain ran through technicians who had been spread across a dozen aircraft. With seven, they could finish each one sooner.