Reluctance to change – Notebook

I’ve proposed an open spaces for DevOpsDays Amsterdam, 2021. The idea is:

The DevOps community pushes for people to change how they think and operate. When it comes to working better, we have proven tools, techniques, and even big picture ways of thinking like CALMS. You’re more than likely eager to try these new things, get better, change. However, many more people seem less than eager to change – your co-workers, managers, and the countless “others” in your organization. In the discussions I have with change agents and executives in large organizations, this reluctance to change is one of the top three concerning topics. I invite you to this discussion to talk about why people are reluctant to change, how you’ve worked helped people change, or, perhaps given up, and, hopefully, to share stories about your own experience overcoming reluctance. Our goal will be to move beyond being frustrated with “frozen” minds and middles, and get a sense for what to do about it…if anything. To start the discussion, I’ll start with a few stories and methods for getting people to change that I’ve encountered in the past few years.

Me!

In preparing for it, I typed in these notes:

Reluctance to change is one of the top concerns with executives and managers I talk with.

  • Frozen middle, frozen minds – often means “I don’t like what they’re (not) doing” – is that kind?
  • I want to talk about why people are reluctant to change; why you are; stories of success and failure in changing people’s minds, desires, and behavior/action.
  • Examples to start with:
    • Constant Planning, or, Analysis paralysis – they want to change, but think too much and don’t act. Fix: external problem/urgency, like (sadly) COVID, competition, dying/plateaued cash cow (not a very good motivator).
    • Fear of change – demonstrate that it works.
    • Seems like more work, or, won’t make their lives better, so why change? Show them that it make their lives better – automating things frees you up from tedium; automating for auditors saves them over-time; the new way can be more secure.
    • Changing job/responsibilities/identity. The DBA likes being the DBA, the network admin likes that – prove to them that it’s better.
    • Fear that they can’t change/learn the new thing – Coté doesn’t get around to learning Dutch, same fear. Related: embarrassment, e.g., Coté doesn’t buy from the butcher down the street cause he don’t speak Dutch (but, butcher doesn’t care – OF COURSE!) Fix: hard one, show success from peers.
  • Fixes:
    • General fix for all of this: build up success stories of their peers doing it.
    • Change motivations:
      • like money;
      • flow – removing friction (better quality of life and work-life);
      • raising individual profile with OSS work/fame;
      • autonomy;
      • closer to end-user to see value they provide.
    • Change structure. “Culture follows structure” – Larman’s Law – points out a common pattern/behavior. Once you know the behavior, you can start thinking about how to change/improve it.
      • “the organizational system (groups, teams, roles and responsibilities, hierarchies, career paths, policies, measurement and reward mechanisms, etc)”

You can also see me discuss these in one of my Tanzu Talk streams.