How to Build a Plan for a Dynamic Operating Model

What Do We Mean by a “Dynamic” Operating Model? A dynamic operating model has three defining characteristics. It: separates what must be stable from what must be adaptable enables rapid reconfiguration of work—not people is managed as a product, not a one-time design This means: Strategy can shift without rewriting job descriptions New services can be launched without new org charts Capacity can move without months of approval cycles The key point for today’s episode is you do not design a dynamic operating model -- you plan for its continuous development. Step One: Anchor the Model in Outcomes, Not Structure The first mistake organizations make is starting with structure. Who reports where. Which division owns what. Where digital or CX should “sit.” A dynamic operating model starts somewhere else entirely: outcomes. Your plan must begin by answering three questions: What outcomes matter most to the people we serve? What outcomes matter most to the organization? Where are those outcomes currently constrained? In government, this might be: Time to decision Ease of compliance Quality of service recovery In enterprise, it might be: Speed to market Cost to serve Retention and loyalty Your operating model exists to reliably produce outcomes under changing conditions. If the outcomes are unclear, the model will always be sketchy. Step Two: Identify the “Fixed Spine” of the Organization Every dynamic operating model has a stable foundation. This includes: Core governance Financial controls Risk management Legislative or regulatory obligations Enterprise platforms and data foundations Your plan must explicitly document: What cannot change frequently What should not change frequently This is not a limitation—it’s an enabler. When people know what is fixed, they are far more comfortable adapting everything else. Dynamic organizations are not chaotic. They are clear about their non-negotiables. Step Three: Design for Flow, Not Functions The third element of your plan is shifting how work is organized. Traditional operating models organize around: functions programs channels Dynamic operating models organize around value flows. That means: End-to-end journeys Products and services Capabilities that cut across silos Your plan should define: The major value streams that deliver outcomes The capabilities required to support those streams How those capabilities are shared, not duplicated This is where agility actually comes from—not from agile ceremonies, but from reducing handoffs and ownership ambiguity. Step Four: Build an Evolution Roadmap, Not a Target State This is the most important shift. Static operating models aim for a “future state.” Dynamic operating models plan for perpetual evolution. Your plan should include: A 12–18 month evolution roadmap Clear hypotheses about what changes will unlock value Lightweight governance for testing and adjusting Think in terms of: “If we change this capability…” “If we move ownership here…” “If we standardize this platform…” Then measure, learn, and adapt. A dynamic operating model is never finished. To wrap Developing a dynamic operating model is not a design exercise—it’s a leadership commitment. It requires leaders to: Let go of false certainty Reward learning, not just compliance Invest in capability, not just capacity