What Your Operating Model Actually Needs
Two pieces in this series named the same underlying problem from different angles: an operating model that accumulates instead of being designed, and a decisioning/capability split teams get backwards. This piece puts three tools behind the decisions both articles argued nobody’s making deliberately.
The gap between the argument and the org chart
Why Good Teams Fail When the Operating Model Is Wrong made the case that fragmented journeys, conflicting KPIs and duplicated communications aren’t a people problem, they’re what happens when an operating model accumulates team by team instead of being designed as four distinct, accountable layers. Decisioning vs Capability then zoomed into one relationship inside that structure specifically: the fight between cross-functional squads and channel teams, which is really just two different jobs, deciding and delivering, collapsed into one group by accident.
Both pieces argue convincingly for a structure. Neither one tells you which starting structure fits your organisation specifically, whether your foundation can actually support what you’re trying to build on it, or how big the team doing the work needs to be. That’s the gap these three tools close.
Three tools, one job each
Two of these are decision tools, not calculators, answer a handful of questions, get a starting-point recommendation rather than a dollar figure. The third turns a workload into a headcount.
| Tool | Answers |
|---|---|
| Operating Model Decision Tool | Whether Centralised, Decentralised, Hub-and-Spoke, or Federated fits how your organisation actually works |
| Capability Horizon Diagnostic | Which maturity horizon, foundation, growth, or retention, actually needs attention first |
| Team Sizing & Span of Control Calculator | What team size and manager count your current campaign and channel workload actually needs |
Three scenarios, three decisions
These are illustrative, not client figures. Swap in your own answers and inputs and the shape of the argument stays the same even if the recommendation changes.
Centralised, federated, or something in between?
A business runs marketing across three regions on a shared martech stack. Head office wants consistent governance and one standard everywhere. Regional teams want the flexibility to respond to genuinely different local conditions. Both sides have a point, and without a structural answer, the debate just repeats every planning cycle.
The tool is explicit that this is a starting point for a leadership conversation, not the final answer, an operating model is a framework for roles and decisions, not an org chart. What it does is stop the debate defaulting to whichever side argues loudest in the room.
Answer the four questions →Curious what these look like against your own structure?
Run all three tools from this piece against your own regions, capability maturity, and workload, not the illustrative ones here. If any of the terms need a plain-English definition, the glossary has them.
Building the top floor before the foundation
A business wants real-time lifecycle triggers and churn-response personalisation, the kind the loyalty and retention pieces in this series describe, and keeps investing in that layer directly because it’s the one with the visible commercial upside. The results stay mediocre no matter how much is spent on the personalisation logic itself, and nobody can quite explain why.
This is the direct numeric version of a point both source articles make in different words: a sophisticated layer built on an under-resourced or unstructured one underperforms regardless of how good that top layer is on its own. The diagnostic exists to make that sequencing visible before the budget for Horizon 3 gets spent.
Diagnose your own foundation →What “tacked onto someone’s existing job” actually costs
The four-layer piece named this as the single most common failure: the orchestration function gets created as an extra responsibility bolted onto someone’s existing role, rather than resourced as the genuinely new, full-time function it needs to be. It reads as a reasonable cost saving right up until it quietly collapses back into whichever team has the most organisational weight.
Whoever’s had orchestration “tacked on” is, on this workload, carrying what a five-person team was actually built for. That gap between the org chart line item and the real number is exactly the kind of thing that’s easy to wave away in a planning meeting and much harder to wave away next to a headcount figure.
Size your own team →What the numbers don’t show
None of this replaces the argument in either source piece. A decision tool points toward a starting structure, it doesn’t design the governance forums, define the RACI, or run the pilot on one or two journeys first the way the four-layer piece recommends. A team sizing calculator tells you the headcount a workload needs, it doesn’t tell you how to structure the handoff between the decisioning side and the capability side the way the Journey Squad and Home Team model does.
What the numbers do is stop these decisions from being made by default, whichever structure the business already happens to have, whichever layer gets budget because it’s the most visible, whoever’s calendar had the most room to absorb “one more responsibility.” Both source pieces are ultimately arguing for the same thing: name the accountability explicitly, on purpose, before the structure decides itself by accumulation.
The Operating Model Playbook goes deeper on this
The four-layer structure, why coordination isn’t the same as accountability, the Journey Squad and Home Team split, and how to sequence a pilot without breaking the org, all of it’s worked through in full in the free Operating Model Playbook. These tools are the starting-point maths; the playbook is the operating model behind it.
Get the Operating Model Playbook →Operating model tools, explained
Are the Operating Model Decision Tool and the Capability Horizon Diagnostic calculators?
No, both are decision tools: you answer a handful of questions about your situation and get a starting-point recommendation rather than a dollar figure. Team Sizing & Span of Control is the one calculator in this category, and it does return a number, a recommended headcount.
Will these tools tell us definitively which structure to choose?
No, and they say so themselves. An operating model is a framework for roles and decisions, not an org chart, so the output is a reasonable starting point for a conversation with your leadership team, not a final answer you can skip that conversation with.
Do I need my own workload figures, or can I use the defaults?
The defaults are illustrative starting points only. For a headcount figure worth taking into a resourcing conversation, replace them with your own campaign volume, channel count, and hours-per-campaign figures.
How is this different from just reading the Operating Model Playbook?
The playbook covers the operating model itself: the four layers, why governance needs structural separation, and how to pilot a change without breaking the organisation. These tools are narrower: they turn one specific structural question into a starting-point recommendation or a number. Most people get more from using both together than either alone.
