Data and AI Transformation: Change in Leadership
When joining Teams, the microphone is automatically muted in meetings with more than a specific number of participants. Do you find it frustrating, or is it the right feature?
I was working on a large transformation programme in 2010-11. We were a tightly knit group of 60-70 architects and transformation specialists in a secure room with restricted access. We were planning and implementing one of the National Health Service’s largest data transformation programmes. A new gentleman, Gavin Mander, entered the room and began sitting in one of the large spaces where we used to sit. After a few weeks, the gentleman could still be seen sitting in that corner daily, but he was now frequently seen talking to our Program Director, Chris Leary. A change in leadership was soon announced, and we were all made aware of the transition period for the two leaders’ handshake.
The leadership team that helped deliver Secondary Uses Service (SUS) for National Health Service. My apologies I was unable to recollect all the names.
Seated on the floor (from left) – Jane Rollings (#2), Jasbir Singh Riyard (last)
Seated on Chair (from left) – Jason Perkins (#1), Mike Thomson (#3), James Ormrod (#4), Gavin Mander (#6), Naren Kamat (#7), Amol Kapote(#8), Adrian Rogers (#10), Mark Carr (#11).
First Standing (from left) – Suhail Kazi(#03), Bhavin Shukla (#05), Roy Taylor (#07), Deepak Thakurdesai (#08), Peter Flynn (#10), Kashif Ahmed (#11), Ketul Savla (#13)
Standing Back (from left): Emma Ross (#09), Chandan Kumar (#10), Henry Walker (#11), Tim Black (#12)
We used to have all-hands meetings, but they were still presided over by our current leader, not the upcoming leader, the gentleman in the corner. We didn’t hear anything about the new leader’s thought process or new ideas; it was business as usual for us.
At the time, my attention was directed toward the more technical aspects of building, and as a result, I failed to recognise the significance of this nuanced but essential lesson. The modifications, the new ideas, and the obvious shift in leadership all took place later, but the transition was smooth, and there was no obvious sign of disruption caused by it.
After a decade, when I joined BT as Principal Enterprise Architect for Data Analytics, I could fully appreciate both leaders’ greatness. After working on and leading numerous transformation programmes, I assumed the role at BT would be no different. I only realised the full scope and complexity of the role after a couple of months. I was fortunate to have Jason Perkins in the organisation as my mentor, who encouraged me not to form or voice early opinions about the current estate and environment and to keep an open mind about the actual cause of the pain points and possible solutions. I was lucky to have such guidance, which helped me lay down the strategy and enterprise architecture that was niche, upcoming and recognised within the industry but was tailor-made for BT. This would not have been possible if I only went forward along with the tools I had in my armour and if I had built early opinion of the challenges and related causes.
This is one of the lessons I have learnt while going through the journey that the MUTE button should be set to default ON for a certain duration while joining a large organisation. For a good result, we should spend more time first listening, building relationships and getting to know people and processes. This will help us develop a strategy and plan that isn’t influenced by our past experiences and looks to the future.
In Data and AI Space, there are several ways to start out as a leader in a new organisation. Even though my thoughts might be true in other areas, my expertise and most of my experience have been in the Data Ecosystem. Here are a few important ones to consider when you join an organisation as a data leader, but this may not be the whole list.
📜Following the Scroll
The incoming leadership believes in the target state specified by the predecessor and comprehends the advantages of achieving it entirely. It is more about enforcing the established concept, which has been difficult and slow to implement. The strategy focuses on adhering to the specified guidelines and enhancing the capability to implement the identified change. This occurs when the organisation is aware of what “good” looks like, and the necessary repairs, but some key individuals or departments within the organisation have not accepted the change. The focus of this change can be limited to those who are resisting it because of their emotional attachment to legacy or because of their own definition of the end state, or to those areas of the organisation that believe the new world will lead to their existential crisis, or to the larger community that does not understand the strategy and direction because the strategy has not been socialised and clearly communicated.
🚦 Turning it Red
Highlight to the leadership that the current state of affairs is unmanageable and the strategy or implementation is either failing or will eventually fail. Changing the current status to RED is one method for managing change. Numerous advantages may accrue from this approach, such as enhanced focus and prioritisation, additional financing for rectification, additional energy to accelerate, cause disruption, and pivot if necessary, etc. This approach has the trade-off of calling into question the abilities and efforts of current and past teams and a baselined strategy. It can lead to uncertainty over the overall strategy, increase the delivery duration, encourage a blaming culture within and across different departments, and leaves a demotivated team.
🎯 Defining the Target State
It is understood that the target state has not been defined, and the incoming leadership has been given the job of defining the strategy, describing the end state, and getting buy-in from stakeholders so that this doesn’t come as a surprise when money is needed. This state is helpful because it lets you start over and understand the organization’s long-term goals. It will need a business case and a clear analysis of the costs and benefits. This kind of reform may take a long time to implement because there isn’t enough funding, and everyone doesn’t agree on what “good” means. It’s a marathon, and the team might lose steam. Also, not all the departments in the organisation would be at the same level of maturity, which could slow everyone down during implementation.
🚧 Removing Roadblocks
This is more of joining when the organisation is in a state of frustration. The change and the work that needs to be done are well understood, the stakeholders have come to an agreement, and the money is there to make the change happen. But the timelines for making this change are unrealistic, causing chaos and frustration in the organisation. The incoming leadership is expected to understand the roadblocks or processes that might slow down the change and educate the senior leadership with realistic timelines or develop alternatives that can speed up the critical processes that are working as the longest pole. This can be fixed by making small changes to the process or adding more resources to speed up the change.
❄️ Resolving Dependencies
This is when one enters an organisation when multiple transformations are taking place at the same time. The transformations of data and analytics are very complicated because they depend on other parts of the architecture, such as Business Architecture, Application Architecture, and Technology Architecture. The data and analytics transformations can’t be seen or done in isolation because other moving parts can cause major rework and might require retrofitting down the road. This can mean that the business case benefits won’t be realised. So, instead of implementing the data and analytics strategy from the Enterprise Architecture blueprint and technology strategy in small pieces, like “Data Analytics modernization,” “Building Data Hub,” and “Enterprise Data Quality as a service,” it is important to first enable the Data Infrastructure and then overlay with end-to-end use cases. The maturity of the architectural building blocks needs to be improved, and the components should be enriched each time. This way, the dependencies and changes across all four pillars of the architecture can be managed and monitored.
One single approach from the list above may not work, and it will require a combination of the above and/or introducing the ones not listed here. But one thing is common to any of these, current understanding and history are required to define the approach to reach the end state.
Joining an organisation is a time of change for both the person and the organisation or team, which takes time. Organisations that bring people in key leadership role need to ensure that the right handoff and handshake happens. This means giving the new leader the original problem statement, the direction taken, and the challenges seen. It is also the job of the incoming leadership to not jump to conclusions about the problems and refrain from providing immediate solutions. False memories and bad experiences from the past, which I have discussed in the seven layers of existence, could change the fate of the organisation. Below are a few take-home points:
- Not all IT problems have to do with technology or are technically based.
- History and the people who know how things got to be the way they are and how we reached so far are important to understanding the root cause. Layoffs, redundancy, resignations and change can be done relatively easily within the engineering team but not in the strategy and enterprise architecture function, as it is not just a technical aspect but also about trust and relationships established with the stakeholders. Do not let the people who have lived through and understand the current strategy and problem statement walk out the door; they could be a gold mine for you.
- The organisation should facilitate knowledge transfer and appropriate handover.
- Having an open mind when one joins can help the person look at the problem as a whole and makes it less likely to form biases. Scars and experiences from the past are important, but they might not be useful or helpful in the new place. Don’t forget that one moved to a new job because the person wasn’t happy with the old organisation or ways of working in some way, i.e. it wasn’t all roses there. Individuals should not rush to prove themselves in the initial stage of joining the organisation.
Enterprise architecture is about looking at the big picture, researching, and connecting the dots. Building relationships with various individuals and teams is required. The single global currency of relationship and ally-building is “trust.” A certain level of aggression is required to push the strategy through, not as an imposition, but through the element of trust and only by explaining the rationale. Trust takes time to build, so settling in and spending time within the organisation is important before making major decisions and making your opinions known. The Mute Point!
If you’ve made it this far, I strongly recommend you to watch a 5-minute video by Simon Sinek in which he explains why leadership is about consistency rather than intensity and why trust is more important than performance, especially in this role.