We have learned the tools of Systems Thinking: Behavior Over Time Graphs (BOTGs) to see patterns and Causal Loop Diagrams (CLDs) to find the structure. Now, let’s see these tools in action to solve a real, recurring business problem.
The problem, known as The ComputeFast Problem, is a classic example of a complex system resisting a simple fix. ComputeFast was a company that installed specialized software for clients, and they could not get the work done fast enough.
The Crisis: Fixing Symptoms That Kept Coming Back
For months, ComputeFast struggled with a major Service Backlog. Every time a new client signed up, the backlog of pending software installations got bigger. This led to angry customers, canceled contracts, and major stress on the installation team.
The Quick, Linear Fix
Company leaders applied a traditional, quick fix based only on the event:
- The Event: Customers are waiting too long.
- The Fix: Hire more technicians immediately.
This fix provided a small, short-term relief, but the backlog started growing again shortly after. The problem kept returning because the company was stuck in a cycle of symptom-level fixing. They were treating the pain without curing the illness.
Step 1: Using a BOTG to See the Failure Pattern
A Systems Thinker asked the team to look past the monthly event and use a Behavior Over Time Graph (BOTG). They tracked two key variables over a year:
- Service Backlog: The number of delayed installations (the symptom).
- Technician Skill Level: The overall experience and speed of the team (the system health).
The Shocking Pattern Revealed
The BOTG showed a clear, surprising pattern that proved the fix was actually failing:
- Every time the company hired new technicians, the overall Technician Skill Level immediately dropped.
- The Service Backlog would shrink for a moment, but then it would start growing again, often faster than before.
The data proved that the simple fix—hiring more people—was somehow hurting the system’s ability to solve the problem. The focus shifted from who to how.
Step 2: Using a CLD to Find the Hidden Structure
The team then used a Causal Loop Diagram (CLD) to map out the connections that caused this negative pattern. They discovered two hidden loops fighting for control.
The Reinforcing Loop of Failure (R1)
The team found that the very decision to hire more people created a negative loop:
- High Backlog forces the company to Hire New, Unskilled Staff.
- Hiring Unskilled Staff puts More Pressure on Existing, Skilled Technicians to train them.
- More Training Pressure means Less Time Available for Installations for the experienced team.
- Less Time for Installations leads to the Backlog Staying High or growing.
This was the core problem: The simple decision to hire created a huge time drain on the skilled team, which kept the backlog high.
The Balancing Loop (B1)
The intended fix was the balancing loop: Hiring more technicians was supposed to lead to more completed installations and lower the backlog. However, the time it took for a new hire to become useful (the time delay) was so long that the negative Reinforcing Loop (R1) always hit the system first, cancelling out the intended benefit.
Step 3: Finding the True Leverage Point
The CLD showed that the key problem was not hiring itself; it was the lack of a proper training structure. The system was broken because it forced the most productive people to take on a massive training burden.
The true leverage point was not in the budget for hiring, but in the time and structure dedicated to formal training.
The Lasting Solution
The ComputeFast team did not hire fewer people; they fixed the structure of the system:
- They assigned one dedicated, experienced technician to only train new hires for their first two months (removing the training burden from the main team).
- They slowed down the hiring pace to match the trainer’s capacity.
- They began measuring the skill level (a hard-to-measure factor) alongside the backlog.
The result was that the overall skill level went up, and the new hires became productive faster. The Service Backlog finally began to shrink, and the fix actually lasted because the company changed the underlying structure, not just the numbers.
Important: The ComputeFast case shows that the best place to intervene in a complex system—the leverage point—is rarely the place where the problem is most visible. The problem was seen in the backlog, but the solution was in the training process.
Conclusion
The ComputeFast story is a classic example of a complex system that resists simple fixes. The initial linear solution—hiring more staff—was a perfect example of a Fixes That Fail system pattern. By using BOTGs to see the pattern of failure and CLDs to reveal the hidden loop of draining the existing staff, the company found the true structure driving the problem. Systems Thinking moved the company from fixing symptoms to changing the underlying process, achieving a lasting solution.
