Bottlenecks

Think about say a milk bottling factory.

If there is one machine for the entire plant that puts caps on bottles and can only do 6 bottles every minute.

Then the maximum output for the system will 6 bottles a minute.

You can improve other parts of the factory but it will never produce more than 6 bottles a minute if the speed of the capping machine is not improved.

The machine is the ‘constraint’ or ‘bottleneck’ for the entire system.

Eliyahu Goldratt was an Israeli physicist turned business consultant who popularized the Theory of Constraints in his novel “The Goal”.

The Goal is written as fiction novel about a manager in a mid west manufacturing plant that is about to go under. He mets character that sounds like like Eliyahu who through a series of questions gets him to think harder about the operation of his factory and turns things around by applying the idea of locating the most significant bottlenecks and solving each one in turn.

This is one of the most important ideas from the theory of constraints. If only one factor limits a system at a given time, then the only worthwhile thing to do is to fix it. Effort expended fixing things which are not the bottleneck won’t have any benefit until the biggest bottleneck is solved.

If you think about it - wow! You only need to focus on the biggest bottlenecks, and solving these first.

It makes things much easier to prioritize and manage. You have far less things to think about at any given time.

Think about what companies often do instead. We run around trying to fix everything, all at once. The theory of constraints tells us that all we need to do is get really good at identifying the biggest bottleneck and solving that. Then rinse-repeat - find the new bottleneck.

Don’t run around like a headless chicken trying to fix every problem.

Focus on finding the biggest bottlenecks and solve them, one after another.

What’s really cool about this is you have the power of compounding efficiencies.

Each bottleneck increases the efficiency of the process by a certain percentage.

Combine these together and they compound.

Each bottleneck solved means you are increasing the speed of the process with a percentage every time.

This is where the magic of compound interest comes into place. You can see this visually in the following spreadsheet:

https://docs.google.com/spreadsheets/d/1mx506x85EnP6btixveJW_4QFLGxqDWnMP8Xnlkcj7Bk/edit?usp=sharing

This is why private sector organizations tend to have an easier time being efficient and successful. Most businesses have a handful of core processes which define the business.

For instance for iNTERFACEWARE these would be our core processes:

• Quality assurance

• Support

• Acquiring new clients

• Growing our relationships with existing clients so they become bigger clients

• Recruitment

• Helping staff grow with training.

• Accounts receivable

That’s about it. It’s not to say that there are not other processes. But these are the core ones that to be successful as a business we need to focus on optimizing.

Some processes don’t need optimization. Payroll is pretty important process but it works well - we won’t need much impact by making 100 times more efficient.

It makes sense when you think about it.

If you know of a bottleneck and you can fix it, then chances are you will just go ahead and fix it if you can.

The bottlenecks which don’t get fixed as easily are when then people who can see the bottleneck are not in a position to fix it.

For instance one of the biggest bottlenecks in our support process is licensing inquiries. To fix that means building a new licensing system which is really more of an action for development.

So good management is as simple as having an open dialog to find out where the real bottlenecks are and getting those fixed.

So good management is about helping to bring visibility on those bottlenecks - it’s all about good communication.

It’s easy as a manager look at a system and find things which look like they are broken or could be improved.

The problem if you are not tapping into the knowledge of the people in the system who are closest to it that you will identify things which you think are bottlenecks but actually aren’t the real bottlenecks.

This is when time and money get wasted fixing problems which don’t improve the system. You have to be humble as a manager and get people to trust you to have open conversations to find the real bottlenecks with your people.

This is so important.

Same underlying math.

That’s what makes this idea so powerful since it gives a common language to talk about through your entire organization.

There are symmetries here.

When you look at system with the goal of trying to improve the speed and output, the first thing you need to do is try to look for what the biggest ‘bottlenecks’ are. Think of the problem abstractly in terms of components of the process. Let’s say they are A, B and C. If we look at the break down of time spent on these things maybe it breaks down as:

• A takes 5 minutes (5%)

• B takes 1 minute (1%)

• C takes 94 minutes (94%)

Total time is 100 minutes.

As a manager or a software developer if we focus our efforts on making A or B twice as fast we won’t see a measurable improvement - increasing the speed of B by a factor of ten times only will barely produce a 1% increase in speed.

But if we focus our efforts on making C change from 94 to 47 minutes then the figures will change to this:

• A takes 5 minutes (9%)

• B takes 1 minute (2%)

• C takes 47 minutes (89%)

Total time is 53 minutes.

If we further optimize C to take it down to 5 minutes then the figures stack up like this:

• A takes 5 minutes (45%)

• B takes 1 minute (9%)

• C takes 5 minutes (45%)

Total time is 11 minutes.

What is interesting about this process is that as you solve one bottleneck then usually another bottleneck emerges as significant. At this point optimizing A would now offer some opportunities to make measurable improvements in the process.

For me personally if I am managing developers I look for typical patterns which slow them down - i.e. if it takes them a long time to compile, run and test to reproduce an issue they are working on solving.

The theory of constraints gives another lens to understand why premature optimization is a problem in software development.