Why Your Target Operating Model Shouldn't Start With an Org Chart

The first thing most leadership teams produce when asked to design a target operating model is an org chart. It's also the first mistake.

It's understandable. An org chart is tangible, fast to produce, and feels like progress. It gives the room something to react to. But drawing the org chart before you've understood what the work looks like once AI is embedded in it means making structural decisions on the current state, not the target one. You end up designing for a world the transformation is supposed to leave behind.

Why structure comes last

A target operating model answers five questions for each function in scope: who makes decisions and how, what data those decisions are based on, how teams are structured, how work flows end-to-end, and what technology the model requires. Notice where "how teams are structured" sits: third, after decisions and data, because you can't design the structure until you understand the work.

You don't know what the work looks like until you've mapped it

AI transformation doesn't just change how people do their work. In many cases it changes what the work is. A buying team that moves from executing against supplier recommendations to curating and overriding AI-generated assortments isn't the same buying team doing the same job faster. The role has changed, the skills required have changed, and the volume and nature of the decisions being overseen have changed.

Design the org chart before mapping those changes and you're drawing boxes around job titles that are about to shift substantially. The result looks organised on paper and doesn't reflect the operating reality. People get assigned to roles that weren't designed for the work they'll actually do.

I see this pattern consistently in transformation programmes struggling mid-flight: the org chart gets produced at the start, the rest of the design gets built around it, and eighteen months later the programme team is trying to force new processes into a structure drawn before anyone understood what those processes would require.

The org chart becomes the constraint rather than the enabler. Functions defend their boxes. Boundaries that made sense in the current state create friction in the target one. Reopening the structural conversation mid-programme, once people have been appointed and stakeholders have aligned to the chart, is exponentially harder than getting the sequence right from the start.

Org charts trigger the wrong conversation

Put an org chart in the room and you've created a political document. People start counting boxes. Span of control becomes a status signal. The conversation shifts from "what does this organisation need to be able to do?" to "where do I fit in this?" before the design is anywhere near mature enough to answer that.

The conversation you need at the start of a transformation programme is about capabilities, processes, and the future shape of the work. The conversation you get when you start with an org chart is about reporting lines and seniority. Having the wrong one first wastes weeks and generates heat the programme then has to manage for months.

What comes before the org chart

Four things need to happen before structure is on the table.

Capability mapping comes first: start with what the organisation needs to be able to do, not who will do it. In an AI-transformed operating model, capability questions look meaningfully different from current-state ones: does the business need AI oversight capability or AI execution capability, people who interpret AI signals and make override decisions, or people who configure and monitor AI systems? These point to different roles, and the capability conversation has to happen before the role conversation.

Process design comes next: once you have a capability picture, map how the work flows end-to-end. Where do AI systems generate outputs, where do people review them, where do people override them, and where does the decision actually get made, and by whom? Process design reveals the interdependencies between functions that the org chart will have to support. Structure that cuts across a process creates friction; structure that follows the process creates flow.

Workforce impact modelling follows: with capabilities and processes mapped, you can do the role-level design, which roles change substantially, which new roles emerge as AI capability matures, and which roles are no longer needed in their current form. This is uncomfortable work, and most leadership teams would rather skip to the org chart and handle the workforce dimension through communications. A transformation programme that hasn't designed the workforce transition is making decisions about people's working lives without acknowledging it. Design it explicitly, attach specific retraining pathways and redeployment commitments, and then communicate.

Transition state design comes last, before structure: how you get from current state to target state. It's rarely a single cutover. Most transformations move through two or three transition states before reaching the target operating model, and each has its own structural requirements, capability needs, and workforce design. The org chart should reflect the target state, but the programme needs to plan the transition states that come before it.

A pattern worth recognising

A retailer I worked with illustrates the cost of getting this sequence wrong. The leadership team produced an org chart in the first month of a transformation programme. It was well-constructed, logical, and widely shared. Senior appointments were made against it. The restructure was communicated to the organisation.

The process design work came six months later. By then, the design team understood that the transformation required a fundamentally different split of responsibilities between the commercial function and the data and analytics function. Two of the senior appointments made against the org chart were in the wrong roles for the operating model the programme was building. The process boundaries crossed structural boundaries in ways that created ongoing friction and needed exception handling that shouldn't have been necessary.

The programme spent six months forcing new processes into a structure that didn't fit. It worked, eventually, at the cost of time, political capital, and relationships that took two years to fully repair.

The org chart came first. Everything else had to work around it.

Design the work first

An org chart represents a set of design decisions. If those decisions haven't been made yet, the chart is fiction: plausible, well-intentioned, even politically necessary, but still a placeholder that the rest of the programme will spend months working around.

Design the capabilities first. Map the processes. Model the workforce impact. Plan the transition. Then draw the structure that supports all of it. The AI Transformation Playbook at transformationplaybook.ai has templates for each of these four steps if you want a structured way through them.

The org chart is the last design decision. Treat it that way.