What these parts deliver, and why
Assess told the client where to start; the pipeline told them what to build. These two parts answer the next question: who runs it, and on what? We design the operating model — the Content Services Organization on three durable practices, strategy + engineering + operations — write the roles around it, resource them realistically for the client's scale, and only then select the stack to match. The order matters: the model comes before the tools, every time.
- 1 · Design the operating model — charter the Content Services Organization; pick the shape: centralised, hub-and-spoke, or federated.
- 2 · Define roles & RACI — the role set, with the modular content architect as the keystone hire; clear accountability per activity.
- 3 · Skills & resourcing plan — hire vs train vs borrow; the realistic team for mid-market vs enterprise.
- 4 · Select the tech stack — the 5-layer reference stack, evaluation criteria, MACH / composable, build-vs-buy.
- 5 · Operating-model governance — the Content Services council, cadences, how it runs day to day.
Design the operating model
Decide the shape of the content function before naming a single tool or person. Charter a Content Services Organization on the three durable practices — strategy, engineering, operations — and pick the topology that fits this client's size, brand spread and politics.
- Map today's reality — who owns content, where it's fragmented, who's already doing engineering work without the title (30m)
- The three practices — agree what strategy / engineering / operations each owns, and that engineering is the keystone (30m)
- Pick the shape — centralised (one team owns it), hub-and-spoke (govern & enable at the centre, execute at the edge), or federated (standards-led, autonomous teams) (45m)
- Decide what lives at the centre vs the spokes — model, taxonomy and governance almost always central (30m)
- Draft the charter — mandate, decision rights, what success looks like (20m)
- Org chart & current content ownership
- Assess findings (maturity, gaps)
- Brand / business-unit structure
- Operating-model canvas (template below)
- Chosen topology + rationale
- CSO charter (1 page)
Nine times in ten the right answer is hub-and-spoke, and nine times in ten the client wants either a single empire or total autonomy. Draw the line where the model, taxonomy and governance sit at the centre and execution stays local — and put it in writing before anyone's reporting line is on the table, because that's when the conversation stops being about content.
Govern and enable at the centre; execute at the edge. The centre holds the model, taxonomy and standards; business-unit spokes run their own delivery within those guardrails. The default answer for most clients.
Define roles & RACI
Turn the model into named roles and clear accountability. Write the role set as roles, not people — then map who's responsible and accountable for each content activity. The modular content architect is the keystone: ontologies, metadata, brand-as-graph, MCP-ready structured content — the role the market now needs and our defensible wedge.
- Modular content architect ★ — the keystone. Owns the content model, taxonomy, semantic/graph layer and AI-readiness; the bridge between content strategy and the stack
- Content engineer — implements models, reuse, metadata, workflow and tech selection; the business↔IT translator
- Content strategist — the "CEO of content": audience, journeys, editorial plan
- Taxonomist — the controlled vocabulary, tagging and classification
- Information architect — structure, navigation, findability
- Content designer — the content people actually read and use
- Content ops manager — intake, workflow, cadence; runs the engine room
- Knowledge-graph engineer — entities, relationships, the intelligence layer (enterprise scale)
- CSO charter (Step 1)
- Existing job descriptions
- Role descriptions (architect spelled out below)
- RACI across content activities
RACI is roles, not names. Insist on at least one R and exactly one A per activity, and never let accountability be shared or delegated — "we're all accountable" means no one is. The fights happen over the A column; that's where they should happen.
Skills & resourcing plan
Decide, role by role, whether to hire, train an existing person into it, or borrow it (us, an agency, or a contractor) — and size the team honestly for the client's scale. The mid-market team and the enterprise team are different animals; don't sell one the other's org chart.
- Skills-gap pass — map each role to the people who could grow into it vs the skills genuinely missing
- Hire / train / borrow decision per role — be honest about which specialist skills are scarce in the market
- Right-size for scale (see below) — mid-market wears multiple hats per person; enterprise can afford dedicated specialists
- Phasing — which roles in the first 90 days vs which can wait for Phase 3 · Scale
- One content engineer / architect wearing both hats
- Strategist & ops manager shared with the wider marketing team
- Taxonomy & graph work borrowed from us or a contractor
- ~2–4 people who also do other things
- Dedicated modular content architect + content engineers
- Standalone taxonomist, IA and knowledge-graph engineer
- Content ops manager running the function full time
- A genuine team, often hub-and-spoke across BUs
Everyone wants to hire the "unicorn" content architect — the one who does ontologies, metadata, the graph, the stack and writes a clean brief. You won't find that person, or you'll find one and they'll leave in a year. Assemble the skills across two or three people and let us hold the rarest piece while they grow into it. A job ad for a unicorn is a vacancy you'll still be carrying at Christmas.
Select the tech stack
Choose the stack against the model, layer by layer, using the 5-layer reference stack — Structure → Repository → Orchestration → Intelligence → Delivery. Each layer rests on the one beneath; the foundation (structure) is where content engineering lives, and nothing above it works if that base is soft. Default to MACH / composable; decide build-vs-buy per layer.
- 1 · Structure — content model, taxonomy, metadata, schema. The foundation; where content engineering lives
- 2 · Repository — the source of truth: headless CMS, CCMS, DAM, PIM
- 3 · Orchestration — content marketing / ops platform (CMP); workflow and intake
- 4 · Intelligence — knowledge graph, vector DB, AI generation grounded via RAG
- 5 · Delivery — DXP / composable front end, APIs, and MCP as the agent contract
- Fit to the content model & AI-readiness (structured fields, schema, API/MCP access)
- MACH / composable alignment — API-first, headless, swappable, not a walled suite
- Interoperability with the layers above and below it
- Total cost & lock-in risk; build-vs-buy economics
- Team fit — can the resourced team in Step 3 actually run it?
- Content model & taxonomy (from Build / Pipeline)
- Current tooling inventory & contracts
- Resourcing plan (Step 3)
- 5-layer stack scorecard (template below)
- Build-vs-buy matrix per layer
- Recommended stack + sequencing
The shiny headless CMS is the trap. A client will fall in love with a demo and want to sign before there's a content model to put in it — and a headless system with no model underneath is just a more expensive way to store blobs. Tools are layers 2–5; layer 1 is yours to build first. Don't buy down the stack until the foundation is real.
Operating-model governance
Give the operating model a heartbeat so it runs after we leave. Stand up the Content Services council — the standing body that holds the model, taxonomy and stack decisions — set its cadences, and wire it to the day-to-day so the function is governed, not just designed. (This is the organisational governance; the AI risk & control stack lives in Part 4.)
- Charter the Content Services council — who sits on it, what it decides, where it can say no
- Set cadences — weekly ops standup, monthly model & taxonomy review, quarterly stack & maturity review
- Define decision rights — what the centre owns vs the spokes, change-control for the model
- Wire it to delivery — intake, prioritisation and escalation paths the team actually uses
- CSO charter, RACI, stack decisions
- Council charter & membership
- Cadence calendar & decision-rights map
RACI & effort summary
Who does what across these two parts. R Responsible · A Accountable · C Consulted · I Informed.
| Activity | Sponsor / Leadership | HR | Content lead | Martech / IT | Lead consultant | Content architect |
|---|---|---|---|---|---|---|
| Operating model design | A | C | C | I | R | C |
| Roles & RACI | C | C | C | I | R | C |
| Skills & resourcing | A | R | C | I | R | I |
| Stack selection | C | I | C | R | A | R |
| Operating-model governance | A | I | C | C | R | C |
| Week | Focus | Consultant days |
|---|---|---|
| Week 1 | Operating model design, start roles & RACI | ~3.5 |
| Week 2 | Finish RACI, skills & resourcing plan | ~3 |
| Week 3–4 | Stack evaluation, build-vs-buy, recommendation | ~4.5 |
| Week 4–5 | Council & cadences, handoff into Build | ~2 |
The artifacts you use and leave behind
Five core templates are spelled out below; the full set produced across these two parts is indexed at the end.
Content Services Organization — on one page
| Dimension | Capture |
|---|---|
| Mandate & purpose | Why the function exists; the one outcome it owns |
| Three practices | What Strategy / Engineering / Operations each owns — engineering as the keystone |
| Shape | Centralised · hub-and-spoke · federated — and why this one |
| Centre vs edge | What's owned centrally (model, taxonomy, governance) vs executed locally |
| Decision rights | Who decides the model, the standards, the stack — and who can override |
| Interfaces | How it works with brand, IT, BUs and agencies |
| Success measures | How the model itself is judged (ties to the Part 1 maturity re-score) |
The role the market now needs
- Mission — own the structure behind content so it's reusable, governed and AI-ready: the model, taxonomy, semantic/graph layer and MCP-ready access.
- Owns — content model & component library · taxonomy & metadata schema · brand-as-graph / ontology · AI-readiness of the estate.
- Partners with — strategist (what & why), content engineer (implementation), taxonomist & knowledge-graph engineer (the semantic layer), martech/IT (the stack).
- Skills — structured-content modelling, taxonomy/ontology, schema & semantic markup, API/MCP literacy, and the rare ability to translate between content and engineering.
- Seniority — senior IC or lead; the bridge role, not a junior tagging seat.
- Anti-pattern — do not write this as a "unicorn" spec that also owns writing, design and the CMS admin. Split the rare skills across people (see Step 3).
Content activities × roles — roles, not names
| Activity | Strategist | Architect | Engineer | Taxonomist | Ops manager |
|---|---|---|---|---|---|
| Editorial strategy & planning | A | C | I | I | C |
| Content model & components | C | A | R | C | I |
| Taxonomy & metadata | C | A | C | R | I |
| Workflow & intake | C | I | C | I | A |
| Stack & tooling | I | R | A | C | C |
Rule: ≥1 R and exactly 1 A per row; accountability is never shared or delegated. Fill against the client's actual roles, then reconcile to named people.
Criteria × layer — score each cell 1–5
| Layer | Model / AI-ready fit | MACH / composable | Interoperability | Cost & lock-in | Team fit |
|---|---|---|---|---|---|
| 1 · Structure | __/5 | __/5 | __/5 | __/5 | __/5 |
| 2 · Repository | __/5 | __/5 | __/5 | __/5 | __/5 |
| 3 · Orchestration | __/5 | __/5 | __/5 | __/5 | __/5 |
| 4 · Intelligence | __/5 | __/5 | __/5 | __/5 | __/5 |
| 5 · Delivery | __/5 | __/5 | __/5 | __/5 | __/5 |
Score the foundation (layer 1) first and hardest — a weak score there caps everything above it. Vendor names are illustrative, never endorsements; fit to the model wins.
Per capability — build, buy, or borrow?
| Capability | Build when… | Buy when… | Lean |
|---|---|---|---|
| Content model & taxonomy | Always — it's yours and bespoke to the business | Never wholesale; tools support it, don't replace it | Build |
| Repository (CMS/DAM/PIM) | Genuinely unique needs & the team to maintain it | Mature category, MACH options exist | Buy |
| Orchestration / CMP | Lightweight, tooling already covers it | Scale & workflow complexity justify it | Buy |
| Intelligence (graph / RAG) | Differentiating IP; in-house skill exists | Off-the-shelf graph & vector tools suffice | Mix |
| Delivery (front end / MCP) | Bespoke experience or agent contract | Composable DXP covers the channels | Mix |
Entry & exit gates
The quality bar that says these parts are genuinely ready to start, and genuinely finished.
- Assess complete; entry point & roadmap phase agreed
- Sponsor + HR/leadership engaged on team design
- Content model & taxonomy work underway (so the stack has something to fit)
- Operating model chosen, charter signed, topology agreed
- Roles defined with a clean RACI; resourcing plan owned by HR
- 5-layer stack decided with build-vs-buy rationale
- Content Services council stood up with cadences running