Five Reasons Developers Resist Change

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Oh no, not again!

Our division director was explaining yet another reorganization to the staff. All I could think was, here we go again.

Same mistakes, different directors.

The last director had promised nirvana with changes she put into place only a year before – after which she was replaced by the jolly fellow now standing in front of the same skeptical applications group.

The last director was all business. At least this guy was cracking jokes and trying to be funny.

But there was nothing funny about going through one more change.

Why are most developers so abhorrently opposed to change? There are many reasons change raises a human’s natural defense mechanisms. Reasons that have kept us from danger over the centuries, chiefly based on fear and skepticism. Why is our reaction not naturally geared towards acceptance and optimism?

Because most of us have been burned by change.

This is especially true when many developers have had a new manager come in to put their mark on an organization. How many of these managers actually come into a new group and say “Gee, your processes and technologies are perfect so we’ll leave everything exactly as it is?”

Not likely!

It isn’t that humans don’t recognize our resistance to change. Case in point, the book “Who Moved My Cheese” (some call it the change Bible) is about how to deal with change. It’s sold over 23 million copies.

But developers tend to be analytical and probably think such simplistic metaphors used in that book are nonsense. They could read the book a hundred times and even get training on how to deal with change – it still wouldn’t matter if bad change has been the norm in their careers.

So how should management approach change? Here are five reasons there are resistance to change and what can be done to counter each one.

1) Shame: The team had put into place what we all thought was an awesome process guide on how to maintain and upgrade the company’s ERP system. Everything was going swimmingly until we had a very bad data conversion experience during an upgrade. My CIO was skewered by the finance department, which subsequently lambasted my manager.

When it became clear there was an inconsistent set of steps in the process guide, my manager hired a consultant to rewrite the entire thing. He announced this rewrite by emailing the entire group, ripping apart the guide in the process.

We were all ticked off.

Not only did we know this was a minor glitch that could be easily adjusted, but now the team was losing face in front of the rest of the department over something we had been originally patted on the back for.

Of course no one wanted to cooperate with the consultant because we felt it was a waste of time and money. This resulted in the consultant rewriting a terrible guide with lots of unnecessary fluff that made it difficult to use.

So we all secretly kept a copy of the corrected old guide. Our manager never knew – and we never had any more problems.

This could have easily have been avoided if our manager hadn’t overreacted. Take your time and do a thorough post-mortem analysis on a problem before assuming major change is needed.

2) Bad timing: Our team was cruising to an on-time deliverable. Just one more round of testing and we’d be golden. Then the head of QA decides to revamp the testing process, including tightening the pass/fail criteria. Even at the best of times this decision would be received with little push back.

But for the love of Jobs, why now?

The development team mutinied. We swore we would not shower or shave until they changed their decision. Of course, this was ridiculous and ineffective. Plus we couldn’t stand our own stink. So this grooming strike only lasted a few days.

In the end, the software release was delayed about three weeks. And every one of us was (unfairly) dinged for this in our performance review.

Actually, Steve Jobs probably would have done the same thing since he was a perfectionist. Of course that didn’t make his teams love him more, just as there was no love loss for our QA manager.

If you are going to make a process change, do a risk analysis first to see what the impact will be.

3) Fear: Fear may be the number one reason people shun change. I actually wrote about fear leading to change resistance this past summer where a developer tried to introduce Scala as a new development language. The rest of the team (including the manager) was afraid of this change.

The team lacked the self-confidence to even try a new language because they were so ingrained in what they already were comfortable with.

Fear can be overcome by knowledge and building confidence. If a developer has been working with one technology for many years, a manager cannot expect to bring in a new technology and expect every developer to embrace it with open arms. I can remember being excited about a new language being introduced but also being scared. What if I just didn’t get it? Would I lose my job?

A manager should slowly introduce a new language and provide education resources for the team to come up to speed. And talk to developers about their fears and what can be done to assuage them. Look for other career options for developers who just don’t take to the new language.

4) Mistrust: At the start of this article I pointed out how past history of failed changes can lead to a high degree of skepticism. This is basically a mistrust of management to make sound decisions.

In my case, the new director was making change for the sake of making his mark. Yes, the existing organization needed improvement, but he should have taken his time – again, another example of management jumping the gun.

If you are a new leader in an organization, before you announce a change, take time to build trust. Ask for the staff’s feedback, have round-table discussions – do the research! And only then do you announce the change, using carefully crafted communications that explains the research completed and the fact-based approach to making the change.

5) Just Because: Well, the fact is many developers just don’t like the idea of change. They may simply be difficult people to deal with. No matter how well you educate them and proactively communicate, they will never accept change.

Kind of like far left Democrats trying to win over far right Republicans. It’s not going to happen because both believe they are right and the other is wrong. You may find developers feel so strongly about a particular technology that they are not willing to budge and are not open to reason.

If your best efforts to avoid the other change resistance factors are not sinking in, don’t waste too much time on these folks. Instead, focus on winning over the majority of the staff. Then consider it a victory and move on.

When it’s all said and done, don’t try to be funny or cute. Do the hard work. Research, educate and communicate!

If you aren’t smart about change, then your next change could be to a new job.