Five reasons developers resist change

Oh no, again, just not that!

The head of the department just informed us that another reorganization awaits us. All I could think about during his speech was “Well, here we are.”

The bosses are changing, but the mistakes remain the same. The past boss was all too busy; this one at least tells jokes and tries to be funny. But the fact that we will once again have to go through the changes is definitely not funny.

Why do most developers do not stand the spirit of change? There are many reasons for this that make the natural mechanisms of human protection work. These reasons protected us from the dangers of the century, we survived thanks to 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 fed up with change.

This is especially true in cases where the development team has some kind of new manager who is about to leave his mark on 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 all leave as we are?”

I’m not sure that I will ever hear this phrase!

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

And here are five reasons why we are showing resistance to change - well, some tips on how we can deal with this.

Shame

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

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

We all plunged into a trance. Now it became obvious to us that we had not just made a mistake that could be easily corrected; our team was losing sight of the rest of the enterprise in front of our eyes - and this was happening in the part for which we were usually slapped on the back.

Of course, it never occurred to anyone to try to work with a consultant - since it seemed to us that this was a waste of time and money. All this resulted in the fact that the resulting document from the consultant was filled to the brim with extra details that made the new manual completely unusable.

That's 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 any problems again.

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

Bad planning

This time our team, the team managed to do everything on time; one more test - and we go to the "gold". Then the head of the quality control decided to re-orient the testing process, including changing the pass / fail criteria. Even in the best of times, such a decision would not have been made without some grunts from the developers.

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

The development team rebelled. We vowed 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 sit together, so we could not hold out for several days.

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

In fact, Steve Jobs would probably do exactly the same as our leadership - all because he was a perfectionist. Of course, this did not bring him much love among Apple developers, nor did he bring our quality control manager.

If you are going to change something during the development process, then first analyze the risks - so you won’t be surprised at the results later.

Fear

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

The team lacked self-confidence even to just try a new language. Yes, they got so close to what they had been using 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 been working 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 fascinated by the new language and scared. At this time, different thoughts come to mind ... But what if I just can not overpower him? What if I lose my job?

The manager should slowly introduce the team a new language and help with the training of the team, continually adding various materials to the developers. In addition, it is absolutely necessary to talk with them about emerging fears and their overcoming. Those who do not want to learn a new language can be offered some other task or project.

Mistrust

At the beginning of my story, I pointed out that. that our previous experience may ultimately 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 done before him needed improvement, but first he should spend some time with us, and not get down to business without any preparation.

If you have become the new leader in the organization, then before you are going to change something, take care of your confidence in yourself. Find out from employees what they think about change, hold round-table discussions - research what you have to change! And if after that the thought that you need to change something does not leave your head, then be as careful as possible in your explanations of why you needed 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 don't like change. It may be difficult for them to cope with them; then it doesn’t matter how well you teach them how to easily deal with them or even predict them - they will never accept change.

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

If most of your efforts to overcome resistance to change are still not successful, then do not spend 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 has been said and done, you can not try to be funny or sweet. Do your thing; Explore, learn and communicate more with others. After all, if you can’t approach this change wisely, then the next change in your life may be the search for a new job.

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