What a target operating model is, and how to design one.

A target operating model is the design of how an organisation will work once a change has landed: the structure it runs in, the roles people hold, the decisions each of those roles can take without asking, the governance that holds it together, and the route work takes from idea to production. The load-bearing word is target. It describes the organisation you are moving to rather than the one you have, which is what separates it from an operating model review, and it is a design document rather than a strategy. Where a strategy says where you are going and why, a target operating model says what the organisation has to look like when you arrive.

An operating model describes how an organisation works now. A target operating model describes how it will work once a planned change has landed. The distinction matters in practice because the two are produced differently, the current model established by observation, including the parts nobody documented, and the target model designed against outcomes. Most failed exercises are a current-state map with ambitions written in the margins, which is why they change nothing.

Eight things: structure, roles and accountabilities, decision rights, governance and assurance, ways of working, value and measurement, capabilities and skills, and the technology and data the model depends on. Decision rights are the section most often left vague and the one that determines whether the model speeds the organisation up or slows it down, because a model where every non-obvious decision escalates by default is slower than the one it replaced.

Tenhaw does not publish a blank template and is sceptical of them, because a template returns the structure of an answer without the arguments, and the arguments are the work. What Tenhaw does publish is a complete worked example. The Tenhaw Way is a full operating model for product and delivery organisations, published free and adoptable without an engagement, with seventeen how-to guides underneath it covering the individual moves. A worked example you can disagree with is more useful than a form you can fill in.

For an organisation-level design with the architecture designed alongside it, two to four months is realistic, and Tenhaw prices that engagement at £35,000 to £55,000 a month for a pair of one operating-model lead and one agentic architect. Anything materially faster is either a smaller scope than an organisation, or a document rather than a design. The HSBC Global Payment Solutions model took six months to design, pilot and refine at 500-team scope.

The eight components stay. What changes is the content of three of them. Decision rights have to say which decisions move to agents and which stay human, and who is accountable when an agent gets one wrong. Governance has to specify how agent output is verified, evaluated and evidenced rather than reviewed by eye. Ways of working split, because AI-augmented teams and AI-native teams do not run the same process. Everything else is a standard target operating model, which is why a firm whose operating model credentials begin with AI is usually learning the discipline on your programme.

A named executive on the client side, and not the supplier who designed it. An operating model owned by a consultancy lasts exactly as long as the engagement, because the decisions it encodes need someone with the authority to defend them when the first exception arrives. Tenhaw writes the owner into the scope and hands the model over as an asset, which is the same reason its engagements are designed to end.

No, and starting there is usually a mistake. Run the pilots first. They are cheap, they tell you where agents actually pay in your organisation, and they produce the evidence a model needs to be designed against. The point to design a target operating model is when pilots have worked and stopped scaling, because that is the symptom of an operating model problem rather than a technology one. If nothing has been piloted yet, an AI Readiness Audit answers where to invest before anyone designs anything.

Each omission fails in its own predictable way, and the failure is usually blamed on something else. Skip structure and you have redrawn the org chart you already had, so nothing about how work flows changes. Leave decision rights vague and every non-obvious decision escalates by default, which makes the new model slower than the one it replaced until the organisation quietly reverts to the old one. Skip ways of working and the result is an organogram that tells nobody what to do on Monday. Skip value and measurement and there is nothing left to report but activity. The other reliable failure is designing the model and the technology to different assumptions, then finding the gap in build.

Six steps, and the order matters. Establish the current model honestly, through interviews and observation rather than a document review, because how decisions are actually taken rarely matches what is documented. Fix the outcomes the model has to deliver, priced where they can be priced and owned by a named person on the client side. Design structure, decision rights and governance together, since structure drawn first with rights added later gives you a model where the boxes are right and nobody can act. Design the architecture on a parallel track. Pilot it in one real area with the new decision rights genuinely in force. Then sequence the rollout and cost it, which is what a board approves against.

Accountabilities, and it is not a pedantic distinction. A role in an operating model is defined by what its holder is accountable for and, equally, what they are not. Job titles vary by region and by whatever the last reorganisation left behind, so a model written in titles means something slightly different in every country it lands in, while accountabilities stay comparable across all of them. Get this wrong and the result is the most common gap in the whole exercise, two functions each believing the other owns the same outcome. It surfaces at the first escalation rather than the first workshop, which is the expensive way round.

A named executive who will own the model after the engagement ends, and the people who actually take the decisions you are about to redesign. The owner matters most. Without one the model belongs to whoever wrote it and expires with the contract. Then you need whoever owns each outcome the model has to deliver, since those outcomes are what the design gets optimised against, your architecture people in the room while the model is being designed rather than reviewing it afterwards, and the leadership of the area you intend to pilot in, because they have to agree to run the new decision rights for real. Tenhaw brings two people to that, an operating-model lead and an agentic architect.

Often yes, and Tenhaw publishes the material you would need rather than holding it back. The Tenhaw Way is a full operating model, free to read and free to adopt, and it works as a worked example to argue with. Use the eight components as your checklist and the six-step sequence as your plan. Two parts are genuinely hard from inside. Establishing the current model honestly is one, because colleagues describe the process they are supposed to run rather than the one they run. The decision-rights argument is the other, since it cuts across functions no single person internally has the authority to settle. If those two are tractable in your business, run it yourself.

One real area, chosen for the consequences it carries rather than for how easy it will be. Three tests apply. It has to do work that matters, so that a decision going the wrong way is visible to someone. Its leadership has to accept the new decision rights genuinely in force rather than simulated. The old escalation path is exactly what absorbs the friction the design was meant to remove, so a pilot that quietly leaves it open tests nothing. And it has to run long enough for a properly contested decision to arrive. What that area teaches you is what the rollout sequence then gets built on.

By writing down what each body is allowed to decide, not just what it will be shown. Governance and assurance is one of the eight components a model has to specify, and the version that fails is the one defined as a meeting with an attendee list, where status is presented, nothing is decided, and the gates exist on paper only. A working design names the bodies, the decisions each one can take, the evidence each sees and the gates work has to pass. The authority most models leave implicit is who can stop something, and a body that cannot stop anything is a reporting meeting with a better name.

They are the rules about who can decide what: which decisions a role takes without asking, which need a second signature, and which go to a governance body. Of the eight components this is the one argued over hardest, and the argument is the work. Agreeing that a named role can settle something today's process sends to a committee is a real transfer of authority rather than a documentation exercise, which is why it has to be designed alongside structure rather than bolted on once the boxes are drawn. Leave it comfortable and vague and nothing changes on Monday, because everyone carries on asking whoever they asked before.

A target operating model engagement ends in a design and a sequenced plan for rolling it out, not a strategy deck. Concretely that is the eight components answered for your organisation rather than described in general, the architecture the model depends on designed on the same track rather than after it, what the pilot area actually showed once the new decision rights were in force, and a rollout sequence with its dependencies and its costs, which is the piece a board approves against. An honest design also says plainly which parts are not ready to move yet. All of it is owned by a named executive on your side, because it has to outlast whoever wrote it.