Is Your Multi-Country Strategy Actually Built for the Markets It's Entering?

There is a version of multi-country programme delivery that looks impressive on a slide deck.

Six countries. Multiple partners. One team. Outcomes delivered on time.

What the slide deck does not show is the 11pm call when a local contact went silent 3 days before an event. The moment you realised that the accountability structure you designed for Lagos does not translate to Gaborone. The programme that nearly collapsed not because the strategy was wrong, but because someone assumed that a deadline means the same thing in every culture.

Through my work at BellaNaija, we have delivered programmes in Nigeria, Rwanda, Botswana, South Africa, Italy, and the United States, in partnership with organisations including Google, the NBA, the Italian Trade Agency, and Travel2SA. Often with the same team. Sometimes across multiple markets simultaneously.

I am writing this because most of what gets published about cross-market programme delivery is written from the outside, by consultants who advise on it, not operators who have had to make it work at midnight when something goes wrong in a city they have never visited.

Here is what I have actually learned.

1. The Assumption That Breaks Everything

Of all the assumptions that cause multi-country work to fail, the most dangerous is the one about accountability.

Specifically: the assumption that because you have agreed on a deliverable, you have agreed on what it means to be responsible for it.

Accountability is not a universal concept. It is culturally situated. In some contexts, accountability means that if something is your task, you own it end to end. You surface problems early, find solutions independently, and do not wait to be asked. In other contexts, accountability is more relational. It involves consultation, consensus, and a different rhythm of communication before action is taken.

Neither is wrong. Both are real. And when you build a programme structure that assumes one model and deploys it across markets that operate on the other, you do not get a breakdown in execution. You get a breakdown that looks like a people problem, when it is actually a design problem.

The solution is not to demand that everyone operate like your home market. The solution is to design accountability structures that are explicit enough to function across cultural contexts, and then over-communicate them.

What that looks like in practice:

• Written confirmation of every milestone, not just verbal agreement

• Check-in cadences scheduled before the programme begins, not improvised when things go quiet

• A clear escalation path that everyone knows, so that flagging a problem early is framed as professionalism, not failure

• A delivery lead in each market who has the authority to make real-time decisions without waiting for sign-off from Lagos

The programmes that have worked best across markets are the ones where no one was ever surprised by what was expected of them, because we said it out loud, wrote it down, and checked it before we assumed it was understood.

2. The Local Logic Layer

Every market has a logic. A set of unwritten rules about how things work, who matters, what signals trust, and what will quietly undermine your programme if you ignore it.

Most cross-market programme teams skip this layer entirely. They build the strategy, design the execution plan, assign the deliverables, and then deploy into a market as if it is a blank canvas. It is not.

When we worked with the Italian Trade Agency on a programme bringing Nigerian creatives and cultural figures to Italy, the local logic layer was not about logistics. It was about understanding what the programme needed to mean to both sides, to the Italian institutions facilitating it, and to the African participants from Nigeria, Ghana, South Africa, experiencing it, and designing every touchpoint around that meaning, not just the operational requirements.

When we delivered the Travel2SA programme in South Africa, the local logic layer was about understanding that a media programme landing in Johannesburg carries assumptions about Nigerian media, about what it is, who it is for, and whether it is credible, that needed to be actively managed, not ignored.

When we worked with Google across multiple markets, the local logic layer was about navigating the gap between a global brand's standardised programme framework and the very specific, very local communities that framework needed to reach. Global brands often build programmes for markets in the aggregate. The communities those programmes are meant to serve experience them as individuals.

The local logic layer is not a research exercise. It is a listening exercise. And it cannot be done in advance from a Lagos office.

This is why local partners are not a logistical convenience. They are a strategic asset. The best cross-market programmes I have run were the ones where the local partner was involved in the design, not just the delivery.

3. How to Structure a Team for Multi-Country Delivery

Here is the part that most articles on cross-market programme management skip: the actual mechanics of how you structure a team to deliver across multiple geographies without burning out or breaking down.

