Five Reasons Developers Resist Change

Five responses to handle the five reasons -- but yes, sometimes developers are simply change resistant.
Posted January 22, 2013

Eric Spiegel

(Page 1 of 2)

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.

Page 1 of 2

1 2
Next Page

Tags: developers, IT management

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.