Your strategy looks excellent. Does your team know it exists?

It’s a common misconception that your IT department knows what your IT Strategy is, despite the number of times you feel you have shown it to them or discussed it in your townhall. Here’s the typical story of its creation:
The IT leadership team sits in a room for days on end with a whiteboard and post-it notes and produces something with pillars, priorities and a polished picture of the future. But look a little closer, and what you see is that much of it describes what everyone is already working on. The ambition feels safe and there’s very little that makes people curious about what comes next.
When it comes to the time to release the new strategy, it is decided that because the team is already ‘overwhelmed’, the launch will be low-key, it's called a refresh or an evolution, rather than a revolution. It’s announced in the townhall, a presentation goes out, perhaps followed by an email.
Somehow, the CIO then expects that strategy to be sitting on everyone’s desk, shaping every decision. A few weeks later, ask people what it says and many remember seeing it but very few remember the priorities. Meanwhile, existing work simply carries on. The loudest stakeholder gets attention; an operational incident changes the plan and whoever controls the budget has the final word. The strategy still looks excellent.
The issue started before the launch
By the time we notice that people haven’t connected with the strategy, we’ve often missed the earlier problem. It was created by the IT leadership team, sometimes by the CIO alone. Managers and frontline colleagues had little opportunity to contribute and the people closest to business demand, operational constraints and delivery were barely involved. So, we’ve made assumptions about what the business needs, what our people can achieve and how much capacity they have and then we hand them the finished document.
For someone already struggling with their workload, that can feel like another set of expectations arriving from above. They don’t recognise their contribution because ultimately, they didn’t get to make one.
There’s usually another empty chair
Our external partners. The strategy assumes suppliers, managed service providers and other partners will contribute. Yet we haven’t asked what they could bring, whether they can meet the deadlines or what they need from us. They might already have a capability we’re planning to build, or they might offer a faster route or even, they might have a dependency that makes our timeline impossible. We’ll discover that eventually but I’d rather discover it while we can still change the plan.
Putting this into practice:
Start with an ambition worth working towards. Describe what will be meaningfully better for the business, its customers and your people. Clearly connect the IT strategy to the business strategy and ask, “What should IT enable in three years that it cannot enable today?” Give the leadership team something to build towards beyond a catalogue of current projects.
Build the strategy with the people who understand the work. Bring in managers, frontline colleagues, IT business partners and business representatives. Use benchmarks and evidence to challenge assumptions about where you are today and what is possible. Be clear about where people can influence the direction, and show them what changed because of their contribution.
Invite your ecosystem into the planning. Ask relevant partners what they can contribute, what additional value they see and what they can realistically commit to. They may already have a capability you need or experience that changes your approach. Agree responsibilities, dependencies and timelines together before assuming their contribution in the strategy.
Make the capacity decisions before making the promises. Put proposed work alongside existing commitments and operational demand. What stops? What slows down? Where do you need different skills or additional support, and where could a partner help? Take the difficult choices to executive leadership early, including what the business will need to defer. Saying no quickly is better than making commitments your organisation cannot deliver.
Connect the ambition to ownership and outcomes. Give each priority a visible owner, including owners beyond the IT leadership team. Set annual objectives and measurable results that teams can translate into their own contribution. Make clear how those outcomes will guide prioritisation, investment and resource allocation, so the strategy has a practical role in the decisions people make.
Develop the capability and culture your ambition needs. Look at what your people will need to learn, where capability is missing and how the working environment needs to change. Include development and culture alongside technology, with time and support for people to adapt. If the strategy depends on greater collaboration, confidence or different ways of working, explain how you will help people get there.
Describe the leadership behaviours that have to change. If leaders continue rewarding firefighting, accepting every request and protecting silos, those behaviours will govern the organisation. Agree what you expect leaders to do differently, including how they handle competing demands, support collective priorities and explain difficult decisions. The team needs to see the leadership acting consistently with the direction it has set.
Give the strategy a life after launch. Build a clear storyline and keep using it in town halls and relevant strategic, tactical and operational discussions. Review progress against agreed baselines, discuss the results and explain the trade-offs behind decisions. Keep the strategy live as business needs change, making clear what has changed and why, so people can continue to understand the direction and their part in it.
Before releasing it, I’d ask one final question: Can the people delivering this explain what we’re trying to achieve, why it matters, what they own and what we’ve agreed to stop?
The answer to that will tell you more than the quality of the slides.





Comments