Five reasons why developers resist change

Oh no, again, not that!

The head of the department has just informed us that we are waiting for another reorganization. All I could think about during his speech was “Well, here we are.”
')
The chiefs are changing, but the mistakes remain the same. The previous boss was all too busy all the time; this one at least tells jokes and tries to be funny. But the fact that once again we have to go through changes, as if there is nothing funny.

Why are most developers in the spirit can not stand the change? There are many reasons for this that make natural mechanisms of human defense work. These reasons took care of us from the dangers of the century, we survived through fear and skepticism. Why is our reaction to major changes associated with negative feelings, and not with feelings of positive acceptance and optimism?

Because most of us are already fed up with changes.

This is especially true in cases where the development team has some new manager who is going to leave his mark in the history of the organization. How many living managers come to the new team and say “Wow, your processes and technologies are so perfect that we leave everything as it is?”

I am not sure that I will ever hear this phrase at all!

Of course, people have long discovered in themselves this resistance to any changes. No wonder the popular book on this topic, “Who Stole My Cheese?” (“Who Moved My Cheese”), sold 23 million copies. But developers, as a rule, seek to analyze all the incoming information, and too simple metaphors, given in it, will seem to them to be nonsense. If they read this book at least a hundred times or even attend a seminar, this will not affect them in any way, especially if they have already faced unsuccessful changes more than once in their careers.

And here are five reasons why we show resistance to change - and some small tips on how we can deal with it.

Shame

Our team has created a guide to support and update the enterprise ERP system, which we ourselves found simply excellent. When we started to work, everything really went fine - but only until that time, until we ran into the unfortunate transfer of data during the update. Our IT-director got from the finance department, and the next “got what he deserved” our manager.

When it became clear that the reason was that there were many inconsistent steps in the development process manual, our manager hired a consultant who had to rewrite this document from scratch. He informed us all about this decision by e-mail, literally tearing apart our current plan - and all this happened somewhere in the middle of the work process.

We all plunged into trance. Now it has become obvious to us that we have not just made a mistake that can be easily corrected; Our team was losing face in front of the rest of the enterprise - and it was happening in the part for which we were usually slapped on the back.

Of course, it never occurred to anyone to try to cooperate with a consultant - because it seemed to us that this was a waste of time and money. All this resulted in the fact that the resulting consultant’s document was filled to the top with unnecessary details that made the new management completely unsuitable for use.

That is why we secretly saved a revised copy of the old manual. Our manager, by the way, never found out about it - and we never had problems again.

All this could have been avoided if our manager had not reacted too seriously to the problem. So a little advice - take the time to analyze the problem of “post mortem” before making a decision about large-scale changes.

Bad planning

This time our team was on time; one more testing - and we are entering gold. Then the head of quality control decided to alter the testing process, including changing the pass criteria (pass / fail criteria). Even in the best of times, such a decision would not have been made without some grumbling from the developers.

But, Jobs take you, why did you decide to do it right now ?!

The development team has rebelled. We swore that we would not wash and shave until the management changed its mind. Of course, it was a little childish and did not bring any results. In addition to all the problems, it soon became too stuffy for us to all sit together, so we did not last a few days.

In the end, the release of the application was delayed for three weeks. And each of us was (completely unfair!) Declared responsible for this, as was written in the report on the effectiveness of our work.

In fact, Steve Jobs might have acted in exactly the same way as our management - all because he was a perfectionist. Of course, this did not bring him much love among the Apple developers, nor did it bring our quality manager.

If you are going to change something in the development process, then first analyze the risks - in order not to be surprised at the results.

Fear

Fear very often becomes the number one reason why people try to avoid change. I already came across this topic when one of our developers suggested using Scala as a new primary development language. The rest of the team (including our manager) was frightened by such a serious change.

The team didn’t have enough confidence to even try a new language. Yes, they clung so closely to what they had used for years - and they did not want to leave the comfort zone.

Fear can be circumvented with new knowledge and increased self-confidence. If a developer has worked with the same technology for many years, then the manager should not assume that his proposals for using something else are waiting with open arms. In addition, from personal experience I can give an example, when I was both delighted with the new language and scared. At this time, different thoughts come to mind ... And what if I just can not master it? What if I lose my job?

The manager should slowly present the team a new language and help with the team's training, continually putting different materials to the developers. In addition, it is absolutely necessary to talk with them about emerging fears and overcoming them. Those who do not want to learn a new language can offer some other task or project.

Mistrust

At the beginning of my story, I pointed to that. that our previous experience may eventually lead us to skepticism about everything new. This circumstance must be taken into account.

In my case, the new boss tried to change something just because he wanted to show himself. Yes, even if everything that had been done before him needed improvement, but first he should have spent some time with us and not get down to business without any preparation.

If you have become a new leader in the organization, then before you are ready to change something, take care to trust yourself. Ask the workers what they think about the changes, hold a round-table discussion - study what you have to change! And if after that your head does not abandon the idea that you need to change something, then be as careful as possible in your explanations, why you need all this, and try to rely on the facts as much as possible.


Active resistance - Passive resistance - Acceptance - Active support

Just because"

Many developers simply do not like change. It may be difficult for them to cope with them; then it doesn’t matter how well you teach them how you can easily deal with them or even predict - they will never accept changes anyway.

The result is something like the struggle of Democrats and Republicans in the United States: neither they nor others will ever finally win, if only because everyone is firmly convinced that he is right and his rival is not. Often, the developer is so faithful to any one technology that he will not even listen to any of your arguments for another.

If the majority of your efforts to overcome resistance to change is still not crowned with success, then do not waste too much time on such a person. Instead, try to win the hearts of most of your team. You will win and be able to move on.

When everything is said and done, you can not try to be cheerful or sweet. Do your thing; explore, learn and communicate more with others. After all, if you cannot wisely approach this change, then the next change in your life may be a search for a new job.

Original article: Eric Spiegel, "Five Reasons Developers Resist Change"