How leaders cultivate coherent change

If change is inevitable, how and what do leaders prioritize to deliver positive outcomes? If everything is a priority, then nothing is. Therefore, it’s incumbent upon leaders to understand and articulate how change relates to the business vision, how it impacts other areas positively or negatively, and how they are accountable for its success.

It’s an easy trap to consider building infrastructure and services over several years at an organization unique. But in my experience, there are many commonalities, particularly in the IT space. In my previous role as a network and security leader at the BBC, the challenge of shepherding change across a diverse organization and workforce stands out as learning worth sharing. Below are some of the strategies that have worked to help deliver on business goals, value, and improved user experience in a globally vaunted institution. 

Think of change coherently and combine technology change with cultural and operational transformation.

The BBC started life in 1922, has around 30,000 employees, 100 UK sites, and 170 international offices in some pretty far-flung places. Its technology stack mixes cutting-edge and in-house technical debt that spans diverse geographies to serve millions of customers. 

When I joined, it was apparent that to remain relevant and competitive it needed to pivot from bespoke, siloed solutions to repeatable, consumable, and scalable solutions that allowed me the opportunity to lead transformation in the network and security space. The BBC has embraced the public cloud and is one of AWS’s largest UK customers, but increasingly consumes multiple public cloud and SaaS services, an accelerating trend. Networks and security were critical enablers of these technologies but required foresight, context, and workflow modernization to deliver this foundation.

Technology change was only part of the evolution. I ensured that processes could support the new workflows that encompassed everything from commercial contracts to service assurance, security approvals, and operational support. Without this, the change couldn’t realize its full potential.

My long-term vision was largely static, while I regularly reviewed and updated near-term roadmaps to accommodate the pace of technology development and the business context surrounding them. This allowed me to re-qualify my assumptions and re-engage stakeholders and the wider business regularly.

Key lesson: Consider change holistically––understand how it affects business facets like workforce, customers, budgets, compliance, and existing programs. Most importantly, consider how it helps deliver the corporate strategy. If it doesn’t, then why are you doing it?

Empower leaders with information, clear reference to the business strategy, and communicate regularly to mitigate escalations.

I’d group users roughly into three categories: change embracers, change resistors, and change ignorers. As a leader, delivering successful change requires you to address all three. 

I’ve certainly been guilty of being myopic and assumed that everyone understands why a change is necessary as well as I do. Usually, this resulted from me focusing on the nuances and possibilities of the technology rather than what it improved for the users or the business. I quickly learned my lesson! 

Users today consume services, and our technologically-oriented society has shifted their expectations. They think IT should deliver the simplicity they enjoy on an iPhone, but that expectation is rarely reconciled with corporate IT and enterprise security. The gaps between operational efficiency, user experience, and security often explain why compromises are made. If the wider business hasn’t planned for change and you haven’t communicated it properly, it can be viewed as imposed rather than welcome improvement. Stakeholder or user revolt can quickly gather pace, whether valid or not.

Communicating detailed technical change and its motivation to non-technical audiences can at times feel like wasted effort but, in the long run, will save time and pain. Adapting messaging to different groups is an essential transformation leadership skill. If users can relate it to the business vision, it becomes relevant to them. As the figurehead, you should be visible and take more of the blame when things go wrong and less of the credit when the change is successful.

Key lesson: Create and execute a framework for communicating, controlling, and helping adapt to change for all your impacted stakeholders, from the board down to end users. And be accountable for your decisions.

Ensure your technology roadmap has realistic transition points between old and new capabilities and factor in the prerequisites and dependencies that could accelerate or cause delays.

Change can feel relentless. In certain situations, getting involved in a series of escalating battles isn’t good for the business or morale. Users become ground down by change fatigue, IT delivery teams become disillusioned at stalled progress, and executives spend valuable time resolving escalations and removing blockers. All these things destroy momentum and dilute value. The negative atmosphere can seep into the public discourse and affect a company’s bottom line - delays in removing technical debt mean missed opportunities to save money, or unpatched security holes can mean a breach that compromises data. 

Roadmaps can be a powerful and valuable way to demonstrate a direction of travel to a range of audiences. But they must be realistic with clear transition points. When I develop roadmaps, I include layers that make up the whole: a layer that concentrates on capabilities linked back to the business strategy, one that maps these to projects and technologies, one that can be shared with vendors, and, one that maps dependencies. These can combine to be relevant for different audiences. Regular review also allows you to reflect on your progress and changing priorities and adapt accordingly.

Key lesson: You won’t be the only leader delivering change, so understand interdependencies and communicate widely. A strategic transformation plan should be underpinned by a roadmap that can communicate and deliver value to a range of audiences. By providing value you ensure the business is more open to change.

Ensure delivery with a realistic scope of work: Can you deliver a minimum viable product and build on those foundations rather than try and attempt a perfect waterfall deployment?

Focus on your own projects and progress is understandable, so long as you realize that other leaders will do the same. Just identifying dependencies may not be enough if those dependencies aren’t addressed, which complicates transformation. In my experience, some business areas take a more pragmatic and tactical approach to transformation than I would personally. I’d argue that’s reactive fire-fighting rather than transformation, and it no doubt makes it harder to deliver your evolution. There can be other unforeseen developments as well - was there an emergency? Did we build something bespoke to meet a new opportunity? Is it shadow IT because central IT didn’t listen to business needs? Did a team not want to be encumbered by corporate security?

The pace of technology change compounds this. SaaS services, for example, have been a booming business trend. They provide the unquestionable benefits of removing technical debt, improved scalability, resilience, and better user experience. But the benefits of adopting cloud services come hand-in-hand with a loss of control of updates, altered security posture, architecture changes, and data residence. As businesses move more infrastructure into the cloud—PaaS, IaaS, DBaaS, and more—they need to be wary of security issues as compromises are made to ensure workflow and users can quickly get to where they need to go. Consuming services in the cloud also increases shadow IT since departments and individuals can buy services without centralized IT oversight. 

I delivered several cloud transformations at the BBC, notably of relevance here is the move to zero trust, which was my horizon strategy but was delivered through an iterative series of developments that included identity, segmentation, multi-cloud adoption, third-party access, and huge infrastructure reduction.

Key lesson: Establish a minimum viable product and iterate from there towards your strategy. Demonstrate the value of your successes to business initiatives and where there are dependencies, ensure communication and alignment so messages, benefits, and timelines are achieved in a coherent and demonstrable way.

Delivering the future

When I moved on from the BBC earlier this year, I left a legacy of successful transformation blueprints that were adopted across IT and can be continued into the future. The siloed approach to technology transformation was no longer viable. By approaching change in a holistic manner, I left platforms and processes that were mature and well understood by the business which in turn expanded their appreciation of the art-of-the-possible. 

What to read next 

“Saving Face” as a CISO: Let Zero Trust accelerate change

The secret behind a successful zero trust project is no secret at all; it’s the human element