The team just finished roadmapping in Step 5, building together: generative, creative, high-ownership work. Step 6 asks them to design meetings and define decision rights, and the room’s posture shifts. If Step 6 feels disconnected from that energy, the team will treat the operating model as overhead rather than infrastructure and abandon it within a month of the consulting team leaving.
Every Element Traces Back to the Roadmap
The design move that prevents this is framing every element of the operating model as a direct continuation of the roadmap work. The operating rhythm is the set of meetings that will make the roadmap actually happen; the escalation framework is how the team will resolve the conflicts logged during roadmapping; the role charters name who owns each decision the roadmap depends on.
Every element traces back to something the team built in Steps 4 and 5. When the framing is right, Step 6 feels like the logical next question: you built the plan, now how do you run it?
The Smallest Set of Structures That Keeps a Program Coordinated
The operating model should be the smallest set of meetings, roles, and decision rules that keeps the program coordinated. The test for each element is specific:
- Does this meeting enable a decision, and does the role attached to it have a decision right?
- Does this escalation path resolve a type of conflict that cannot be resolved at the working level?
If a meeting doesn’t enable a decision, it’s a status update that can be replaced by an async written update; if a role doesn’t have a decision right, it’s advisory and doesn’t need to be in the operating model. Without this discipline, programs end up with governance structures that generate too many meetings.
The minimum viable operating model for a cross-functional program with four to six workstreams typically includes three layers:
- The working-level cadence is where execution happens. Each workstream has a weekly session where the workstream lead reviews progress against milestones, surfaces blockers, and makes decisions within their scope.
- The cross-functional cadence handles everything above the workstream level. A biweekly or monthly session brings all workstream leads together to review dependencies, resolve multi-team conflicts, and update the integrated roadmap.
- The executive cadence resolves escalated decisions and confirms resource commitments. That session is a decision meeting, not a status presentation.
Decision Rights Belong at the Decision Level
The operating model defines decision rights at the decision level, not at the role level. For each type of decision the program will face (e.g., milestone changes, resource reallocation, scope adjustments), there’s a clear owner and a clear escalation path:
- Milestone changes within a workstream are decided by the workstream lead; changes that affect other workstreams are decided by the program lead in consultation with the affected workstream leads.
- Milestone changes that affect the overall program timeline are escalated to the executive sponsor.
This specificity matters because cross-functional programs generate conflicts that don’t fit neatly into any single leader’s authority. Two workstreams sharing a regulatory affairs resource cannot both have priority during the same submission window; someone has to make that call, and the operating model names who. One client team that applied this approach cut meetings by forty percent in the first quarter.
A Durable Operating Model Outlasts the Engagement
The operating model is the artifact most likely to outlast the engagement. Roadmaps get updated and charters get revised, but the operating rhythm (who meets when, who decides what, where conflicts go) becomes the way the program actually runs.
At the ninety-day mark after the engagement ends, the test is straightforward: is the team still meeting at the cadence they designed? Are decisions being made by the right people and conflicts being escalated through the path that was built, or through the same informal channels that existed before?
If the operating model is running, the program has infrastructure. When the operating model outlives the program it was built for, we’ve helped produce something more durable than a set of deliverables. If it’s been abandoned, the program is running on improvisation, and cross-functional programs cannot sustain improvisation at scale.
