What separates transformation programs that deliver from those that endlessly replan is not the vision. It is whether anyone designed the system around the strategy, and the teams inside it.
Two Strategies
I have seen strategy done at both extremes.
At one extreme, a strategy group of a high-tech company valued at over $200 million. The strategy we reviewed was a list of wishes: "We will dominate the category." "We will be the platform of choice." Nothing an engineering lead or a sales director could act on Monday. Nobody could disagree with it. That was the problem.
At the other, a large-scale digital transformation in government. Goals ten years out, the first five defined down to clear outcomes: sequenced, owned, measured, deep enough to start work tomorrow morning. No poetry. Choices. Still the best-written strategy I have seen.
But even the second one hit trouble in delivery, because a sharp strategy is the entry ticket, not the game. Vision-driven programs live or die on two design acts: the stakeholder system, the institutions and incentives around the program, and the delivery system, the teams and how they interact. Strategy is the hinge between them, and strategy implementation is where it breaks. Transformation programs fail when a well-written strategy meets an undesigned system: stakeholders who don't believe they are part of it, and teams structured against the flow of value.
Good Strategy Defines Action
You can judge a program before it starts, just by reading its strategy document. What matters is whether it defines action: a good strategy tells people what to do differently, a bad one tells them how to feel about the future.
My Executive MBA at Quantic gave me a name for the difference: strategy is choices under constraint, not ambition. Richard Rumelt's Good Strategy Bad Strategy calls the bad kind "fluff" and gives the good kind a kernel: a diagnosis of the real challenge, a guiding policy, and coherent actions that follow.
The test: does the document make any choices that could be wrong? "Citizen services before back-office" is a strategy. "World-class, agile, citizen-centric" is not — nobody can disagree with it, which is exactly why it cannot guide anyone. And a strategy that can be wrong can also be rehearsed against failure, something I explored in Overthinking vs Scenario Planning.
A well-written strategy is not the end of the design work. It is a claim about a system, and systems push back.
The System Will Vote
Design for Real Purposes, Not Stated Ones
Donella Meadows, in Thinking in Systems:
"A system is a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time."
The ministries, agencies, and vendors you want to transform are not an org chart waiting for instructions. They produced their own pattern of behavior long before your program existed. Your strategy is an intervention in that pattern, and the pattern will respond. Meadows again:
"Purposes are deduced from behavior, not from rhetoric or stated goals."
Every stakeholder has a stated purpose, the one in its charter, and a real one: protect the budget, avoid blame, control the data. Design for the real purposes. A strategy that only engages the stated ones is working with a system that does not exist.
Policy Resistance, and the Way Out
Meadows calls the most common failure policy resistance: many actors each pull the system toward their own goals, so every push produces a counter-pull. The program pushes a shared platform; the departments quietly renew legacy contracts. Nobody is sabotaging anything. Everyone is rational inside their own limited view, and the system stays stuck. Her way out:
"Let go. Bring in all the actors and use the energy formerly expended on resistance to seek out mutually satisfactory ways for all goals to be realized—or redefinitions of larger and more important goals that everyone can pull toward together."
This is not "communicate the vision more." It is structural: redesign the program so each actor's own goals are served by the transformation succeeding. The ministry that fears losing its data gets governance rights in the platform, not reassurance. A system resists as long as stakeholders experience the change as done to them; build their purposes into its rules and governance, and they move inside the system, pushing forward. This is what stakeholder management actually means in a transformation program: not a communication plan, but structural design.
Pull the Strong Levers
"Missing information flows is one of the most common causes of system malfunction."
Program governance moves status upward, to the steering committee. Almost none of it moves information sideways, showing stakeholders how their decisions affect each other. An information flow is often stronger than a rule, and far cheaper than a committee.
And in Meadows' hierarchy of leverage points, budgets and deadlines — the things steering committees love to adjust — sit at the bottom. Rules, information flows, and goals sit at the top. A replan with new dates and the same structure pulls the weakest lever available.
"Systems can't be controlled, but they can be designed and redesigned."
That is the job description. Not commander. Designer.
Teams Are the Execution Architecture
Strategy implementation is not a planning exercise. It is an organizational design exercise, and the unit of design is the team.
Team Topologies by Matthew Skelton and Manuel Pais rests on Mel Conway's 1968 insight:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Your program will ship its own org chart. Organize delivery as a web of workstreams, committees, and shared pools, and you will deliver a web of partial integrations and handoffs. No strategy execution framework survives teams that mirror the org chart. Skelton and Pais invert Conway, the reverse Conway maneuver: decide the outcome architecture first, then shape teams to match it.
Team Topologies defines four team types: stream-aligned teams around a continuous flow of value; platform teams that "enable stream-aligned teams to deliver work with substantial autonomy"; enabling teams that grow capabilities in others; and complicated-subsystem teams for deep-specialist pieces. It also defines three interaction modes: collaboration, X-as-a-Service, and facilitating.
Most programs instead staff workstreams named after strategy pillars, with a PMO that interacts mainly by asking for status. Pillars are categories, not streams of value. Nobody receives anything from a pillar. Organize delivery around actual streams — the citizen journey, the enterprise service — and leave the pillars in the document.
The book's deeper contribution is cognitive load: every team has a limit to the complexity it can hold. One team asked to master a legacy stack, a new platform, three vendors, and a compliance regime will not go faster because the steering committee is anxious. It will slow down. The fix is architectural: shrink the team's responsibility, move the platform burden to a platform team, send an enabling team to teach.
The two designs are really one discipline. Policy resistance between ministries is a broken interaction mode between teams at larger scale. In both books, flow comes from boundaries drawn so each unit serves its own purpose and the whole, with communication designed rather than maximized. Both design the connections instead of pushing the parts to try harder.
One Chair, Two Designs
Back to the two strategies. The $200 million company never got past the writing test: no choices, so execution defaulted to whoever argued loudest that quarter. The government program passed brilliantly and still stalled wherever a stakeholder's real purpose was never built into the structure, or teams were sliced to mirror the org chart.
Business school teaches the first design, engineering culture teaches the second, and almost nobody is taught to hold both. The craft is doing both, in order. Write a strategy sharp enough to be wrong. Read stakeholders' real purposes from behavior and move the boundary so they are inside the system. Then run the reverse Conway maneuver: organizational design around streams of value, cognitive load protected, every team interaction a deliberate choice.
None of this looks impressive in a slide deck. But a few years in, one kind of program is on its third replan, and the other is quietly delivering.
"You can't navigate well in an interconnected, feedback-dominated world unless you take your eyes off short-term events and look for long-term behavior and structure."
Meadows was writing about the world. She could have been writing the job description of everyone ever handed a vision and asked to make it real. The vision is the easy part. The two designs are the work.
References
Meadows, D. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
Meadows, D. (1999). "Leverage Points: Places to Intervene in a System." The Sustainability Institute.
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
Conway, M. (1968). "How Do Committees Invent?" Datamation.
Rumelt, R. (2011). Good Strategy Bad Strategy: The Difference and Why It Matters. Crown Business.