Org restructuring is for the agentic age

It used to be something you did every few years.

A big reorg. A reset. New lines on a chart, a few months of disruption, then back to normal. You’d live with the outcome for a while, even if it wasn’t perfect, because the cost of changing it again was just too high.

That rhythm is breaking down.

AI is changing how work gets done, and it’s happening quickly enough that teams don’t really get the luxury of settling anymore. What worked six months ago can feel inefficient today. Roles are shifting. Team sizes are changing. The ratio between different disciplines is moving around in ways that weren’t really on the table before.

You can see it in engineering first.

Smaller teams getting more done. Individual contributors producing at a higher level. Work that used to take a few people now being handled by one person with the right tooling. And on top of that, you’ve got agents starting to take on pieces of the workload in a way that’s only going to accelerate.

That has knock-on effects everywhere.

• How many engineers do you actually need on a team?
• Do you still structure around functions, or around outcomes?
• What does a “balanced” team even look like now?
• Where do you invest, and where do you reduce?

These are the kinds of questions that end up on your desk when you’re trying to figure out what the team should actually look like next.

Because while the pace of change has picked up, the way we design organisations hasn’t really caught up. Most companies are still trying to answer these questions using fragmented data and static tools.

• Your HRIS has the org chart.
• Your delivery tools have some sense of output.
• Your finance systems know about cost.
• Your AI tools have their own view of usage and productivity.

None of it really sits together.

So when it comes time to make a change, you’re stitching together a picture from different places. A bit of headcount data here, some delivery metrics there, a sense of how teams are performing based on instinct and conversation.

You can get to something reasonable that way, but it’s hard to feel confident you’ve actually got it right.

And when you’re dealing with questions like:

• can we reduce cost here without hurting output?
• should we redistribute people across teams?
• are we underutilising the productivity gains from AI?
• what happens if we lean further into agents?

…“reasonable” starts to feel a bit risky.

There’s also a tension that keeps coming up.

On one side, there’s the opportunity. AI is clearly driving productivity gains. Teams can do more with less. There’s a chance to simplify, to move faster, to cut out inefficiencies that have built up over time.

On the other side, there’s the risk of going too far. Cutting too deep, breaking team cohesion, losing context, or ending up with structures that look efficient on paper but don’t hold up in practice.

Striking the right balance between reducing cost and increasing output is not straightforward. It’s not a linear equation. And it’s very easy to overshoot.

So companies are finding themselves in a loop.

• Change the structure.
• See what happens.
• Adjust again a few months later.

It’s more continuous than it used to be, but it’s still quite reactive.

What’s missing is a safer way to explore these changes before they hit the real organisation.

If you had a clean, connected view of your organisation as it actually exists, you could start to treat it a bit differently. Instead of jumping straight from idea to execution, you could try things out.

• What happens if we reduce this team and spread the work differently?
• What if we group people by product instead of function?
• What if we assume a higher level of AI assistance and adjust roles accordingly?

You could model those changes, see how they affect cost, coverage, and structure, and compare a few different options side by side.

Not as a thought experiment, but as something grounded in your actual data.

That’s where AI starts to shift things again, but this time in your favour.

Instead of just accelerating the need for change, it can help you explore it. You can generate possible structures, surface trade-offs, and get a clearer view of what each option really looks like, while still keeping control over the final decision.

It doesn’t remove the difficulty. Org design is always going to involve judgement. There are human factors that no system can fully capture.

But it changes the way you approach the problem.

You move from reacting to changes after the fact, to exploring them ahead of time. From making one big bet, to comparing a set of options. From piecing together data, to working from a more complete picture.

In that sense, org design starts to look a bit more like something you can iterate on. Something you can test, refine, and then commit to, rather than something you have to get right in one go.

That shift feels inevitable given where things are heading.

There’s too much change, too quickly, for the old approach to hold.

The companies that get comfortable with this way of working will likely move faster and make better calls, simply because they’re not flying blind.

And quietly, a new category of tools is starting to emerge around this idea. Tools that treat your organisation as something you can model, explore, and optimise before you actually change it.

If you’re finding yourself back in another round of restructuring sooner than expected, you’re not alone. The pace has changed.

The way we design organisations is starting to change with it.

You can already see early versions of this emerging. Instead of working across disconnected systems and static artefacts, some teams are starting to pull their org data into a single model, layer in delivery and cost signals, and explore changes in a more structured way before acting.

It’s early, but the direction is clear.

Org design is becoming something you can actually model.