Nobody Ever Gets Credit for Fixing Problems that Never Happened

In 2001 MIT published a study on why process improvement typically fails. It was insightful and still highly relevant to what I've seen companies struggle with today. I think it's particularly poignant for startups that lack the industry experience to recognize these pitfalls themselves. The paper is a ~20 page report, which this post aims to shorten significantly. I highly recommend reading the original if you have the time!

Here is the paper:

PDF Article

Parent Webpage

Quality Improvement Initiatives

The paper's primary observation is that every decade or so introduces a new methodology or even turnkey program to help companies improve their output. For example, in the 1980's a quality approach/program called "Total Quality Management" (TQM) was very popular, but by the 1990's no new companies were adopting it.

The conventional wisdom has been that these fads die out because they aren't effective. However, the paper shows evidence that almost all companies that put serious investments into them came out ahead.

In fact, digging deeper shows that these fads tend to re-invent the same processes with only slight changes. Some can be mapped to each other directly with only terminology differences. This indicates the right implementation of any of them can yield improvements for companies.

Why Quality Improvement Initiatives Often Fail

Where quality initiatives fail is not the core concepts, but rather how they are implemented. Such processes are not well suited to a top-down or fast implementation. Hence most companies that make a half-hearted effort to implement them fail to do so effectively.

The paper puts this high effort required to be successful quite simply as: "you can't buy a turnkey six-sigma quality program."

This means companies already stretched for resources try a program like TQM as a panacea, fail to implement it properly due to lack of resources, and then blame the program for not delivering. These companies are frequently desperate for a magic bullet, and so are likely the same ones that will try the next rebranding of the same process and fail again.

On the other hand, companies that successfully implement improvements likely won't try a new fad every few years. Ultimately this means a lot more companies will fail with these programs than actually succeed.

How Process Improvements Work

The paper provides a model of how a company's "Capability" to produce value develops over time. A capability can be viewed as a machine that takes in effort and produces value. It's possible to put effort into improving the capability - so that it produces more value per unit effort in the future. However, the results of these improvements are delayed significantly. Capabilities also degrade over time, leading to lower value per unit effort if left unattended.

Many factors affect the variables in this machine. A common one is employee turnover - investments in capabilities decay much slower if the individuals involved in the improvements stick around to leverage and maintain them. Another common factor is the complexity of a capability - more complexity means slower improvements.

It is also worth noting that there is a high degree of risk in process improvements. Many process improvements fail to actually produce better value. The authors are fairly adamant that this is simply part of the cost in making process improvements as a whole. These failed projects should be amortized into the cost of the successful ones.

Why Improvements Fail To Happen

Improvements to capabilities inevitably require effort to be pulled from producing value. If production targets are set at the current capabilities of the team, it leaves no room for improving processes. This means the decay in capabilities dominates. This inevitably leads to worse outcomes over time.

In practice, teams almost always start with some additional bandwidth for maintenance and improvements. They also typically start with a solid process for bridging short term production issues (ex. overtime) differently than long term production improvements (ex. root cause analysis). However, as senior management tries to push for additional profits, they set targets slightly above what the teams can naturally output.

Most teams respond by shifting effort away from improvements towards production short term ("working harder"), with the goal of bridging the gap with improvements in the future ("working smarter"). However, once the gap is filled and the team is overworked, it's rare to put in further effort into improvements. Additionally, senior management only sees that their targets were achievable and sets the next targets higher. This cycle gradually adds pressure to a team until it has eroded any improvement efforts.

This cycle is particularly viscous for salaried teams because late nights and high effort is unpaid and untracked. This means there is no direct signal to management when it becomes a recurring pattern. However, even for hourly work the additional effort is pulled from what should be maintenance and improvements, leading to the same lack of signals to management while eroding capabilities.

The paper also points out that many teams take "shortcuts" that directly hurt their capabilities long term for short term gains. This might take the form of cutting down on communication or running equipment too hard. These shortcuts ultimately have the same affect as letting capabilities erode due to lack of maintenance, but are more commonly misinterpreted as positive when they actually hurt the organization.

Why Smart People Fail To Break The Cycle

Teams rarely catch these feedback cycles for a few reasons:

1. "Working harder" can work for a long time before your capabilities collapse. This means managers learn that this approach works.
2. It's hard to notice long term degradations in capabilities. This lack of a negative signal implies the current (flawed) approach will continue working.
3. Improvement projects are more likely to fail when nobody has time for them. This teaches teams that improvement efforts are wasteful.

These difficulties are systematic and don't mean a manager is particularly unskilled. They are seeing real signals and responding to them.

How To Fix It

The top advice from the paper is to avoid associating blame with problems. A problem should be fixed. An individual is rarely the sole reason a problem occurred.

This change in mindset is critical because assigning blame feels like action, but it isn't actually a solution. Once blame is assigned, there is rarely a reason to look deeper of fix systemic issues.

The second key advice is to make the entire organization aware of these feedback cycles. When teams don't realize that this can happen, they aren't on the lookout for it.

As an example, the paper told the story of a Du Pont initiative in the 90's where everyone went through role-playing workshops where they tried to optimize performance in hypothetical scenarios. They quickly saw these cycles play out during the workshops. Once teams were aware, they pushed back more appropriately on targets and recommended shifting effort to improvement projects more openly. This ended up saving millions with relatively minor effort.

Larger Feedback Cycles

Unfortunately, the paper leaves us on a somewhat somber note. It points out that any team that is performing too well will almost certainly undergo budget and personnel cuts to improve profits further. Even in the most optimistic case, high performers are likely to be moved to other teams to share their learnings. Ultimately any team is still at the whim of outside forces like their customers or investors.