This post will endeavour to explore the reasons why developers do not like organisational change, and how not recognising this could pose an issue for both developers and management.
No one likes change
Let me start off by saying that as humans we are not big advocates of change. To illustrate this, if I told you to move house every week, you would probably not be overly enamoured by the idea. We seek stability the majority of the time.
However, this is not to say we do not seek change from time to time:
- Move house
- Change job
- Re-decorate a room
- Change your car
No one likes to lose
From birth, it is pre-determined that we do not like losing. In the brilliant book Thinking, Fast and Slow Daniel Kahneman talks about gains and losses. I won't delve into the details of Prospect Theory here, but if you want to understand more I recommend reading the book.
In the book Kahneman explains how we react worse to losses than to gains, and are much more sensitive to losses. This fear of losing can help explain why developers are not fond of organisational changes.
For example, take the below scenario:
Company X has an software engineering department that consists of ten developers.
Company X wish to make some changes, if you were one of those developers, which one of the below would you prefer?
A - Company X proposes a change in which there is a 70% chance you will lose your job
B - Company X proposes a change in which there is a 5% chance you will lose your job
If you are like the majority of people, you will prefer option B, despite the fact that both options present potential losses (in this case, your job).
Unfortunately, when changes are proposed not all of the facts are known and so you would not be able to make such a decision as above. There normally is a large amount of uncertainty, and your decision to remain at a company will be a gamble.
The illusion of moving
When presented with an organisational change marked with much uncertainty, many think that moving company will be the solution. However, this is often a misconception and can often result in people hastily jumping ship and being disappointed when they realise that the grass was not in fact greener.
In this situation you must balance whether to stay or leave. You might even benefit from identifying some traits that you look for in a company, such as the ability to work remotely, and decide which opportunity will satisfy this criteria better.
Creatures of habit
As developers, we are creatures of habit. Much of the technology we like is chosen due to our familiarity with such technologies. For example, say your favourite programming language is Java, this will most likely be because you have a lot of experience using it and you have good memories programming in Java.
Now say your bosses tell you that you must now use C# instead, this conflicts with your passion for Java. You most likely view this change as a loss, not a gain. Therefore you will most likely make a fuss and voice your dissatisfaction of using C#.
Here you must take an objective view, if C# is more appropriate in this context, you must accept this.
My advice to developers
Hold tight, assess your options
In the event that you find yourself in the middle of a proposed organisational change, seek out as much information as possible to help you make your decision. See what you have to gain or lose from the change. If there is not much to lose then I would recommend seeing how the change goes, you might find yourself in an environment where you can learn a lot.
Be professional
Something I have seen before is how developers will often complain amongst themselves rather than engaging directly with management. This is very important as talking to management will help to solidify the relationship between management and developers.
Enter into a productive conversation with management, representing your colleagues in a professional manner and you will most likely gain the respect all of parties involved.
Understand you can't change the world
Within an organisation there will be a number of constraints that you will have to work within. Personally, this is something that I have found hard to come to terms with and only recently the light bulb moment happened. In the past I was treating the company I was working in as if it was my own, getting annoyed by the lack of perfection that I found.
However, these were constraints and you have to learn to work within them. This is by no means an attempt at being average, but more an attempt at being realistic. Attempting to win every battle will be both exhausting and time-consuming. Choose wisely.
My advice to managers
Empathise with developers
Understand that developers, like anyone else, are creatures of habit and will be skeptical of change. Listen to their views and provide them with enough information so they can make their own decision.
Don't impose change
Furthermore, try not to impose change on developers. Often I have seen change being forced on developers rather than actively engaging them in discussion early on in the decision making process.
Be professional
Similarly to the advice for developers, don't fall into the trap of talking amongst yourselves, bad-mouthing developers when you could be entering into an intellectual and productive conversation, united by the desire to represent your department.