We are thrilled to announce 📢 Kosli is now SOC 2 Type 2 compliant - Read more
New Feature: Kosli Trails is liveCreate comprehensive audit trails for any DevOps activity - Read more
Kosli devops change management It’s 2021! Why does Change Management still suck?

It’s 2021! Why does Change Management still suck?

Mike Long
Author Mike Long
Published December 2, 2021 in features
clock icon 3 min read

There’s an excellent management paper from 2001 called Nobody Ever Gets Credit for Fixing Problems that Never Happened. In it, the researchers looked into how companies create and sustain process improvement. Even though the focus is on Total Quality Management (TQM) and manufacturing processes, the paper contains a ton of useful models for software development organizations. It also helps to explain why the current state of change management still sucks. As the authors pointed out….

“Soon afterward, the problem was solved, confirming the boss’s belief that they had acted appropriately, indeed had decisively taken charge of the situation, even though the team was already working around the clock and his interference drained precious time from their efforts to solve the problem.”

Decisions, decisions…

work harder work smarter image Kosli

The main investigation looks at the system dynamics of how organizations close performance gaps. In other words, the difference between desired performance and actual performance. They identify two causal loops that can be executed based on a desire for higher performance:

  • Work harder loop (B1): longer hours, more effort, more pressure to do work.
  • Work smarter loop (B2): more time spent on improvement, more pressure to improve capability, more investment in capability

Working harder loop

I found it super interesting that they model Capability as an asset that can accumulate improvements over time. This framing of capability is a useful mental model when thinking about how knowledge work gets done.

The paper asserts that “everyone knows it is better to work smarter than harder,” but in their investigations they found many organizations still default to the work harder mode. Why does this happen?

BIBO: Bad Incentives -> Bad Outcomes

The researchers found that a combination of bad incentives and cognitive biases were underlying the irrational reaction to work harder despite having the knowledge that working smarter is more effective. Put simply, the problem is all in our heads.

Let’s take a look at the first issue: incentives.

“While investments in capability might eventually yield large and enduring improvements in productivity, they do little to solve the problems managers face right now”. You can see this modelled as DELAY in the figure.

Worse still, when there is failure demand, a temporary emphasis on working harder quickly becomes routine.

In other words, we tend to discount the future. The authors provide a vivid illustration of this worse-before-better dynamic in figure 6:

nobody ever gets credit for fixing problems that never happened

Beyond incentives, they commonly found that managers had a tendency to conclude that the “cause of low throughput is inadequate worker effort or insufficient discipline, rather than features of the process". This is a classic example of the fundamental attribution error.

Change Management still sucks

So, getting back to Change Management, the current status quo is terrible. And it’s terrible for the same reasons - bad incentives and cognitive biases.

Firstly, we have the silo problem: those imposing the rules are not responsible for following them, and those following the rules are not empowered to improve the system.

And secondly, improvement has short term costs while working harder has immediate benefits. A long term investment in capability to drive high performance requires commitment and systems thinking.

Working HARDER at Change Management Working SMARTER at Change Management
More frequent CABs Continuous Compliance
Better ticketing systems DevOps Change Management

The paper concludes with this upbeat message:

“The only barrier was a mental model that there were no resources or time for improvement”

🤓


ABOUT THIS ARTICLE

Published December 2, 2021, in features

AUTHOR

Stay in the loop with the Kosli newsletter

Get the latest updates, tutorials, news and more, delivered right to your inbox
Kosli is committed to protecting and respecting your privacy. By submitting this newsletter request, I consent to Kosli sending me marketing communications via email. I may opt out at any time. For information about our privacy practices, please visit Kosli's privacy policy.
Kosli team reading the newsletter

Got a question about Kosli?

We’re here to help, our customers range from larges fintechs, medtechs and regulated business all looking to streamline their DevOps audit trails

Contact us
Developers using Kosli