I once ran the monitoring and evaluation department of a large nonprofit in rural Tanzania. We had 25 full-time data collectors who ran surveys with farmers on their crop yields and planting practices. My job was to oversee the team, analyze their data and produce reports with actionable recommendations.

The field team was incredibly productive and we were collecting tons of data. We were also producing very few actual reports and horrendously behind on everything. This seemed to me like a “time to work harder” problem but reading a business professor’s novel about manufacturing helped me see it differently.

The correct solution was to tell my 25 field staff to stop working for two months.

The most engrossing book I've read since Harry Potter

The Goal by Eliyahu Goldratt is a novel about a manager given 6 months to turn around his factory or face closure, and the tactics he uses to get production up. It should not be good. It is very good. I’m not claiming it’s great literature but it contains one of those ideas that, once seen, cannot be unseen. 

A system moves at the speed of its slowest component, and nothing you do to the other parts matters.

Goldratt illustrates this with a scene where the book’s hero, Alex, takes his son's scout troop on a long hike. The troop is moving slowly towards camp and at risk of not getting back before sunset. Some kids keep racing ahead, then stopping and waiting for the rest to catch up. Alex has his first realization: the speed of the fast kids doesn’t matter for the speed of the overall troop. The troop will arrive at the camp when the slowest kid arrives. Even if he could make the fast kids somehow hike faster, the troop still arrives at exactly the same time.

There's a kid named Herbie at the back. He's carrying a huge backpack full of heavy pots and pans. Alex has his 2nd insight: making Herbie faster makes the entire troop faster. A 10% improvement in Herbie's speed is a 10% improvement in the troop's speed: the rest of the troop can easily match this slightly-faster-Herbie. Yet a 10% improvement in any fast kid's speed remains a 0% improvement in the troop's speed.

So Alex does two things. First, he takes the cookware out of Herbie's backpack and distributes it among the fast kids. Herbie, and the troop, speed up. Second, he puts Herbie at the front of the line. This second move is less intuitive. Alex notices that putting Herbie up front forces everyone to move at Herbie's pace. This prevents the fast kids from wasting energy racing ahead and then waiting. It also makes it very obvious when Herbie’s backpack weight has been reduced to the point where he is no longer the slowest kid, because gaps will start to emerge in the troop, and the new slowest kids will be revealed.

This is the theory of constraints. Your system has a bottleneck—the lowest-output part. That bottleneck entirely determines your system's output. X% improvements to bottlenecks have X% productivity improvements to the entire system. Improvements to non-bottlenecks have exactly zero effect on system output. If your car production line can make 20 engines, 100 front axles and 600 wheels per day, you will be making 20 cars per day because that's the output of your bottleneck, the engines. Growing your wheel productivity to 1,000 wheels per day will not make you any more cars but it will waste a lot of wheels.

This seems obvious but it was not obvious to me, working inside the system.

Rory, the bottleneck

Now back to Tanzania. I was stressed because I had 25 people to manage and I needed to keep them busy. We were running 8 major data collection efforts per year and I was constantly behind on analysis.

I drew our workflow on a whiteboard:

1. Field team collects data (Output: 8 surveys per year)
2. I clean and analyze data (Output: Analysis of 4 surveys per year)
3. I write reports with recommendations (Output: 3 reports per year)

The goal of our department was not "collect lots of data" (which sucked, because we were crushing that part), it was "produce actionable recommendations." And I, with my output of 3/8ths that of the field team, was the bottleneck.

This led to a deeply uncomfortable realization: improvements to my field team's productivity literally did not matter. They could become 10x more efficient at data collection and we would produce exactly the same number of recommendations. They could become infinitely efficient and we would produce exactly the same number of recommendations. Because I was the bottleneck.

Worse: managing this highly productive field team was taking up my time in always making sure they have more surveys to run, which meant I was spending less time on analysis, which was making the bottleneck worse.

The theory of constraints says: only work that speeds up your bottleneck matters. Everything else is waste, even if it looks productive.

