How to Design an OCM Operating Model That Actually Scales

Somewhere around the second or third simultaneous transformation project, most organizations realize their change management function doesn't have a real structure — it has a person (or two) doing their best to keep up. An OCM operating model is what turns "someone handles change management" into a function that can actually scale past a handful of projects without falling over. Here's how to think about building one.

Start with the problem, not the org chart

The instinct when designing an operating model is to start by drawing boxes — who reports to whom. That's actually the second step. The first is figuring out what's currently breaking: Is it that nobody owns decisions across projects? That domain experts (clinical, technical, operational) aren't looped in early enough? That leadership has no visibility until something's already off track? The operating model should be a direct answer to whichever of these is costing you the most right now — not a generic org chart borrowed from a case study.

The domain-lead model: a reasonable default

For most mid-sized change functions, a domain-lead structure works well: one central OCM lead accountable for the overall roadmap and portfolio prioritization, with domain-specific leads embedded in the areas where the work actually happens (operations, clinical or program delivery, technology, compliance — the exact domains depend on your organization).

This structure solves the two most common failure modes at once. A single central function without domain leads tends to lose touch with what's actually happening on the ground. Fully decentralized change efforts — every team running their own approach — tend to duplicate work and produce inconsistent standards. The domain-lead model splits the difference: central accountability, distributed execution.

Sizing it to where you actually are

An operating model built for a 20-person function, deployed on a 3-person team, just creates confusion — roles nobody's filling, layers that don't need to exist yet. Rough sizing guidance:

• 1-3 people: one person (or a very small group) covers all domains directly. Use a lightweight RACI as a personal checklist rather than a real delegation structure.
• 4-8 people: a central lead plus 2-3 domain leads, consolidating adjacent domains where volume is lower (e.g., combining technology and compliance under one lead).
• 9+ people: the full domain-lead model, often with a Center of Excellence layer added to coordinate standards and capture what's working across domains.

The mistake to avoid is designing for the org you'll be in two years from now. Build for where you are, and treat the operating model as something that gets revisited as headcount changes — not a one-time architecture decision.

Decision rights matter more than the org chart

An operating model without clear decision rights is just a diagram. The org chart tells you who reports to whom; it doesn't tell you who's actually accountable when a budget needs approving or a workflow change needs sign-off. That's a RACI matrix's job, and it's worth building alongside the structure, not after it — ambiguous ownership is one of the fastest ways a new operating model quietly reverts back to "whoever's loudest decides."

Piloting a Center of Excellence, if you're at that stage

Once a function reaches the point of needing to standardize how change gets done across multiple domains, a Center of Excellence (CoE) pilot is a common next step — but it's worth treating as a genuine pilot, not a permanent program from day one. A fixed 60-90 day window, a single narrow problem, a small team, and a hard decision point at the end (expand, extend, or close) keeps a CoE from becoming a department that quietly exists without ever proving its value.

Putting it together

A real OCM operating model has three parts working together: a structure that matches your actual headcount, decision rights that are explicit rather than assumed, and a way of reporting progress that leadership will actually read. Skipping any one of the three tends to recreate the original problem in a new shape.