Subordinate non-constraint resources to the constraint
Now that the constraint is 100% loaded (thanks to the Exploit the Constraint step), the other resources are not loaded to full capacity. Let these resources spend some of their slack time to help the constraint. For example:
- resources in front of the constraint can spend some of their slack time reviewing the work in progress they pass to the constraint, so that the constraint doesn't work on faulty material
- resources behind the constraint should use their slack time to ensure they don't introduce faults which could cause throwing away work the constraint has worked on: wasting something the constraint has worked on means wasting throughput of the system.
- non-constraint resources can take over some of the constraint's work or provide some service which allows the constraint to focus on their throughput-creating work.
How much should each resource be loaded?
- The constraint must work at 100% capacity
- Non-constraints must work at less than 100% capacity
![]() |
What happens when the first resource works at 100%? An ever-growing pile of work builds in front of the bottleneck resource, wasting money and hiding quality problems (see the evils of inventory).
What if we let the first resource spend their slack time on another project, thereby keeping them 100% busy and not overloading the bottleneck? If we're not very careful, the first resource might not be able to feed enough work to the bottleneck, stalling the bottleneck and directly reducing the system's throughput. What if the third resource is kept 100% busy? They can't be busy processing the bottleneck's output, because in that case they would be idle some of the time. So, the third resource works on something else. If we're not very careful, the third resource might not be able to react to variations in output of the bottleneck, thereby delaying/wasting some of the bottleneck's output, thus delaying/reducing the system's throughput. The lesson: the goal of the system is not to keep resources busy. The goal is to generate the maximum amount of throughput! |
Two types of resources
In any system one can find two types of resources:
- Resources whose throughput is valued: analysts, designers, programmers... The more output they produce, the better. Keep these resources focused (one task at a time!) and busy on throughput-creating work.
- Resources whose response time is valued: secretaries, receptionists, coaches... They must be able to deal quickly with unexpected events, so that the throughput-generating resources are able to work at their peak. They will need to multi-task (and drop a task when some higher-priority interrupt happens) and shift their focus. They can only do that if they have the extra capacity ("slack") that allows them to react quickly and to be able to waste throughput by task-switching.

