Episode #6: Why your Why is everything
How a clear business purpose strengthens alignment, reduces resistance, and keeps your program credible when pressure rises
Why Every Tech Program Needs a Clear Business Why
Most tech programs excel at defining the “what” and the “how” of their program – but stumble on the why. And when the why is weak, every stakeholder interaction becomes harder, every challenge becomes noisier, and user adoption post go-live becomes a gamble. A clear business why is not esoteric. It is one of the most impactful levers an IT leader has to reduce resistance, protect program credibility, and sustain momentum in long, complex transformations.
A missing or vague why is one of the most common root causes behind stalled adoption, stakeholder pushback, and declining program visibility in noisy workplaces. In long programs like SAP S/4HANA, or platform modernisations, the why is the anchor that keeps leaders, teams, and end-users aligned when the pressure rises. This blog outlines why the “why” matters, how it works, and what goes wrong without it – plus practical guidance to define one that holds up under real-world conditions.
Most CIOs and program leads recognise this pattern: the technology plan is precise, well-structured, and detailed.
The business case is validated. The roadmap is refined across workstreams. Yet the one element that should unify all of it – the reason the organisation is making this change now – is underdeveloped or missing. Teams rush into delivery mode before establishing a clear business why, assuming the logic “should be obvious.” But it rarely is. And without it, even the strongest technical delivery struggles to land.
The why matters because technology change is never just technical. It introduces new behaviours, new expectations, new ways of working.
When people understand the purpose behind a change, they stay engaged when complexity peaks. When they don’t, resistance grows quietly, trust erodes, and the program becomes one more initiative lost in organisational noise.
Meaning shapes motivation. That’s the behavioural science perspective. Humans don’t adopt new tools simply because the tools exist. They adopt when the change makes sense – rationally and emotionally. Programs that communicate only the technical rationale (“support is ending,” “the legacy system is outdated”) miss the motivational layer needed to sustain momentum. Programs that articulate a grounded business why – “we need cleaner data to make faster decisions,” “we need comparable processes across regions to scale” – create direction, alignment, and resilience.
When the why is missing, the consequences show up early and repeatedly.
Stakeholders give minimal attention. Business leaders deprioritise decisions. Program teams experience more friction from functions and regions. Communications land without impact. Training uptake becomes uneven and slow. And when the first real challenge appears – usually around Fit/Gap, UAT or later during Data migration – criticism escalates quickly because the program lacks a unifying narrative that earns goodwill.
With a clear why, the opposite happens. Stakeholders recognise why the work matters and stay committed even when conditions are difficult. Teams focus not only on delivery but on outcomes. Leaders support decisions because they understand the strategic direction. And when delays or setbacks occur, the likelihood that stakeholders remain constructive instead of adversarial increases substantially. The why acts as a stabiliser – a practical tool that protects credibility and keeps people aligned.
To define a strong why, IT leaders need to avoid two extremes. Not just facts and logic. And not emotional slogans detached from reality. A credible why sits at the intersection of both: clear business rationale, paired with meaningful benefit. It should answer three questions: Why are we doing this as an organisation? Why now? What happens if we do nothing? The answers must be specific, relevant, and grounded in the organisation’s actual context—not aspirational marketing language.
Common mistakes weaken the why quickly. The first is relying on technical jargon instead of business benefits. The second is trying to define the why too late, once stakeholders already feel disconnected. Another is presenting the why once in a kick-off and never reinforcing it. But the most damaging mistake? Crafting a why that only makes sense to headquarters. If the narrative serves corporate priorities but ignores the realities of local teams, it generates scepticism and early resistance. Every stakeholder group must be able to see themselves in the why.
Once defined, the why must become the thread that runs through the entire program. It should show up in communications, steering updates, training materials, and leadership messaging – not as a slogan, but as a reference point for decisions. When used consistently, the why provides cohesion across functions and geographies. It becomes the lens through which people understand prioritisation and trade-offs.
Testing the why is essential. Read it aloud. Share it informally. Ask a local leader what they think it means for their team. Ask a colleague outside the program whether it’s clear. If people hesitate or struggle to explain it back to you, more work is needed. A strong why must be understandable in two sentences – not fifty PPT slides. And it should feel relevant to both senior leadership and frontline teams. If it only works for one audience, it will not sustain alignment across a multi-year program.
The why also needs proof. Early wins and signature stories from all impacted functions – especially during hypercare – help translate purpose into tangible outcomes. When teams experience improvements – faster reporting, fewer manual steps, reduced rework – they begin to associate the program with progress rather than disruption. These stories make the why real, especially for stakeholders who are initially sceptical. They reinforce that the program is not only a technical upgrade but a strategic shift with measurable benefits.
Ultimately, the goal of a clear business why is not inspiration. It is risk reduction.
Tech programs with a strong why encounter fewer “noise” surprises (and hence less comm-firefighting), fewer pockets of resistance, and fewer credibility challenges. They maintain stakeholder support through difficult phases and transition more smoothly into business-as-usual. They protect the investment, the leadership reputation behind it, and the adoption outcomes that determine whether the system becomes value-generating or shelfware.
Key Takeaways (What IT Leaders Should Remember)
Adoption depends on meaning; the why creates the motivation to change.
Without a clear why, stakeholder trust and commitment decline quickly.
A grounded business why protects credibility when challenges surface.
Programs must reinforce the why consistently – not only at kickoff.
Every stakeholder group must see themselves in the why.
About your host
Arne Kötting founded COSYN after years of seeing organisations struggle with the human side of tech change. He built the Change Playbook to codify what actually works based on 20 years of watching these patterns.
The Change Playbook is designed for IT program teams to confidently manage the human side of tech change in-house, without expensive consulting dependencies.
His conversational style cuts through complexity to reveal the fundamental principles that make tech change communication work - principles you can apply 1:1 to your own transformation challenges.
Get in touch
More podcast episodes from
a Change in Conversation
