The Human Side of Modernization

Modernization often faces more human challenges than technical ones. CloudFrame’s COO Hans B. Otharsson highlights that successfully modernizing systems requires addressing the emotional and cultural barriers to change. He reflects on his experiences to shed light on the deeper dynamics of modernization, focusing on resistance, ownership and the need for collaboration.

Modernization: A Challenge Rooted in People

Modernization isn't just about updating technology, it’s just as much about addressing the human factors that can make or break a project. The emotional aspects of modernization—fear, resistance, and hesitations that accompany change—can be more complicated than the technology itself.

Application modernization is more of a corporate culture, people, and technology issue than just a technology problem. Resistance to change is a significant barrier. If the corporation or the people don’t want to change, it doesn’t matter what technology you bring in, how much money you will save, how fast you can get something done or how much it’s going to improve the end customer experience. If people don’t want to change, or you’re not able to get them to change, you’re not going to move forward.

The Brick Wall of Resistance

Resistance often manifests at the executive level, with leaders struggling to implement changes without triggering backlash. I’ve encountered this issue when dealing with CFOs and CEOs. They sometimes hit this brick wall of resistance when attempting to implement modernization initiatives.

This leads some leaders to adopt heavy-handed approaches like modernization mandates. That drives a whole other sort of resistance and can create bigger problems by pushing people further away from accepting the changes.

Lessons from the Government Sector

I once worked with a small state government department responsible for critical social welfare programs—small team, lots of pressure and annual compliance changes. This department’s work carried immense responsibility, as it directly impacted citizens’ lives. The work was about getting money to people who needed it. Those who do this work, they do it because of the citizens. It’s not just a job to them. You don’t put up with all the pressure, the bureaucracy and the difficulty unless you have a passion for helping people.

However, this dedication led to resistance to modernization. They were worried that the new systems were not going to work and that the citizens would lose access to essential services. They also saw modernization as a threat to their jobs and a disruption to how they’d been doing things for years. To them it seemed like the modernization initiative was second-guessing their decisions and methods, and they felt a great deal of ownership over these systems.

Us vs. Them

Organizations often fall into an “us vs. them” dynamic, with clear divides between those pushing for change and those resisting it. The people maintaining the legacy systems need to be brough across to embrace the changes, or they may create roadblocks, intentionally or otherwise. The difficulties can range from not getting access to the source code to being given the wrong source code or not getting the right test data when validating and verifying. This can lead to not understanding how the systems work, failing validation tests and similar issues. The legacy system owners can then use your failures to justify their resistance. This can stop the modernization process dead in its tracks as early as the proof-of-concept phase. I’ve run into these issues many times, including while working for CloudFrame.

A Call to Focus on People

In navigating these challenges, the most important thing is collaboration. You have to get those who maintain the systems today to embrace the change. If you don’t, you’re going to face enormous difficulties.

So how do you accomplish this? You have to bring those who own the legacy systems into the fold. Engage with them, have open forums where they can discuss their issues, give them a voice. Let them bring up their concerns and offer input on the best way to move forward. And it’s not just about them, it’s also about you. You need to understand their hesitation, their concerns, and be able to address them to their satisfaction. That takes not only subject matter expertise and experience, but a willingness to listen and understand. You can’t be dismissive, you can’t say, “Your concerns aren’t valid, this will work, trust me.” You need to convince them.

Another essential element is framing the changes as something positive. It’s not a replacement, it’s an enhancement, and not just to the systems. It can be an enhancement to the current owners’ roles. What they are responsible for now can change and grow into something bigger, something even more vital. This won’t work for everyone as it can be hard to overcome fear of change, but there will always be people who will embrace learning new skills, broadening their capabilities and enhancing the value of what they provide. If you can show them that modernized systems will provide more value to the end users, then you can get the current owners to embrace the change as an enhancement to their roles.

The DIY Dilemma

Another element of resistance can come from those who have embraced the need for modernization but feel that the best way to move forward is to rewrite legacy applications themselves. They believe this will be not only an opportunity to learn new skills and broaden their capabilities, but also a path towards enhanced job security since manual rewrites can take a very long time. And in that time they will master a new language and ensure their usefulness to their organization for the foreseeable future.

Such people need to be convinced that automation will be a benefit to them, which isn’t hard to do on the technical side, but can be challenging when dealing with human imperatives. I believe the key to this is to explain that manual rewrites involve a copious amount of repetitive and tedious tasks that automation would eliminate. In turn this would free our intrepid developers to focus on more engaging and interesting tasks like feature and functionality enhancement, which would bring more value to the end users and the organization. It would also eliminate the bane of all developers, human error that leads to buggy code. More value, better results.

As for learning a new language and enhancing job security, I’ve found that getting COBOL programmers to learn Java is pretty simple. It’s really the same thing, just different syntax, nomenclature and verbiage. Programming is programming, and learning a new language doesn’t need to take as long as a manual rewrite. Furthermore, COBOL programmers don’t need to learn a new language to remain essential. Expertise in COBOL is a dwindling talent pool, and COBOL isn’t going anywhere. Those with COBOL skills will remain essential until they retire.

Explain these things well enough and you’ll turn that resistance into support and get those involved to be advocates of the process.

In Closing…

Ultimately, modernization must prioritize people over systems. The human factor is the hardest part to manage but also the most important. By engaging with those maintaining legacy systems, fostering trust and bridging divides, organizations can ensure that modernization becomes a collaborative success rather than a battleground of resistance.