Software modernization is fundamentally all about change—new technologies are the most visible, and often most exciting, aspects of modernization. However, technology doesn’t stand alone: Systems are created, maintained, and used by teams of people across organizations—from the developers to the business stakeholders to the end users—and people have built-in limits to how much change they can comfortably adapt to. Pushed past this point, people are likely to experience a range of problems that put the modernization project at risk, whether that’s losing the ability to gauge actual project progress, revolting against the further introduction of anything new, or being unable to maintain a production system. To avoid these consequences, it’s critical to be realistic about what amount of change people can internalize and keep that at the forefront of planning. Cultivating an incremental approach to change will up the success of major IT projects like modernization by building organizational acceptance.
The emotional threshold
How do most people deal with change? Frequently, not well. When I was six, my parents bought a house across town from where we were living at the time. Being six, I didn’t really understand that eventually, all of our belongings would make their way from our old house to our new house, but that it was easier for my parents to move things over a bit at a time. What I DID see was that one day, all of my books were gone. This was a little confusing, but I could accept it. The next day, my toys were gone. This was more concerning, but I could still deal with it. Then, the third day, my bed was gone—this was suddenly too much! The toys and books were one thing, but my bed, too?! Suddenly, my parents found themselves with a screaming 6-year-old on their hands.
In the business world, we may not express ourselves by screaming when change becomes overwhelming, but at our core, our reactions are really not so different. We can reach an emotional breaking point and react by instinct. People are only so flexible, and organizations, made of people are only so flexible too. Go past the natural point of flexibility, and something is going to break down. What’s worse is that the shift from comfortable to uncomfortable isn’t always gradual—that overwhelmed feeling can come on suddenly, so the warnings signs might be subtle.
Further, you might not think to “count” some changes as potentially overwhelming. For instance, maybe we consider updates to the core tech stack to be “change,” but we forget to consider changes to development tools such as a new IDE or a new type source control as an additional load. Or maybe you overlook the significance of a process change—switching to Agile when you were used to waterfall, for instance. It might be that adapting to Agile is about all the change the team can take on, and still deliver.
Finding the pressure source
Sometimes technology teams can push too much change on themselves: For developers, it’s really hard to say no—they tend to get drawn to the newest and shiniest thing, especially when tasked with updating a system. They sometimes find themselves choosing technologies that look exciting, but may end up introducing too much risk into the project. Juggling too much unfamiliar technology means they won’t know all the pitfalls or be able to anticipate problems. In this case, a lot of work can end up getting thrown away because tech choices were fundamentally unsuitable/not viable, or because the actual effort needed to get to production is underestimated. While it can be manageable to account for one unfamiliar technology, throw together several and the interactions can lead to large amounts of unanticipated work. Say you’re introducing a relational database alternative like MongoDB to a project for the first time while also moving up to .NET Core. That’s a big job, but beyond that, there may be special considerations for using the two together, or add-ons that you need to get them to work. Do you know how to work with both in your testing framework? It’s going to be difficult to think about these kinds of interactions when you’re familiar with neither technology.
Other times, developers push too much change on the rest of the organization: The new technology may be comfortable for them, but unfamiliar to the business. The tech folks might feel like they are “doing right” by pushing the business to adopt an all-new, fully modern stack. They may feel the idea of leaving old technology in place is a personal affront to how the world should be. This can happen both with external consultants and with internal developers at an organization. However, if the business is not ready to take on that much change, they might get left with a pile of stuff that they aren’t ready to own and maintain—and are likely to feel frustrated and overwhelmed as a result. In that case, the business might cancel the whole project due to lack of understanding and confidence, or take on the high risk and cost of authorizing something in production that the organization doesn’t know how to use, and maybe isn’t able to keep running at a basic level, meaning a lot of downtime.
Alternatively, the business stakeholders might be advocating too much change from their side. They might have a fire lit under them by investors or by customers or partners to improve things fast, but not be ready for the fallout of having the world turned upside down. Leaders might be overly optimistic about how much better the new system will be and downplay the risks or the amount of turmoil they are about to inject into their own business. This results in too much change for the developers to maintain, too much for the business to learn and understand, and possibly in widespread failure as the changes spiral out of anyone’s understanding. End-users might stage a large-scale rejection of anything new, falling back on the common refrain, “Why can’t we just use the old system?” But it doesn’t have to be all or none. An incremental approach to modernization can mitigate the amount of risk and ease the transition to something new.
Choosing what to change
There really isn’t a hard-and-fast rule for exactly how much change is likely to be a safe amount—each modernization project is different, and all people are a little different. However, not more than three or so changes at a time has proven a good starting heuristic—and maybe fewer if any of those changes are going to be really substantial. For instance, if introducing a significantly different system architecture, it might not be the best time to also introduce a completely new business workflow into the mix. Each one of those changes is plenty to take on by itself.
Understanding what the individual people involved can actually take on is going to be critical, and not just by relying on heuristics. Throughout any modernization effort, it’s a good idea to meet with stakeholders frequently and keep an extremely close eye on reactions. The more change has already been locked in, the more seriously to take even a small spike in reactions to new things that are introduced—these could signal pent-up stress about changes starting to leak through. Not everyone is self-aware enough or outspoken enough to clearly speak out about their concerns, but that doesn’t mean that their discomfort isn’t going to cause big problems.
If discomfort is approaching a level beyond what people can accept, it might be time to put off some change. This doesn’t mean you need to cancel your modernization project and stay stuck in the past. However, it might mean that it needs to be tabled until people are used to the changes that are already in the pipeline. Once people have adapted to prior changes and accepted a new norm, there’s more room to introduce new initiatives. If you introduced three changes a few months ago and two of them now seem natural to the business and everyone is comfortable, you’ve now got room to introduce another two or so. Taking into account what people need to feel comfortable will help here too. For instance, keeping them informed about when changes are going to be introduced, and providing them training materials should shorten the time to adapt, and the time needed to wait before introducing something else new.
Change often isn’t easy, and often isn’t comfortable. It’s stressful, and takes work. Overloaded with too much change, people can react badly, struggle, and even rebel. Risks of ignoring this emotional factor range from turning on a system that no-one knows how to keep running to the cost and expense of pushing through a system that the users refuse to switch to. However, with an incremental approach to keeping change below people’s breaking point and in line with their ability to adapt, it’s possible that people can learn new skills they need, accept new tools and patterns, and sail through changes successfully. It might not be as quick as everyone wants, but a slower, successful rollout is better than a fast failure.