If you’ve ever tried to change a large organisation from the inside, you know this: complexity doesn’t kill transformation. Confusion does.
I’ve seen programmes stall not because the strategy was flawed or the technology was wrong, but because nobody could quite agree on what we were actually solving for. Everyone was busy. The decks were polished. The governance was humming. But when you asked five people what the mission was, you got five different answers.
That’s not alignment. That’s organisational white noise.
Over the years, I’ve come to believe that success doesn’t start with execution. It starts with clarity—not the kind that lives in a PowerPoint slide, but the kind that breathes in your team meetings, lives in your daily decisions, and shows up in how people speak about their work.
Without it, your project will burn resources. With it, you build something that works—and lasts.
The trap: mistaking activity for progress
At Barclays Africa, we faced what many called an “onboarding problem.” Customers were bouncing between departments, asked to provide the same documents again and again, and ultimately stuck in a broken experience. The cry was: “We need automation. We need dashboards. We need better tech.”
But when I dug into it, it became clear: we didn’t have a tech problem. We had a data model problem.
Each department had its own definition of a customer. Each system had its own processes. From the customer’s point of view, they were dealing with one bank. But behind the scenes, they were five different people, in five systems, with five inconsistent journeys.
What we needed wasn’t more automation inside those silos. We needed to redesign—and ultimately disrupt—the system entirely. And that started with clarity: clarity on the customer we were serving, the data we were capturing, and the experience we wanted to deliver.
Five truths I’ve learned about clarity
These aren’t theoretical. They’re hard-won lessons from real programmes with real people—programmes that scaled, stuck, and succeeded because clarity was built in from the beginning.
1. Start with the real problem—not the request
It’s easy to respond to what leaders ask for. “We need an app.” “We need automation.” “We need a dashboard.” But that’s just the symptom. The real problem is often hidden upstream.
I’ve made it a rule to never quote a budget, scope, or timeline until I know what we’re actually solving for. Is this a two-bedroom apartment, a three-bedroom house, or a 10-storey apartment block? Until we know what we’re building, any estimate is fiction.
In one programme, I was asked to provide a budget for a full-service digital platform. But I paused. “What exactly are we building?” I asked. Front-end apps, yes—but also integrations, data analytics, a transaction engine. So I created a conceptual design—an architectural sketch of every key component aligned to the outcome. Only then could I price it, phase it, and structure it with integrity. If you define the outcome too late, you build the wrong thing very efficiently.
2. Design the outcome before the roadmap
One of the most pivotal moments in my early career came when, in a kickoff workshop, I proudly gathered 10–12 strategic goals. My mentor smiled and said: “You now have to deliver all of them.” Lesson learnt.
Now, I always push for one goal. One mission. One core “why.” You can’t steer a ship toward twelve lighthouses. You need a North Star.
In our programmes, we articulate the outcome first. Then we design the map backwards. We even use visuals—artist’s impressions before architectural drawings—to make the abstract tangible. We move from vision to design, to delivery. And it works. Because once everyone can see the same future, the energy begins to align.
3. Translate strategy into human terms
Strategy that stays in the boardroom is just wallpaper. To make it real, you have to help every person connect their role to the goal. That’s how you build belief.
Across many programmes—including at Barclays, Absa, and Old Mutual—I’ve made it standard practice for each workstream lead to create a “strategy and approach” document. Not just a plan, but a story. “Here’s what our workstream is doing. Here’s how it aligns to the mission. Here’s how success looks.” These documents get shared, discussed, refined—and they become anchors that help people make sense of the broader picture.
We also created spaces for direct, unfiltered dialogue. At Old Mutual, we had “Weekly Wednesdays”—a live Q&A session open to the entire programme team. Every week for over three years. Anyone could ask me anything. Why are we doing this? How does my piece fit? What does this mean for the business? It made the strategy human. It gave people access to the big picture—and to the person accountable for it.
4. Establish a shared language—and repeat it until it sticks
In the early days of the Finance Transformation Programme (FTP) at Old Mutual, I saw emails flying around with “FTP” in the subject line. My tech brain defaulted to “File Transfer Protocol.” It wasn’t. It was the programme acronym. Cue the awkward conversation. But it reminded me: even smart people can talk past each other without shared definitions.
Words like “done,” “data-driven,” and “customer-centric” mean different things to different teams. I had developers tell me, “It’s done”—but it hadn’t been tested, deployed, or used. So we made “definition of done” explicit. “Done” meant in production, used by the business, and delivering value. Anything short of that was just activity.
Language matters. And culture is shaped by repeated language. We used vision banners, team rituals, even playful storytelling to reinforce the message. I often used phrases like “points on the board”—a rugby metaphor to explain delivery. You can pass, scrum, and tackle all day. But unless you score, you haven’t won. That metaphor stuck. It became part of how we spoke about progress.
5. Clarity allows complexity to scale
The more complex the programme, the more essential clarity becomes. When we ran the pan-African Finance & Data Transformation at Old Mutual—across 12 countries, 100+ entities, and multiple time zones—clarity wasn’t optional. It was the only thing holding it all together.
We built a culture of clarity. Clear roles. Clear language. Clear goals. We clarified outcomes, but we also clarified purpose. People need to understand why what they do matters. What’s the real benefit? How does it help the customer? How does it help the business? We didn’t just design systems—we designed purpose. And that’s what kept people engaged.
When people understand the purpose, it becomes their purpose. They don’t just comply. They commit.
Points on the board
Not everything that moves is progress. Not every deployed feature creates value. The real question is: What’s going to put points on the board for the business—and for the customer?
If your team spends six months building something that never gets adopted, you’ve missed the point. If your customer service agent still takes 30 minutes to answer a call, despite your shiny new CRM, you’ve missed the point. Transformation isn’t about activity—it’s about impact.
And clarity is how you define impact in advance.
Final reflection
If I had to give one piece of advice to any board, CEO, or transformation sponsor, it would be this:
Make the mission visible. Make the goal undeniable. Then make the path inevitable.
Don’t confuse complexity with progress. Complexity can be managed—but only if clarity comes first.