Nimble organizations — those with technology at their core — have the advantage over enterprises hindered by legacy systems, organizations and mindsets.
As a senior leader, this is the time to be bold about what happens next. You need to reframe your perception of ‘legacy modernization’ and stop considering it in terms of ‘technology’ or ‘replacement’ rather, reimagine your future business.
We’ve been working together for 15 years, on the frontline of legacy modernization and transformation projects for FTSE 100 and government clients. In this series of articles, we want to share nine areas we’ve seen blindside execs along the transformation journey — and how successful leaders overcome them.
“The process of digital transformation can’t be done on a cost-cutting basis, it requires investment. It means being brave.” - Mark Thompson, ex- Chief Exec of the New York Times, extract from The Guardian 22/07/2020
Part One: Nine lessons from failure: Leadership
In this first article, we’re going to take a deep dive into some of the most important components of modernization — and where we’ve seen so many enterprises come unstuck: leadership and cultures.
1. Encourage accountability by being accountable
A key anti-pattern we observe is senior leadership recognizing their organization needs to change but assuming that they don’t need to change themselves. In other words, change is “over there”, not “over here”.
When we see this behavior play out, senior leaders become a blocker to their own program, while feeling frustration that change isn’t happening fast enough or sticking.
Where we see leadership truly engaged in a program — and by engaged we mean holding a mirror up to themselves to work out what they and their peers need to do in order to change — we witness far more successful, longer-lasting change programs; ones that produce greater business benefits.
How can you recognize when you’ve become a block to your own enterprise modernization program? Ask yourself these simple questions:
- What introspective activities have you done as a leadership team to understand the changes you need to make, to encourage the right values and culture?
- What are you doing to show your teams you’re embracing new ways of working? Are you reading/listening to the books, articles and podcasts that your teams are engaged with? Are you attending the same training programs as your teams?
- Are you creating an environment where it’s safe for teams to give good and bad news?
- Have you agreed on the right measures to encourage the change you’re working towards?
- Are you asking different questions of your teams to those you’ve asked in the past?
- For example, are you asking about outcomes — not simply progress — of a plan?
- Are you asking about the blockers they need removed (and removing them)?
- Are you focusing on the right questions and behavior? For example, if you’re asking for speed, do you understand the impact on quality? Or are you creating a ‘cottage industry of reporting’ within your program?
Fundamentally, all long-standing organizations, that have been successful in the past, develop a ‘legacy mindset’. That is to say, leaders and people with the organization throughout the ‘successful years’ can have weighted anchors: ‘what created goodness in the past is surely the best way for the future?’
These leaders may have teams, departments or indeed made their name in the past from an approach. They often want to hold on to these and unknowingly create suboptimal outcomes for the wider organisation. The most well-known example of this is of course where automation will impact teams who previously undertook manual tasks — the elimination of jobs or even whole teams is rarely an easy ‘sell’.
In practice, this friction to change develops not from technology constraints or lack of capabilities. It stems from people making self-assessments on “what does the change mean for my colleagues and me?”
A legacy mindset resistant to change is sometimes described as the “disagreeing nodding head” — there is the facade of wanting change (because it has been mandated by someone higher up) but the emotional buy-in hasn’t happened.
Only with sufficient buy-in, will required business change ever be successful.
‘Sufficient’ of course doesn’t mean everyone or even the majority but there are some important signals:
- Key influencers or net hindrance? Know the difference in your people
- Boardroom support. One courageous executive isn’t enough, you want senior leaders to be fully committed, personally invested and willing to change.
- Have you got enough support to help grow further support? i.e. 40% passionate about change will have a good chance of persuading a majority of the remaining 60%. This is more valuable than 80% lukewarm on change but “sort of supporting it”.
“The only constant in life is change” (Heraclitus)
This saying captures the essence of the challenge every organization faces with aging technology assets.
Today, even if requirements never change, your technology estate has to. You need to constantly patch, update and monitor for security exploits, bugs in software libraries and just the natural end of life of the many many components that go into building systems today. And the rate of change in software is relentless; the ‘half-life of software’ is rapidly coming down from decades to months.
And this is just for the best-case scenario, where requirements aren’t changing. Add in the complexities of a changing competitive landscape and evolving consumer behavior and needs, then the requirement not only for software but the entire organization to continually evolve becomes table stakes. One of the changes that organizations need to make is to move away from a project mindset to organizing teams around long-lived products (Products over projects - by Sriram Narayanan).
From an engineering perspective, there needs to be a focus on quality and automation, which are the building blocks for teams to be able to adopt the practice of continuous delivery with confidence.
Here are a couple of points you can ask yourself to ensure you are in the right journey mindset for the rebuild:
- Is your engineering program governed by an end date or a continual flow of requirements?
- Do you budget for “requirements to an end date” or production flow?
- Have you got a plan in place for continuous evolution?
- When you make changes to your system, is it modular for the area you want to change (i.e. flexible) or does that become a project of work in itself as so many other changes need to be made also?
- How responsive are your systems to your changing market needs?
- How do teams get feedback and what are the mechanisms for continuous improvement?