Build a real operating model
Most organizations talk about run and change as if they were two competing priorities fighting for the same oxygen. Run keeps the lights on. Change prepares the future. One is framed as necessary but unglamorous, the other as exciting but disruptive. Budget discussions turn into trade-offs. Roadmaps become negotiation documents. Transformation gets postponed “until things calm down”, which they never really do.
Over time, this framing does real damage. I’ve come to believe that run versus change is not a tension to manage. It’s a trap created by an incomplete operating model. When run and change compete, both lose. Reliability slowly erodes, and transformation becomes chronically underfed, reduced to bursts of activity that never quite compound.
What’s missing is structure.
In organizations where things actually work, run and change are not separated by intention, but by design. Reliability is not something you protect by freezing everything around it. It’s something you engineer so that change can happen without putting the core at risk. Transformation does not live on the margins, begging for capacity. It is embedded into how work is planned, staffed, and governed.
That requires being explicit about what belongs where. Some parts of the system exist to be stable. Core platforms, identity, security foundations, critical data flows. These need clear ownership, strong standards, and a bias toward predictability. This is where reliability is built, and where improvisation is expensive.
Other parts of the system exist to evolve. Products, use cases, local processes, experimentation. These need room to move, fast feedback loops, and the ability to adapt without dragging the entire organization into change at the same pace. When this distinction is blurred, everything becomes fragile. Teams either slow down to protect the core, or they push change through brittle structures and pay for it later.
I often visualize this as a dandelion-like model. A strong, well-defined core that provides stability and shared rules, with multiple spokes that can evolve independently. The strength of the system does not come from rigid control, but from clear boundaries. People know where consistency is required and where autonomy is expected. That clarity removes friction far more effectively than endless arbitration. What usually starves transformation is not lack of ambition. It’s the absence of a credible operating rhythm. Change is treated as exceptional work, squeezed between incidents, deadlines, and urgent requests. Predictably, it slows down or burns out the teams carrying it.
A real operating model does the opposite. It reserves capacity for change by design. It aligns funding, staffing, and governance with long-term intent. It accepts that reliability and evolution are not opposites, but outcomes of the same system when it is designed coherently.
The hardest part is letting go of the illusion that reliability comes from control alone. In complex environments, reliability comes from adaptability. Systems that cannot change safely will eventually fail unsafely. When run and change stop being rivals and start being complementary, something shifts. Transformation becomes steadier. Operations become calmer. And leadership conversations move away from firefighting toward stewardship.
That, for me, is what an operating model is really about. Not choosing between today and tomorrow, but building a system that can carry both without tearing itself apart.
