← Strategic Target State Definition
From Target State to Target Operating Model
A target operating model should be derived directly from a validated target state: what must this organisation be able to do, which roles and decision rights follow from that, and what does the organisation look like once it can reliably do those things. Working this way, rather than designing an operating model in the abstract, keeps the model lean, it only includes what the specific ambition actually requires, not every function a generic best-practice template happens to recommend.
Why designing the operating model first gets the sequence backward
An operating model designed before the target state is validated ends up shaped by whatever structure already exists or whatever looked fashionable at a conference, rather than by what the ambition genuinely needs. The target state should constrain the operating model design, not the other way around.
What "capability first" actually means in practice
Start by listing what the organisation must be able to do to reach the target state, not roles, not org chart boxes, capabilities. Only once those capabilities are named does it make sense to ask which roles, decision rights, and reporting lines would actually deliver them.
Also relevant, on realtime-strategy.com: The eight-domain check that turns those named capabilities into an actual roadmap →
A common failure mode this approach avoids
Organisations that skip straight to operating model design tend to produce a structure that looks complete and impressive, while quietly assuming capabilities nobody has actually built. Deriving the model from a tested target state surfaces that gap before it becomes an expensive surprise mid-execution.
Your Vision Is Not the Problem. Not Knowing When You've Reached It, Is.
We turn vague ambition into a measurable, 12-18 month target state that actually aligns your leadership team, not a mission statement nobody disagrees with because nobody acted on it either.