When we consider the task of updating legacy software, our minds often jump straight to the technical hurdles: How will we modernise that outdated API? Is it time to restructure the database for efficiency? And crucially, how do we implement these changes without disrupting ongoing business operations? These questions, while vital, only scratch the surface of a deeper, more complex challenge.
In focusing solely on the technical, we risk overlooking a crucial component of any modernisation effort – the dedicated team that has been maintaining these systems. Dismissing their deep-rooted understanding of the current system as outdated or irrelevant is not just a mistake; it’s a missed opportunity. These individuals often hold the keys to why things were designed in a certain way, offering invaluable insights that can guide the modernisation process.
However, this raises a number of challenges:
-
How do we harness this wealth of knowledge while simultaneously addressing the skills gaps that inevitably arise with the introduction of new technologies?
-
How should we navigate the resistance to change that can manifest within teams accustomed to certain workflows?
-
How do we avoid potential barriers forming between the existing team and any new people we bring in to help with the transformation?
Incorporating the team’s expertise into the modernisation journey requires a strategic approach, one that values their contribution and facilitates their growth.
Learning from the Team
The first step in any transformation is understanding the current system from the perspective of both developers and users. Many companies have internal wikis or even a collection of design documents. While these can provide a good start, they are likely not up-to-date.
Assuming that’s the case, it can be instructive to look at how new developers are inducted onto the team. What is involved in setting up their computer? What materials are they given to bring them up to speed? How do the current developers explain the system to them? This can be a good way of flushing out some of the complexities of the current system and highlighting areas the team views as problematic.
Following on from that it is useful to interview team members, asking them to describe the system and drawing architecture diagrams based on their knowledge and understanding. While doing this, it’s important not to make judgements but rather show curiosity and ask probing questions to understand the how and, just as important, the why.
Having gained some understanding from the developers, one of the following steps should be to interview different users and ask them to demonstrate how they actually use the system. Ask about how well the system supports what they are trying to achieve and how they would improve it. So often processes are determined by the software rather than what it is people are trying to do. These processes may have been influenced by technological constraints from when the system was developed which no longer exist, and so trying to separate business goals from how the current system works is vital.
Valuable insights can be gained by comparing the users’ understanding of the system with the developers’. Are there areas where they significantly differ? How well do the developers understand what the users are trying to do? Are there areas of tension or frustration between the two groups? Modernising the legacy system is going to require knowledge and involvement from both of them so it’s vital to get them talking to each other if they don’t already. One good way to do this is to set up workshops where developers and users talk through some of the current system’s pain points and discuss how they could be addressed.
Upskilling the Team
At the same time as discussing the current system with the development team, it is important to start thinking about the technologies you wish to use as part of the modernisation. The team may already have some strong ideas around this, but even if they don’t, asking for their thoughts will get them involved and help overcome any resistance to change.
Alongside this, giving the developers time to explore some options and making time for them to learn new skills is likely to enthuse them. One idea would be to ask people to develop some simple POCs to address various challenges. But remember, activities like this should be timeboxed rather than open-ended.
Navigating Resistance to Change
While getting the developers and users involved by asking them about the current system and how to modernise will help, it is likely there will still be reluctance from some.
Reasons for this can include a fear of how the changes might affect their roles, people being familiar and comfortable with how things are now, even if they are inefficient, past experiences of legacy system overhauls going wrong and poor communication about the reasons for the change and expected benefits. There may even be a feeling of implied criticism, especially if someone new comes in and starts asking why things were done in a certain way and starts talking about making improvements.
To overcome any resistance, it’s vital to involve people and explain why now is the time to modernise. Emphasising the value the current system has brought over time and talking about some of the opportunities that newer technology can bring will help avoid people feeling any implied criticism of what they have done in the past. Above all, clear communication about plans, timescales, and even some of the challenges will help prevent the feeling of having something done to you.
Integrating New and Existing Team Members
The chances are that new people will need to be brought in to help with modernising the current system. This may be a few new developers with skills in the technologies that are going to be used, or there may be an external consultancy that will bring in a team to implement the modernisation and will then go once it’s completed.
The combination of existing team members who may have been using older technologies for many years and new developers who don’t seem to have any respect for or knowledge of those older technologies can easily lead to resentment and mutual animosity.
Leaders should remind new team members to avoid any disparaging talk about what has gone before, while at the same time encouraging the existing team to take on board new ways of doing things.
Rather than leaving the existing team to maintain the legacy system while a new team builds something new, a much better option is to have both existing and new developers working together. New developers can benefit from the knowledge and experience of those who have worked on the current system, while at the same time supporting them as they skill up.
Conclusion
Modernising a legacy piece of software involves both technical and human-centred challenges. Developers will often focus on the technical hurdles, but leaders who don’t think about their team do so at their peril.
Developers who have been working on a system for a number of years may not be up on the latest technologies, but they have a wealth of knowledge about how that system works. Tapping into that knowledge while also giving them opportunities to upskill is an integral part of ensuring that any technical transformation is successful.
