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 and operations), write the roles around it, resource them realistically for the client's scale, 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. 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. This is 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. Owns the controlled vocabulary, tagging and classification
- Information architect. Owns 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 to 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. A headless system with no model underneath is just a more expensive way to store blobs. Tools are layers 2 to 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 genuinely governed, not just designed once and forgotten. (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 to 4 | Stack evaluation, build-vs-buy, recommendation | ~4.5 |
| Week 4 to 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, with 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: at least 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 to 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