The first principle is role clarity over role flexibility. In mid-sized teams, the temptation is for everyone to do everything, which sounds efficient and feels collegial until you are 3 days from delivery in a market six time zones away and nobody is certain who is making the final call. In multi-country work, ambiguity about roles is not just inefficient. It is a risk.

Every programme needs one person who owns the outcome, not the tasks. That person is accountable for what gets delivered, not just what gets done. They are the decision-maker when things go wrong at 11pm.

The second principle is asynchronous by default, synchronous by exception. When you are running programmes across time zones, real-time communication is expensive in time, in energy, and in the cognitive load it places on a small team. The default should be asynchronous: written updates, shared documentation, clear status tracking. Reserve synchronous time for decisions that genuinely cannot be made any other way.

The third principle is what I call the pre-mortem conversation. Before every multi-country programme begins, I now run a structured conversation with the team about what could go wrong, specifically what has gone wrong before in similar programmes, and what we are going to do about it before it happens rather than after.

In the NBA programme to San Francisco, the pre-mortem conversation would have sharpened something we had to figure out in real time: that the All-Star Weekend context, built around major stars our audience had limited personal connection to, was not the most resonant entry point for a Nigerian community. We had to find the African angle inside a very American event. That meant leaning deliberately into the Basketball Africa League presence during the weekend, spotlighting the young African rising stars we identified on the ground, and anchoring our coverage around the BAL Gala Night rather than defaulting to the mainstream All-Star narrative. That pivot worked, but it worked because the team had the flexibility and the local instinct to make it. A pre-mortem conversation would have designed that angle in from the beginning rather than discovering it mid-programme.

A small team does not mean a team that does more with less. It means a team that is ruthlessly clear about what it will and will not do, and has the discipline to hold that line even when the pressure is to say yes to everything.

The fourth principle is post-programme documentation that is honest. Not a highlight reel. Not a lessons-learned report written to satisfy a reporting requirement. An honest account of what worked, what did not, what we would do differently, and what the next team to run a programme in this market needs to know.

4. What I Would Never Do Again

I would never again assume that a quiet partner is a functioning partner.

Silence in multi-country work is not neutral. It is information. And the interpretation of that information depends entirely on whether you have built the kind of relationship where problems surface early rather than late.

In one of our early cross-market programmes, a local partner went quiet in the final week of delivery. The assumption on our end was that things were on track, because if they were not, we would have heard. We heard four days before the programme date. The problem was solvable, but only barely.

What we changed after that experience: a standing check-in in the final two weeks of every programme, regardless of whether there are known issues. Not to manage the partner. To maintain the relationship, so that when something goes wrong, the instinct is to call us, not to manage it quietly until it becomes a crisis.

I would also never again underestimate the debrief.

The programmes that have improved the most over time are the ones with the most honest post-mortems. The ones that have repeated mistakes are the ones where the debrief was rushed, sanitised, or skipped entirely.

And I would never again treat local knowledge as a nice-to-have.

Every market I have worked in has surprised me in at least one way that a local partner could have predicted. The expertise of someone who knows a market deeply is not supplementary to a cross-market strategy. It is foundational to it.

The Through-Line

Multi-country programme delivery is not, at its core, a logistical challenge. It is a design challenge and a relational one.

The logistics can be planned.

The relationships have to be built.

The accountability structures have to be explicit.

The local logic layers have to be heard.

The team has to be structured for clarity, not just efficiency.

And the honest debrief has to happen, even when everyone is tired.

None of this is glamorous. None of it makes for a compelling slide deck. But it is the difference between a programme that delivers in six countries and a programme that delivers in six countries in a way that you could replicate, improve, and build on.

That is the standard I hold myself to. Not just: did it work? But: did it work in a way that makes the next one better?

Because in the end, the most valuable thing a team can build is not a single programme. It is the institutional knowledge to keep delivering, across markets, across cultures, and across whatever assumptions the next programme is carrying that nobody has checked yet.