Is your org chart stalling your new strategy?

Let’s say you've spent months creating a 3-year strategy. And then you look at your org chart, and realise it doesn’t fit the thing you just decided to do, so it’s time for some changes.

Below are a handful of things worth getting right before you edit your org chart:

Decide what you're optimising for.

Every org chart is a set of trade offs, whether you make them on purpose or not. The leader who says "we want a lean, high-quality, fast-moving, durable team" hasn't named a priority, and the new structure they design will end up making the decision for them, in some random direction, perhaps decided by whoever argued hardest in the last meeting.

So, when you can't have everything, what does your org structure prioritize?

I worked with a leader recently whose priority was cost. By that logic, almost every role in his new org chart should have been consolidated and shared.

But his strategy rested on the organisation's ability to learn from its own work and feed that information back into their activities. Cost logic said merge his learning & development capability into a shared pool, serving every team a little. But shared across everyone, this department answers to no one in particular, and becomes the kind of function whose findings arrive a month after they'd have mattered, and are generally ignored.

This was unacceptable because his strategy only worked if what the organisation learned in one cycle actually reshaped the next one. The priority was cost; the line he wouldn't cross was that learning loop. 

That's what naming the priority, and deferring it to your strategy, helps to do. Later, when two ways of structuring both look reasonable — and they often will — you'll choose the one that protects your priority, and you'll already know the one place you refuse to follow your own priority.

Audit the roles you have, but pretend the seats are empty.

Now look at your current structure. Every role, held up against the new strategy, lands in one of four buckets: keep it as is, reshape it, retire it, or it's missing.

Judge the role, not the person sitting in it. Conflating "do we need this role" with "is this person good" is how you end up keeping a role you don't need because you like someone. Separate the two questions, (and understand your legal requirements before actioning anything.)

Something to keep in mind: The team doing the work best understands how it runs, and they deserve a say in shaping what comes next. So bring them in as soon as your priority is established. Keep this time compressed. The longer people sit in uncertainty, the worse team morale becomes.

Group your teams around outcomes, not functions.

Once you know what work the strategy needs, you have to cluster it into teams. The default most organisations reach for is grouping by function. All the programme people here, all the comms people there, all the data people in their own corner. It's tidy, and it has a the following virtue: people who share a craft sharpen each other, and expertise deepens when it sits together.

But function grouping buys that depth at a cost. When everyone is organised by what they are rather than what they're for, no single team owns the result. The programme team runs the programme. The data team measures it. The comms team talks about it. And when the outcome the strategy is designed to achieve doesn't materialise, everyone can truthfully say they did their part.

When you group by outcome, each team owns one clear piece of the change you exist to create, end to end, with the mix of skills it needs to move it.

This isn't the only way, and it isn't always right. There are organisations that should group by something else, for example:

By place, when local context dominates every decision and a region has to be able to respond on its own; 

By programme or product, when each line is distinct enough to run as its own concern; 

By the issue or relationship you're trying to influence, which is often the truer shape for advocacy work where the win depends on forces outside your walls. 

The rule is that the right grouping follows the kind of work you do.

Cut duplicated overhead, but make sure it's truly duplicated.

Once you've built teams around what each one owns, you'll notice the same kind of role showing up in several of them. The instinct is to pull those together into one shared function so you're not paying for the same thing three times.

But watch out for where this goes wrong: Two roles can wear the same title and be completely different jobs underneath. 

Before you merge anything, run a simple test: could one person do both versions of this job, in a normal week, without needing a different skillset or a different set of relationships? If yes, then consolidate with confidence. If no, you've got two jobs sharing a name. Leave them apart.

And one thing to make your peace with: the moment you pull a capability out of a team and into a shared pool, you've created a “handoff”.

Work now has to cross a boundary to get done, and work leaks at boundaries. This means you have to be deliberate about who can expect what from the shared team, and who's accountable when it falls short. Consolidation trades a cost problem for a coordination one, and that’s fine, if you’re doing it with your eyes open.

None of this is the whole picture: Questions about who holds which decisions, how you size a manager's team, and the transition process, all need planning. But if you've just completed a strategy and you're staring at an org chart that doesn't fit it, this is where to start: