I’ve been writing about Strategy Deployment a lot recently but realised that I haven’t properly defined what I mean by the term. Actually, I sort of did in my last post, so I’m going to repeat, expand and build on that here.
In a nutshell, Strategy Deployment is any form of organisational improvement in which solutions emerge from the people closest to the problem.
The name comes from the Japanese term, Hoshin Kanri, the literal translation of which is “Direction Management”, which suggests both setting direction and steering towards it. A more metaphorical translation is “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety.
Lets look at the two elements, strategy and deployment, separately.
Strategy
Wikipedia defines strategy as
“a high level plan to achieve one or more goals under conditions of uncertainty”.
The emphasis is mine as these are the two key elements which indicate that a strategy is not a detailed plan with a known and predictable outcome.
Strategy to me is about improving and making significant breakthroughs in certain key competitive capabilities. I like Geoffrey Moore’s Hierarchy of Powers from Escape Velocity as a guide for exploring what those capabilities might be. This hierarchy is nicely summarised as
“Category Power (managing the portfolio of market categories in which a company is involved), Company Power (your status relative to competitors), Market Power (market share in your target segments), Offer Power (differentiation of your offering), and Execution Power (your ability to drive strategic transformation within your enterprise).”
As an aside, in this context, Agility as a Strategy can be thought of as primarily (although not exclusively) focussed on improving Execution and Offer Powers.
Determining Strategy as “a high level plan to achieve one or more goals under conditions of uncertainty”, therefore, involves setting enabling rather than governing constraints. Strategy should guide the creation of new solutions, and not control the implementation of existing solutions. It defines the how and not the what, the approach and not the tools.
Deployment
Mirriam-Webster defines deploy as
“to spread out, utilize, or arrange for a deliberate purpose”.
In this context it is the strategy that is being utilised for the deliberate purpose of improving organisational improvement. Given that the strategy is “a high level plan to achieve one or more goals under conditions of uncertainty”, this means that the deployment is not the orchestration and implementation of a detailed plan.
Instead it requires a shift in the way organisations operate, from a mindset where management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that managers know the right answers as a facts, the deployment of strategy assumes that any suggestions are simply opinions to be explored and challenged. Employees are allowed, and encouraged, to think for themselves, allowing for the possibility that they may turn out to be wrong, and making it acceptable for people to change their mind.
As another aside, this brings to mind a great Doctor Who quote from the latest season:
"Do you know what thinking is? It's just a fancy word for changing your mind." #DoctorWho pic.twitter.com/Qf8AONNuVw
— Doctor Who on BBC America (@DoctorWho_BBCA) November 8, 2015
Strategy Deployment
Back to my original definition of “any form of organisational improvement in which solutions emerge from the people closest to the problem.”
Strategy Deployment is the creation of a high level plan for organisational improvement under conditions of uncertainty (the strategy), and the utilisation of that strategy by employees for a deliberate purpose (to achieve one or more goals). Clear communication of both the goals and the strategy, and constant collaboration across the whole organisation to use all the skills, knowledge and experience available, allows the appropriate tactics emerge. In this way Strategy Deployment enables autonomy of teams and departments while maintaining alignment to the overall strategy and goals.
Note that I say any form. I don’t see Strategy Deployment as a specific method, or framework, but more as general approach or style. My preferred approach at the moment uses the X-Matrix, but I would also describe David Snowden’s Cynefin, David Anderson’s Kanban Method, Mike Burrows’ Agendashift and Jeff Anderson’s Lean Change Method as forms of Strategy Deployment. I’m hoping to explore the synergies more at Lean Kanban North America and the Kanban Leadership Retreat.
[…] What is Strategy Deployment? (Karl Scotland) […]
Since Hoshin Kanri is already well defined and used for many years – what’s the point of changing its content? In 1964, Bridgestone Tire coined the term Hoshin Kanri and in 1965 published its Hoshin Kanri Manual. Bridgestone Tire codified the principles of Hoshin Kanri, based on an analysis of what Deming Prize winners had been doing. Is your definition the same as the original definition? If yes that’s not your definition. If not you shouldn’t use the name Hoshin Kanri.
Based on your definition :”any form of organisational improvement in which solutions emerge from the people closest to the problem” and the emphasis on Strategy I’d refer you to a famous Boyd’s paper called “Organic Design” where Boyd has (ignore the command and control words ): “A command and control system, whose secret lies in what’s unstated or not communicated to one another (in an explicit sense)—in order to exploit lower-level initiative yet realize higher-level intent, thereby diminish friction and compress time, hence gain both quickness and security.”
In my article here http://www.infoq.com/articles/noestimates-monte-carlo I present very similar thoughts (of course based on Boyd’s) but in the context of project planning only:
“Probabilistic high-level plan forecasts the initial budget and also the range of the time frame for a project. We don’t plan in detail what is not absolutely necessary to plan. The short-term details, like the scheduling, are done based on the immediate needs and capabilities – and we create these schedules upon the execution of the high-level plan. When executing the high-level plan we have to keep focus on the project intent but we can never be certain which paths will offer the best chances of realizing it. We exploit uncertainty by making a series of small choices which open up further options then observe the effects of our actions and exploit unexpected successes.”
So I’d propose you to use a name something like “Strategy Orientation” based on Boyd’s :
“Referring back to our previous discussion, we can say: orientation is an interactive process of many-sided implicit cross-referencing projections, empathies, correlations, and rejections that is shaped by and shapes the interplay of genetic heritage, cultural tradition, previous experiences, and unfolding circumstances.”
Hope that helps!
Dimitar
Karl,
I’ve been wondering what “Strategy Deployment” is for a while, I’ve heard you mention it but didn’t know so I’m glad to see this blog. Can I ask that you elaborate a little more?
This blog leaves me with more questions than answers really, although I do think “Strategy Deployment” is not a good name, from the name it sound akin to “Strategy implementation” and one imagines rolling out some big strategy.
I’m a bit confused when you write: “It defines the how and not the what, the approach and not the tools.”
From the proceeding discussion I thought it was defining the what but leaving the method of achieving that (how and tools) to those who need do the work. Perhaps you can clarify?
At one level I wonder if what you are arguing for it simply giving authority to decide who to implement to those who do the work? i.e. pushing authority down.
I also wondered if emergent strategy had a place here – although you didn’t name it – because emergent strategy says that strategy is changed by what happens and strategy may only become apparent in retrospect.
Please keep the explanations coming!
Thanks Allan – good feedback and questions. My hunch has been that Strategy Deployment is not as well understood as it could and should be, so my recent blogging and speaking has been an attempt to create wider awareness and figure out how to articulate my understanding. You’re not the first to interpret the deployment as implementation, so maybe a new name is needed. Dimitar makes as good suggestion in his comment. I’m not rushing into that decision though!
Some quick responses to rest of your comment.
I’m using How and What in the Simon Sinek “Start with Why” and “Golden Circle” sense. Why are we doing something. How will we approach it. What will we actually do. So, yes, Strategy is determined centrally, and authority for defining/discovering Tactics is deployed to those who do the work.
What I didn’t mention that you allude to is the dynamics of Strategy Deployment. In essence, everything can be viewed as hypotheses with experiments. Strategy Deployment can be thought of as nested experimentation. So as the Tactics are put in place, indications of success and failure give feedback not just on whether they are working, but also on whether the Strategy is appropriate. These feedback cycles allow for emergent strategy through amplification and dampening. The Lean community generally refers to this as Catchball. Its probably worthy of a future post!
Thanks for coming back Karl, I look forward to future posts.
One immediate comment, about the idea that Strategy is a central determined thing. This is the image of Strategy as pushed by Porter and countless consultants, this therefore assumes the best information is at the center and that once decided it is “simply” a question of implementing the strategy through tactics.
However there is an alternative view of strategy – well there are several actually – which says that strategy may be emergent, it arises from what you do and the learning that occurs – often at the edges. Strategy can only really be understood retrospectively.
There is probably a balance between “centrally directed” and “completely emergent”. However the emergent view of strategy fits must better with the ethos and philosophy behind the agile movement.
At the danger of repeating myself too often, the parallels between the history of strategy and the traditional view of software development are striking. Mintzberg’s “Rise and Fall of Strategic Planning” describes how central strategy and “simple” implementation came to being and how it failed. It could almost be written about software development. I would go as far as to say the origin of our “waterfall” approach is indeed rooted in that approach to strategy and in particular Pentagon thinking in the early 60s under McNamara.
I agree with all of this, which probably means I need to work on my explanation more 🙂
I don’t think that centrally determining strategy is at odds with emergent strategy. I use the word centrally deliberately as opposed to “from the top”, and I would say that a central group can determine a strategy by understanding the potential of the current state (or side-casting to use Cynefinish language).
The difference between the way I think of Strategy Deployment and the “simply implement” approach you describe is the feedback cycles which enable the evolution and emergence. That’s why you need to have clear alignment with Strategy as “enabling constraints” to allow that to happen. Complete emergence may mean no constraints, which may mean chaos. Complete direction probably means “governing constraints”, which may also ultimately lead to chaos as well by a different route!
From a military perspective, I’m more aligned with the approach Stephen Bungay describes in the The Art of Action.