Top 5 symptoms to watch for if Your Enterprise System/Product is Entering a State of Legacy

Summary

Read More..

---

Reading Time: 4 minutes

Dealing with legacy systems is never a leader’s preferred choice. At the same time, driving software systems into a dreaded state of legacy is also never a leader’s preference. Systems gravitate towards legacy for a variety of reasons, ranging from organizational priorities to strategic misalignments to technological advancements. 

One of the strongest aspects of these gravitational forces is organizational culture. In our experience of re-stabilizing and re-architecting legacy systems, we have observed specific cultural traits that help explain when and why systems head towards the dreaded legacy state. To determine the susceptibility of your own organization, here are five symptoms that serve as an early warning indicator that a product or system is entering into the dreaded legacy state. 

Fear of the Unknown 

There is a healthy level of fear and risk mitigation that every organization should have. But often, people tend to lean too much into their fear as opposed to faith and determination. You may hear phrases like, “We can’t implement this feature because it interacts with components that the previous team built” or “We need more time to validate if this change breaks other features.” These are understandable as regression libraries tend to increase build after build. And as a system becomes more complex, the risk of breaking something also increases over time. But instead of introducing new tools and processes to reduce these risks, the cultural tendency is toward smaller releases and the status quo. 

A Culture of Hero Worship 

Whether it’s tenure or expertise or ego, every organization tends to have its heroes. For example, you may hear phrases such as “only so-and-so truly knows the system” or “it’s best that s/he makes these changes or else something will break.” While organizational heroes are prevalent, a culture of hero worship has its side effects on the way systems evolve. Over time, this culture breeds a self-fulfilling prophecy where the very heroes who contributed to the legacy problem become the only people who can save the system. As much as we love heroes, organizations should create a culture of decentralization and a meritocracy for anyone to become a hero. 

Sunk Cost Fallacy  

Systems do not become legacy overnight, but rather over a period of time. And if you carefully observe the rate of legacy evolution, it tends to accelerate at a certain point. This tipping point is where the team collectively begins to have sunk cost thinking. Instead of taking a step back to evaluate the current system with respect to the product roadmap, the attention shifts to maintaining stability without disrupting the status quo. You would hear conversations like “We have invested so much into this, let’s keep this going!” or. “We have already taken this decision and we have to stick to it” or “There has been a lot of effort put into this, we should use it”. And while this sunk cost fallacy may be correlated with time, we have seen this happen to systems that are only six to 12 months old. 

Product Vs Project Mindset 

The difference between a product and project mindset greatly impacts a system’s susceptibility to becoming a legacy. With a project mindset, there is an overly simplistic approach to implementing features as quickly as possible. Team members may even march to the tune of being agile as their mantra of speed over substance. With a product mindset, the team is meticulous about understanding new feature requests and then building a proper product roadmap. Furthermore, the team brings in multiple stakeholders in the development process to ensure functional, operational, and technical excellence is achieved. Although it is more time-consuming to espouse a product mindset, the strategies employed will greatly reduce the pace and possibly the path towards legacy. 

Unclear Accountability 

Legacy systems don’t happen overnight. Just as it takes many choices to build the overarching organizational culture, the present is often anchored on past decisions – both good and bad. But a key problem arises when there is a lack of accountability for past mistakes. You may hear newer employees say things like “we inherited this problem” or “we’re doing this because the previous team did this too”. When there is no cultural incentive to address problems regardless of when they started to occur, past problems only become exacerbated over time. 

How Do We Address These Symptoms? 

As software leaders, these legacy symptoms are all too familiar and may even keep you up at night. More often than not, we point the blame on a handful of people, thinking that replacing them with “the right people” will solve the problem. However, we’ve seen that story play out as well, where the endless cycle of hiring and firing has not produced the desired outcome over the long term. Taking a step back to address these common legacy indicators, we begin to realize that organizational culture may indeed have a profound impact on whether a system prematurely heads towards legacy. This doesn’t mean that hiring the right people is not important. Instead, the overall team and individuals must espouse the right culture that is instilled by the leadership and management teams.  

In our upcoming posts, we will unpack some of these cultural issues and provide recommendations on resolving them. Until then, we invite you to share your knowledge and experience, the good and the bad. For example, which clues have you seen that indicate a system is heading towards a legacy state? And what steps have you taken to resolve these conflicts?