I implemented a rule: we could not start a new survey in the field until I had finished the analysis and write-up from two surveys ago.^[1] This was my version of putting Herbie at the front of the line. It forced the whole system to move at the pace of the bottleneck, the speed of my analysis, preventing people from doing wasteful work. It was also suddenly very easy for me to tell my team that I needed to spend time on analysis: they wanted to see me get that done, so that they could get back to work. 

This initially had the effect of cutting the number of surveys down by 2/3rds. The field team sat idle for months at a time in between data collection rounds. This felt incredibly wrong. We were paying 25 people full salaries to do nothing– a seemingly terrible use of a nonprofit’s resources.

But we weren't wasting anything, because data collection wasn't the bottleneck. The only scarce resource was my analysis time. Every survey I didn't have to manage freed up time for analysis. Every report I finished increased our actual output: actionable recommendations.

Focused now on just improving the analysis and report-writing bottlenecks, we hired another analyst, and simplified the reports to be quicker to write.

Our output of reports and recommendations went up, lots. Adding an analyst for 5% of our department’s budget increased our output of reports by easily 50%. Once analysis ceased to be the bottleneck, we could start working on improving other parts of the process, starting with the new bottleneck.

Bottles as bottlenecks

In another job, we were producing a pilot batch of a new bacterial vaccine. The contract manufacturer hit a snag. We needed a specific type of bottle for the vaccine and the only vendor they could find at short notice had a minimum order of 500 units. We needed just 5 bottles. The manufacturer asked for a few weeks to call around and find someone who would sell us the 5.

The request seemed entirely reasonable. Why would we buy 495 bottles we'd never use? That would cost $2,000 instead of $20. We'd be wasting $1,980. 

Except the bottles were now our bottleneck. Delaying bottle procurement by 2 weeks would delay the rollout of the vaccine by 2 weeks. If this vaccine had the potential to make $10 million per year, then each week of delay cost us roughly $200,000. Spending $2,000 to save two weeks was worth approximately $400,000. A 200x return.

Buying the 500 bottles to fix a bottleneck was a screaming deal, not waste.^[2]

Some observations on bottlenecks

Fixing non-bottlenecks feels deceptively productive. Your field team can always collect more data. Your fast hikers can always hike faster. But if these aren't bottlenecks, your output will not change.

Bottleneck logic often requires making people or resources work at lower output levels. This is the hardest part psychologically. The field team could have been doing something. Your fast hikers are bored. But if these aren't bottlenecks, having them run ahead often makes things worse, creating unused inventory or placing demands on management attention. Sometimes this means people are temporarily idle, but more often it just means they need to move at the bottleneck's speed.

The bottleneck might be you. In my Tanzania example, I was the bottleneck. This is not fun to realize. It might mean delegating, hiring, or just doing fewer things so you can finish what you've started.

Correctly identifying the bottleneck is really important. If you get it wrong, then unfortunately your work on improving the productivity of that part of your system will do little for your output. No pressure. 

Conclusion

So part of the lesson here is identify your bottleneck and eliminate it. This is correct! But there's a harder step: stop optimizing everything else. You need to be comfortable with parts of your system running at reduced capacity, while you focus on the bottleneck.

This sounded so trivial to me at first and has taken years to somewhat sink in. I spent a lot of time stressed about the wrong things because I didn't understand it. I probably cost my organization hundreds of thousands of dollars of value in missed recommendations from the M&E team. It was also just very un-fun to feel so behind.

Identify your bottleneck, optimize it alone, let everything else run at that same speed. It will feel weird but you should do it anyway.

The scout troop moves at Herbie's speed. 

1. ^{^}

   I made it "2 surveys ago" rather than more simply "we don't start a new survey until I've finished analysis of the last one" to reflect that the surveys took a while to actually run, so it was fine for field work for one to be running in parallel while I finished analysis of the previous survey

2. ^{^}

   This is a true example but the truth is never quite so neat: I ended up eventually realizing that we were actually bottlenecked by waiting for regulatory approval anyway. We could wait for the cheaper bottles without affecting our productivity. But the example is too good to not share in its idealized form :)