Firefighting and the Tipping Point

Definition

Firefighting — dropping planned work to chase urgent problems — is not an occasional response to bad luck. Once an organization crosses a resource-utilization tipping point, even a temporary overload triggers a self-reinforcing spiral in which firefighting replaces disciplined process entirely, and performance keeps degrading even after workload returns to normal. "Bad systems beat good people every time."

In the Book

Oosterwal grounds this in an MIT research collaboration that studied Harley-Davidson's development organization (the "MIT Connection," Chapter 5) after a project called Beavertail blew past its timeline and consumed head-of-the-line resources at the expense of every other project in the portfolio — the engineering saying "at launch, all debts are forgiven" captured the mindset. The MIT study found that firefighting, though well-intentioned when it starts on one troubled project, quickly spreads: organizations that tolerate even isolated instances soon find firefighting has become their entire development process. The book identifies three lessons from operating "beyond the brink": firefighting drives out disciplined execution once initiated; an influx of workload can permanently degrade system performance rather than just temporarily strain it; and the location of the tipping point is set by the steady-state level of resource utilization — the leaner an organization runs, the smaller a disruption needed to tip it into the spiral. Crucially, when performance craters, managers reflexively blame the engineers working within the system rather than questioning the system's structure, which prevents the real fix.

Why It Matters

This reframes chronic firefighting as a systems problem with a measurable trigger (resource utilization) rather than a people problem to be solved with more heroics or better individuals. It gives leaders a lever — deliberately managing slack and WIP rather than running at maximum utilization — and a diagnostic question to ask before blaming staff: has the system already tipped, and is the workload simply too high for stable flow. The pattern generalizes to any resource-constrained system (support queues, hospital wards, on-call engineering) where efficiency gains push utilization toward a threshold that trades steady-state throughput for catastrophic fragility.