This is part 3 of a multipart series on changing core technologies in software systems and software-based services. Part 1 talked about the costs of change, and part 2 discusses the risks associated with change.
In some organizations, there are cultural roadblocks to change (or to avoiding change). Let’s face it: many people don’t like change. Change can be a cause of stress and anxiety. Some organizations have built up an inventory of processes and procedures that not only track and manage change, but in some cases work to prevent it. Not all groups and companies do this, but some do, and you need to be aware of the cultural and procedural issues within your own organization that will try to prevent or subvert a change.
For people who are averse to learning something new, changing technologies can threaten or scare them. This can be particularly true when a technology currently in use has been there for a very, very long time. For some, their entire career could be staked on a particular technology. The best you can do is try to motivate them, train them and help them along. You don’t necessarily want to “discard” someone because they outright refuse to “play along”, but in the worst case, you may have no choice. If the technology change is mandatory in some way, then so is the team’s need to move along with it.
The other threat, though, is some variant of the “rabid fanboy”. For them, some element of the current technology can take on a mythic status in their mind, turning them into something resembling a religious zealot. Some element of the technology you use today becomes an extension of themselves, and removing it means a repudiation of them as a person. They oppose the change simply because it doesn’t fit within their current technological belief system. To be honest, I don’t know what you can do about this type of person. Hopefully you don’t have someone like this, but I don’t see much that can be done.
For some organizations, there is a tremendous amount of process and procedural overhead. I have seen this in action in the past, and I only found a couple of ways around it. One was to simply grit your teeth, come to grips with the “rules of the game” and work through the process. Do the documentation, put together the justifications and analysis and simply grind your way through it. Even in the worst systems, if you can show how this will save money, improve profitability or avoid business failure, it should work out. It may not always, so be prepared for a long, uphill battle.
The other way (which can be career-limiting at a company, even if you succeed) is the “beg for forgiveness, rather than ask for permission”. If you do this, though, then the change had better work out with limited or no downside. You have to be 200% right, and you will have to justify the means the end no matter how good they are. This approach will only work for a select few people, and failure can have ugly consequences.
If you have the luxury of working on a small, motivated team at a smaller organization, then (hopefully) you can rely on rational thought and intelligent discussion to resolve any reservations about making a major technology change. This can be where prototypes can help again. Rather than relying on someone else’s case studies or a vendor’s claims, you may have to “prove it” to the rest of the team by actually showing the new technology in action.
No matter how good a change in technology will look on paper, at some point you will find someone who will oppose change. Their reasons may not appear rational, but it may force you to make sure you do your homework on all of the other aspects, and take away the opposition due to cost or risk.