It seems a truism to say change is hard.  Anyone who has tried to change their own habits knows this.  Anyone who has tried to change an organisations has no doubt found it difficult.  It has certainly been my experience, both in my personal life and in my work.  Change is hard.

But why is it hard?  I’ve met plenty of people who blame failed change efforts on the shortcomings of technology.  I’ve been one of these people.  But this reason holds little sway these days.  I agree with Laura Kunkel (@kunkiskrunk) who recently tweeted: “We can easily solve technical problems. Most of our problems will be people problems.”

I’ve worked with a people and organisations that want to shift their IT delivery to newer methods, Agile, Continuous Delivery, DevOps tend to be the goals.  And rightly so, done well these approaches to IT delivery can transform organisations.

And therein lies the problem.

In my next post I’ll talk about an approach to change management that is effective at building in lasting change.  In this one I want outline a few key reasons why change can be so hard.  Regardless of whether your wanting to move to new methods of working (Agile, DevOps etc) or implementing new processes (say good information and knowledge management practices) or trying to move to a more customer centred culture, or whatever, I believe there are a set of underlying psychological factors that make change hard if they are not addressed.


“Status is about relative importance, ‘pecking order’ and seniority. Humans hold a representation of status in relation to others when in conversations, and this affects mental processes in many ways.”

I have encountered status based change resistance fairly frequently.  In one organization there was a senior individual who many people said was blocking the change.  I met with this person over lunch, we had a great chat, we discussed the changes and he agreed with them ‘in principle’.  Over time it became increasingly clear though that he wouldn’t agree with them in practice because they weren’t his idea.  He was the senior person.  He was the subject matter expert. He was the guru.  To have a consultant come in and talk about the team changing their practices was taken as a direct assault on his status.  In the end he was moved aside into another team and the change went ahead and delivered the benefits.

“It can be surprisingly easy to accidentally threaten someone’s sense of status. A status threat can occur through giving advice or instructions, or simply suggesting someone is slightly ineffective at a task.”

In another organization I was leading an Agile transformation; based out of IT.  Once of the central governance groups went around me and my team, and the CIO, to the Chief Executive to have the change blocked.  When I met with the key stakeholders and talked about their concerns they largely (but not wholly) boiled down to a perceived loss of status.   The idea of teams being self-organizing in Agile is often taken as an assault on the status of more traditional power brokers (middle managers, enterprise planning, HR etc.).


“The brain is a pattern-recognition machine that is constantly trying to predict the near future…The brain likes

to know the pattern occurring moment to moment, it craves certainty, so that prediction is possible…even a small amount of uncertainty generates an ‘error’ response in the orbital frontal cortex. This takes attention away from one’s goals, forcing attention to the error”

My experience is that uncertainty is often expressed as fear and anxiety.  In Agile, and even more so in DevOps, the work that people building products do tends to become increasingly transparent.  Most people I’ve met have seen this as a good thing.  However, there are some who express significant uncertainty about this.  Because their model of the future is that if their work is more visible people will catch them out.  The uncertainty fans the flames of their imposter syndrome.  If they lack trust in ‘management’ this only makes it worst.  In most cases it’s not until they actually see people reacting positively to visible failures that they slowly come around.


“Autonomy is the perception of exerting control over one’s environment; a sensation of having choices…An increase in the perception of autonomy feels rewarding.”

Many of the developers, testers, BA’s and other product builders I talk too are really keen on Agile because it gives them autonomy.  As a team they choose what they will work on (given agreed constraints).  Conversely, many project managers I talk too are cynic or derogatory about it; in part because they no longer manage the team (i.e. telling them what to do).

When faced with any kind of change one of the key sources of resistance I see is expressed as “don’t tell me what to do.”  It’s people feeling like their autonomy is being overridden.  I remember one case where I was working with a person to see if I could get them to see the benefits of a change.  They agreed with all of it.  Finally, in a moment of frustration, they said: “but no one asked me.  It wasn’t my choice so I don’t want any part of it.”

It’s my experience that this is a common reaction to change.  Especially when people know the change is good.  “People to resist change; they resist being changed.” – Peter Senge


“Relatedness involves deciding whether others are ‘in’ or ‘out’ of a social group. Whether someone is friend, or foe. Relatedness is a driver of behaviour in many types of teams, from sports teams to organizational silos: people naturally like to form ‘tribes’ where they experience a sense of belonging.”

At their heart Agile and DevOps are about bringing people together into a single cross functional teams that collaborate to solve problems.  One of the kinds of resistance I’ve encountered in both spaces come from a violation of people’s sense of relatedness.  The classic in DevOps where developers view operations as the other; people who complain and whine about all the hard creative work developers do.  And operations complain and whine about how developers don’t care about having stable production systems; and the developers don’t wear the blame for their mistakes, operations do. I see very similar patterns of behavior between developers and test analysts.

Bridging the gap means creating a common ground upon which both groups can build a common identity in which to root their sense of relatedness.


“…fair exchanges are intrinsically rewarding, independent of other factors…People who perceive others as unfair don’t feel empathy for their pain, and in some instances, will feel rewarded when unfair others are punished”

I’ve seen people’s sense of fairness be violated the end of year performance review process.  They find out that they received a good result but this other person received a better result.  They perceive themselves as just as capable and complain that it’s not fair.  They were treated unfairly and unjustly.

I’ve also seen it when there has been someone who isn’t perceived to be pulling their weight in a team.  It’s very easy for people to lose their sense of empathy for that person and to want them to be punished.  This is probably the factor that frustrates me the most because usually people’s fairness trigger goes off when they perceive unfairness; that doesn’t mean the situation is actually unfair.  When I was talking to a friend about this he said: “Matt it’s human nature, people want mercy for themselves and justice for others.”


Yes, change is hard.  These days it’s less about the technology and more about the people.  So if you are planning to try to change a team or organization, or even just yourself, think about these factors and how they might come in to play.

The observant will have noticed that I’ve used the SCARF model.  All the quotes are from “SCARF: a brain-based model for collaborating with and influencing others” published in issue one of the Neuroleadership Journal (2008)