What Strategic Execution Actually Looks Like When You Strip Away The Hype

Most people conflate planning with execution. They are not the same thing, and confusing them is why your initiatives die in slide decks. I spent years watching strategies look brilliant on paper and fall apart the moment anyone had to actually do the work. The difference comes down to a handful of mechanical habits, not inspirational speeches. I interviewed Steve Turrill several years ago while covering governance and policy implementation in Ontario. He had a blunt way of putting it: execution is just accountability with a deadline. That sentence alone is worth more than half the strategy frameworks you will encounter. What followed was a long conversation about how public sector organizations repeatedly fail not because the plan is bad, but because the plan has no ownership attached to each milestone.

Unlocking The Secrets Of Strategic Execution An Exclusive Interview With Steve Turrill Aka Steve Terreberry

The core idea Turrill keeps returning to is that a strategy without a single named owner per deliverable is just a wish list. I have seen this play out in practice more times than I can count. A municipal infrastructure team once spent six weeks debating whether drainage improvements should fall under public works or environmental services. Meanwhile, the budget window closed and the project stalled. The actual fix was simple: assign one director as the named owner, give them the budget authority to move money between departments, and set a hard date for the next phase. Done. Here is the practical framework I use when I need to turn a strategy document into something that actually ships:

Break it down into owned milestones

Every objective in your strategy should decompose into milestones with exactly one owner. Not a committee. Not a steering group. One person whose name appears next to the deliverable. When I worked on municipal policy rollouts, I learned that shared ownership is just a polite word for no ownership. If everyone is responsible, nobody is. You need to force the question: if this misses its date, who gets asked to explain why? This is where most people blow it. You can have perfect ownership and still fail if you do not understand what has to happen before what. Dependencies are usually invisible until something blocks. I ran into a specific problem once where a zoning policy initiative depended on environmental impact data from a different department. That department operated on a six-month turnaround. Our strategy timeline assumed eight weeks. We were going to miss by a wide margin and nobody noticed until three months in. The workaround was brutal but effective. I mapped every external dependency on a single page, estimated the worst-case timeline for each, and then built a buffer week for every dependency that lived outside my direct control. It sounds basic. Most people skip it. When I added the buffer, the project timeline shifted from eight weeks to fourteen, which was still two months shorter than reality would have demanded if we had not caught the dependency early.

Get the Full Details

Steve Terreberry Isugaku
Steve Terreberry Isugaku

Use visible status, not private updates

Private updates between managers and their teams are fine. But the actual status of strategic milestones should live in a shared space where anyone can see red, yellow, or green at a glance. I use a simple RAG system. Red means blocked. Yellow means at risk but moving. Green means on track. The moment something turns yellow, the owner writes two sentences explaining what changed and what they are doing about it. No meetings required. This cuts reporting time from hours per week to maybe fifteen minutes per milestone, and it surfaces problems early enough to actually address them. Strategies fail because people keep investing in them past the point of usefulness. The reason is social, not logical. Nobody wants to be the person who killed a project. The workaround is to define kill criteria in writing before you start. If a milestone misses by more than thirty percent, or if a key dependency shifts without notice, the project automatically goes to review. This removes the emotional weight from the decision. It is not anyone's opinion anymore. The criteria triggered the review. Simple. There are honest limitations to this approach that you should be aware of. It works well in structured environments like government, engineering, or operations where deliverables are tangible and deadlines are measurable. It does not work in creative industries where the output is ambiguous and the timeline is fluid. If you are running a research division or a product team that needs room to pivot, forcing ownership and rigid dependencies will suffocate the work. In those cases, a lighter framework with shorter feedback loops tends to perform better.

Another limitation is the human factor. Ownership only works if the person named is willing to be named. I have encountered leaders who refuse to put their name next to a deliverable because they do not want the exposure if it fails. When that happens, you have a cultural problem, not a planning problem. No framework fixes that. You either change the culture or you accept that accountability will remain vague. The practical takeaway is straightforward. Write down your strategy. Decompose it into owned milestones. Map the dependencies. Make the status visible. Set kill criteria. Then do the boring work of checking in weekly and adjusting when the numbers tell you to. The magic is not in the strategy. The magic is in the repetition.