How to Structure a Change Team That Actually Works
Most change teams are built around headcount and methodology. The ones that work are built around a specific pairing of capabilities — and it's a pairing most organizations consistently get wrong.
By Cursus Research Team
Most change initiatives fail not because the methodology was wrong, but because the people running them didn't fully understand what was actually changing.
This is a structural problem, not a competence problem. The classic failure mode looks like this: a skilled OCM practitioner who understands change deeply — resistance patterns, stakeholder engagement, communication architecture — but can't credibly speak the language of the business domain being transformed. Paired with, or more often replaced by, a functional expert who understands the system or process being changed but has no framework for the human side.
Both archetypes, alone, are insufficient. The change practitioner designs a technically sound change plan that doesn't reflect how the impacted population actually works. The functional expert runs a super-user program that never addresses the underlying resistance, and adoption stalls six months post-go-live. The organizations that manage change well have figured out that these two capabilities need to operate in combination — not sequentially, and not interchangeably, but as genuine co-owners of the stakeholder outcomes.
The thesis is simple: a change team's structure should be designed around this pairing of capabilities. Not around a methodology framework. Not around certification levels. Not around headcount.
Why Structure Gets Treated as an Afterthought
Change teams are often assembled late. They are under-resourced. They are expected to "handle communications and training" while the real work happens elsewhere. In this model, the practitioner is a project coordinator with a change methodology overlay, and the question of who provides domain expertise is left to chance — or, more often, to a busy subject matter expert who has no bandwidth or orientation for change work.
The stakes of getting this wrong are high. Change saturation — the condition where impacted populations are absorbing more change than their capacity allows — is partly a structural problem. When programs run without genuine domain expertise in the change team, they underestimate what is actually hard for impacted groups, overestimate the effectiveness of generic communications, and miss the resistance patterns that only become visible to people the impacted population trusts.
Leader fatigue and adoption failure are downstream consequences of structural gaps that were baked in at program inception.
The Three Common Models (and Their Limits)
Most organizations organize their change capability in one of three ways.
The centralized CoE model puts a dedicated OCM team in charge of all change programs. This produces methodology consistency and practitioner development. It also produces bottlenecks. A centralized team managing multiple concurrent programs cannot be embedded deeply enough in any of them to do the work that matters. As the volume of simultaneous change has grown — and it has grown dramatically — the centralized model increasingly produces either queue management or rubber-stamping.
The federated model embeds practitioners within business units or program teams. This solves the distance problem: practitioners gain business context and build trusted relationships. It creates new problems in return: methodological inconsistency across programs, practitioner isolation, career path fragility, and no cross-portfolio visibility into cumulative change load.
The hybrid hub-and-spoke model — a small central CoE that sets standards and provides senior capacity while practitioners embed in the business — is generally the right direction for mature organizations. It is also consistently missing something. The structural gap that no variant of these models typically addresses is the functional expert pairing. That is the structural insight most frameworks miss entirely.
The Core Structural Argument: Pairing, Not Proximity
The change practitioner brings a specific set of capabilities to a program: change methodology, stakeholder analysis, resistance pattern recognition, communication and training architecture, and cross-program perspective. These are hard-won skills that take years to develop. They are also, by themselves, insufficient.
The functional expert brings something the practitioner structurally cannot: deep knowledge of the system, process, or domain being changed. Credibility with the impacted population — not borrowed credibility, but the kind that comes from having worked in the same domain. The ability to identify what will genuinely be hard for impacted groups, as opposed to what a change plan assumes will be hard. Context for what "good adoption" looks like in this specific domain, not in the abstract.
Neither is effective alone at scale.
The practitioner designs the change approach; the functional expert pressure-tests it against operational reality. The functional expert brings the "what"; the practitioner brings the "how." Stakeholders trust the functional expert enough to be honest with them; the practitioner knows what to do with that honesty. The functional expert can identify the specific workflows and job contexts that a generic communication plan will fail to address. The practitioner can translate that specificity into structured engagement design.
Consider an ERP implementation. Without the functional expert, the practitioner runs a training program that doesn't reflect how Finance actually closes the books. The training is technically accurate. It is functionally useless for the people who need to use the system under time pressure. Without the practitioner, the functional expert runs a super-user network that has no structured resistance management, no stakeholder analysis, no sequenced engagement plan. Adoption data looks reasonable at go-live and deteriorates over six months. With both: the functional expert co-designs job aids that reflect real workflows; the practitioner maps resistance patterns by persona and builds targeted interventions for the groups where resistance has legitimate operational roots.
Who Should Play the Functional Expert Role?
This is the question organizations struggle with most, because the functional expert is not always an obvious hire. The options depend on program type and organizational context.
In some cases the right person is a subject matter expert from the impacted team, seconded into a change enablement role for the program's duration. In others it is a former practitioner in the domain — a finance manager who lived through a previous ERP implementation and understands both the system and the people. In others it is an elevated super-user or a business analyst on the program team who can be oriented to the change dimension of their existing role.
The title matters less than the traits. The functional expert needs credibility with their peers — meaning the impacted population will actually be honest with them about what's not working. They need comfort with ambiguity and the willingness to challenge the program team when the change plan doesn't reflect operational reality. They need genuine empathy for the people being impacted, not the performative version. And they need enough organizational standing to be heard when they escalate.
What they do not need is deep OCM methodology training. That is the practitioner's job. The functional expert needs enough change literacy to understand the approach and contribute meaningfully to stakeholder design — not enough to run the program independently.
Formalizing the Pairing
The pairing only works if it is made explicit. A functional expert who is informally involved in a change program — consulted occasionally, looped in on communications reviews — is not a co-owner. They are a reviewer. The structural conditions for effective pairing require more than informal collaboration.
Define the pairing in the program charter. Not as a courtesy role or an advisory position, but as co-ownership of stakeholder outcomes. The charter should name both the practitioner and the functional expert, define their respective accountabilities, and make clear that change outcomes are jointly owned.
Give the functional expert real accountability. Adoption metrics, not just delivery metrics. When the functional expert's own performance is connected to whether impacted groups are actually using the new system or process six months post-go-live, their engagement with the change work deepens qualitatively.
Create a shared working rhythm. Weekly practitioner and functional expert syncs. Joint stakeholder sessions. Co-authored communications and job aids. The functional expert should not be receiving the practitioner's outputs for review — they should be shaping those outputs from the start. The difference is significant and visible to stakeholders.
Protect the practitioner's independence. The functional expert should not manage the practitioner. They are organizational peers with different expertise, not a hierarchy. This matters because the practitioner's ability to identify resistance, escalate concerns, and challenge program assumptions depends on their independence from the functional line.
Differentiate escalation paths. The practitioner escalates to the program leadership structure and, in organizations with a CoE, to the CoE. The functional expert escalates within their business unit. Both paths need to be open and respected. When the functional expert surfaces legitimate operational concerns about a change plan, that feedback has to reach the right decision-makers — not get filtered out by the program hierarchy.
Scaling the Model
For organizations running multiple concurrent change programs, the pairing model has to be systematized. Leaving it to individual program leaders to figure out whether they have functional expert coverage produces inconsistency: some programs will have it, most won't. The capability becomes a function of which program leaders happen to understand its importance.
The CoE's job in a scaled environment is to operationalize the pairing. That means maintaining a roster of functional expert candidates across the domains most commonly affected by change — finance, operations, technology, HR, supply chain. It means orienting those candidates in change basics so they can step into the role without a long ramp. It means matching functional experts to incoming programs based on domain relevance and relationship capital, not just availability.
This reframes what "change capability" means at the organizational level. It is not a headcount in a central team. It is a distributed network of practitioners and functional experts who can be paired effectively against any program in the portfolio. The organizational intelligence layer that tracks stakeholder group readiness, behavioral signals, and cumulative change load becomes the substrate that both practitioners and functional experts use to make better decisions — faster, and with evidence rather than assumption.
The Real Question to Ask
The change team structure question is not primarily about FTEs, reporting lines, or methodology certification. Those are proxies. The underlying question is whether the people running change have the combined knowledge to understand what's changing and how the people experiencing it will actually respond.
Audit your current change programs. For each one, ask two questions: Who is the change practitioner? Who is the functional expert? If you can name both and describe how they are working together, you have the structural foundation the program needs. If you can name only one — or neither — you have identified the gap most likely to produce adoption failure, not as a consequence of poor execution, but as a predictable outcome of a structural design that never gave the program what it needed.
The pairing model is not a new idea. It is consistently under-institutionalized. Organizations that get it right treat it as an architectural decision, not an improvisation — and they make it early, before the program has already built momentum on the wrong foundation.
Further reading: The Job of the Change CoE · Change Saturation: Measuring Cumulative Change Load · From Change Management to Organizational Intelligence · Decentralizing Change: Equipping the People Closest to It
Want to see Cursus in action?
Explore the interactive demo or request a personalized walkthrough.
See the Demo