So, (you think) you have a strategy?

There are many things called “a strategy”, but how can you assess them?

What if you want to construct your own strategy? Where to start?

In this article we explore a simple, usable definition of what a strategy is, as described by Richard Rumelt in his excellent book, “Good Strategy Bad Strategy” (publisher). If you get no further through this article, go and read that book. Be prepared for the soul-cleansing list of forehead-slappingly frustrating examples of “not a strategy”, based on real world case studies. It’s ok - they didn’t just happen to you.

We will fold in references to Goodhart’s Law (wikipedia), Conway’s Law (wikipedia), “bike-shedding” (wikipedia), “perverse incentives” (wikipedia), “The Innovator’s Dilemma” by Clayton Christensen (wikipedia), and Simon Wardley’s opening chapter about Wardley Maps (online book).

All of this will be seasoned with an over-generous sprinkling of personal opinion.

Definition of a Strategy

Let’s look at Rumelt’s definition (again, read his book for a more leisurely, rounded view). Yes, other definitions are available, in 1000s of books and youtube videos, but this one works well. A cursory trawl has indicated a good overlap with other good definitions (such as by Roger Martin). You will certainly want to add your own spin to it, but it is an excellent place to start. 

In essence, a strategy is “a cohesive response to an important challenge”.

As Rumelt explains, this kind of definition allows you to have multiple strategies, each focused on its own ‘important challenge’.

At its core, a strategy has 3 main parts:

1. Diagnosis: simplifies complex reality, and identifies critical aspects/risks/opportunities.
2. Guiding policy: overall approach, to cope with or overcome the obstacles/opportunities identified in the diagnosis.
3. Coherent actions: coordinated, defined steps, to carry out the guiding policy.

Most of Rumelt’s examples of “not a strategy” are missing one or more of these parts.

1. Diagnosis (and strapline)

A key term in this definition is “complex reality”. That is to say, it requires a correct understanding of what is going on outside the org, as well as what is going on inside the org. 

This is “Situational Awareness”, as described by Simon Wardley’s opening chapter about Wardley Maps (free online book, worth taking the time to read). Something often lacking and hard to achieve, relates Wardley from his own experiences as CEO. You need an understanding of all the key components affecting your org and industry, their position, context, and movement/trends. A nuanced map of the world and likely future within which the org and strategy need to operate. An explicit, shared map means more opportunities to sense-check it.

Moreover, it requires an understanding of what you have in the org. It may not be apparent that you do not have such an understanding, once the details have been filtered through multiple layers of reporting. You may overlook capabilities you do have, as well as assume capabilities you do not. Existing processes might be obscuring latent capabilities.

Beware “bike-shedding” aka “Law of triviality” (wikipedia), where it is easier to focus on the understandable aspects of the situation, rather than the not understood or harder to understand aspects.

In the strapline, the phrase “important challenge” is crucial for the same reasons. Is your situational awareness good enough to have identified the most important challenge (or opportunity)?

Choices made without actually understanding the complex reality might as well be random, and could easily be counter-productive.

2. Guiding Policy

In the absence of an explicit guiding policy, the primary risk is that anything goes. There may be  “perverse incentives” (wikipedia), that have “an unintended and undesirable result that is contrary to the intentions of its designers”.

When the project rubber hits the road, an unstated, assumed, or implicit guiding policy holds little to no sway. The realities of project and product management ensure the focus is on meeting any clearly-stated, primary metrics. The fearsome term, ‘pragmatic’, will be bandied about when making choices. [‘Pragmatic’ is a word used by folk who do know their choice is perverse, flying in the face of common sense, clearly against the greater good, but hey, they will be assessed on the official metric, so shrug. See also “tactical”]

Let’s construct some case studies, exaggerating for dramatic effect.

New directive 1: “We must increase the number of pages read per user!”

Ok, great, so then 

- Subsequent projects actively discuss how to break the larger pages into smaller pages, to spread the same useful information across more page views.

- We cancel any plans for building aggregated pages that might risk reducing the absolute number of pages viewed per user even if those aggregated pages would be far more useful and engaging to the users.

- We front load the search results with even more piecemeal results, forcing the users to step through more content before they find what they are after.

Page views per user goes up (as does user frustration). Is that what was meant?

Presumably what was actually meant was closer to: “We want to be a place users keep coming back to because we provide an engaging, informative, efficient, useful service.”

New directive 2: “We must reduce subscriber churn!”

Ok, great, so then

- Subsequent projects actively discuss ways of making it harder for a no-longer-happy subscriber to actually unsubscribe. 

- Add more hurdles, more steps in the unsubscribe process, obfusticating the UX.

- Let’s throw in some pop-unders. 

Unsubscribe numbers go down (as do subscribe numbers, but that’s officially not the point). Is that what was meant?

Presumably what was actually meant was closer to: “We want to reduce churn by becoming more of a place where subscribers stay because they trust us and value what we do - so we must truly understand our users, their needs and hopes and dreams, and use that understanding to give them good, valid reasons to stay”.

These are delightful examples of “not a strategy” where “a goal is not a strategy” (soo many citations) meets "when a measure becomes a target, it ceases to be a good measure", aka Goodhart’s Law (wikipedia, this more useful variant actually by Marilyn Strathern). 

Whenever a ‘policy’ is expressed as a metric, the original intent will be twisted and lost, at best diluted. Doing the ‘right thing’ will lose out to pragmatic choices to move the needle on the explicit, mandated measures. Teams will tend to self-censor, and simply not consider ‘for the greater good’ choices when they conflict with the primary metrics.

Have you given sufficient ammunition to folk in your company to call out and change mis-aligned business processes?

To reduce the risk of divergence from the intent, the guiding policy needs to be explicit and clear, and care taken in perversity-avoidance when selecting the primary metrics (as Coherent Actions). The policy also needs to be continually assessed for just this kind of insidious divergence.

3. Coherent Actions

The obvious key aspects of this are Actions and Coherence.

How are we actually going to tackle this? It needs concrete next steps - definite, explicit actions. What teams? What reporting lines? What business processes (to add, or remove)?

The whole should be greater than the sum of the parts. How does everything hang together, coordinated, working well together rather than despite the other projects and teams?

A strong indication of coherence can be gleaned from subsequent project prioritisation sessions. Are there big disagreements? Can they be resolved by referring to the strategy’s Coherent Actions? No? How about the Guiding Policy? No? Does the initial Diagnosis still hold?

An absolutely classic indication that all may not be well, coherence-wise, is when “We need to make this new product now” comes into conflict with “We need to fix the basics right now because we are running on fumes”.

When assessing the actions, are they solid enough, comprehensive enough, well-enough considered to base a reorg on them? In fact, why isn’t the reorg one of the actions?

Without these actions defined, things are purely hypothetical. You do not yet have a strategy.

This could be called the “Yes, that’s all very well, but what are we actually going to do?” section. It needs good foundations in parts 1 and 2, but things get only real in part 3. This is the hard bit.

Some (but by no means all) Strategy Gotchas

Don’t reorg first, then construct a strategy.

Welcome to Conway’s Law (wikipedia). 

Paraphrasing wildly, the political structure of your company, the team reporting lines, all influence the eventual technical architecture of systems and capabilities. When you reorg, you are in a very real sense making a technical decision about future systems. 

When some clarity emerges later about what the strategy might actually mean and what you actually want to do, there is every chance the pre-strategy reorg has put new obstacles in the way. Classic.

Your strategy implementation is more than likely going to become, at least in part, a damage limitation exercise to overcome the harmful consequences of the prior reorg.

The reorg should be an outcome (or part) of the strategy, not a hindrance to it.

Business Processes are the enemy

Welcome to a close relative of Conway’s Law, the pithy observation from “The Innovator’s Dilemma” by Clayton Christensen (wikipedia): “Business processes resist change”.  This is so on point, it might as well be considered an emergent property of the business universe. 

Business Processes exist, and spontaneously form, for good reasons. We want the same things to happen again, efficiently. Business processes will survive personnel changes, leadership changes, and reorgs. Business processes will slow down and more likely outright block change. 

This is a good thing.

Except, when you want things to change, when you want different kinds of decisions made. Then it very much isn’t. 

Because now, you are fighting against your own org. Without any need for overt resistance, with no particular malice involved, your new changes will crash up against the physics of the business universe, like waves against a breakwater.

Trying to force through a strategic change without factoring in changes to the existing business processes is doomed to be sub-optimal. 

The strategy needs to explicitly acknowledge and handle existing, obstructive business processes.

Everything you build becomes a burden

This is the opportunity cost that sneaks up on you and will grind you to a halt.

If each new thing you build or do is mostly or wholly new, you will soon run out of resources to do more.

What you build first stays with you the longest.

If you don’t factor in an approach to deal with this from the start, your strategy will grind to a halt, even if it is otherwise working. It is a hidden tax on an otherwise successful strategy.

… so think “Capability First”?

The simplest, long term approach to mitigating this is to minimise the cost/burden of doing new things, by striving to have (or head towards) the best portfolio of capabilities at your disposal. Be Capability first, not Product first.

Products are expressions of Capabilities, and Capabilities are built up as needed for Products. There is no additional work involved, no delays while we wait for the big slow capabilities to be developed. There will be many other Products, but there should only be a few Capabilities.

For any given number of staff, there is going to be a most effective balance of capabilities vs products, where new products and product validations are approaching zero net cost, because the capabilities are so good and relevant. 

But how to choose those capabilities? This is not trivial, especially when considered in the ubiquitous, piecemeal, some might say anti-strategic, product by product way. An early sense of where you want to be, capability-wise, can be gleaned from the superset of all the products you might want to consider. This can be identified ahead of time. 

It is almost as if good capabilities might be the essence of a good strategy? Perhaps when constructing a strategy, base it all around identifying and implementing the best possible portfolio of capabilities? More on this soon.

A Strategy Checklist

Is it “a cohesive response to an important challenge”?

Does it have these explicit, clearly stated parts: 

Diagnosis + Guiding Policy + Coherent Actions

For the Diagnosis (Why)

- Is there a good situational awareness?

- Is it explicit?

- Has the situational awareness been sense-checked by others?

- External and internal?

- Have you identified the primary challenge/opportunity?

For the Guiding Policy (How, generally)

- Is it explicit? Are all the assumptions called out?

- Is there enough of a steer for teams at the coalface to make multiple, good, low-level decisions in the heat of the moment, that are strategy-compatible?

- Is there monitoring of those decisions for signs of perverse incentives?

- Say this strategy works, and keeps on working. How is it handling the long term allocation of resources?

For the Coherent Actions (What, specifically)

- What are the next steps?

- Do they cohere well?

- Has there recently been a reorg? If so, mitigate that in the strategy.

- Which existing business processes will be impediments and need reshaping?

- Are they clear enough to drive a reorg?

- Should a reorg be one of the actions?

- Is there monitoring of the qualitative arguments during project prioritisations for signs of serious conflict?

Summary

Rumelt has given us a simple, 3-part definition of a strategy: 

“A cohesive response to an important challenge” 

= Diagnosis + Guiding Policy + Coherent Actions.

We have discussed how this definition is compatible with several notable observations of org structure and understanding, such as Conway’s and Goodhart’s Laws, The Innovator’s Dilemma, and the origin story of Wardley Maps. We have listed some specific gotchas to avoid.

Rumelt’s definition of a strategy provides a structure to consider when you might want to construct one of your own, or assess others’. We have a checklist to help with that.

A strategy should be more than just a buzzword tacked onto the title page of a slide deck to add gravitas. For sure any strategy is a gamble. You are making a bet that this is the way to go. You might be wrong right from the start. Things might change significantly and you become wrong later. But then, passively continuing with BAU is also a gamble, as is making dramatic, under-informed, unstructured decisions. These are, in effect, strategies in their own right, just probably not very good ones. 

Your (Rumelt-based) strategy is explicitly stated, with a clear, sensible, comprehensible structure, open to interrogation, criticism, iteration, and ongoing validation. 

A strategy, when crafted well, is your org’s route into the future, taking on the biggest challenge or opportunity, identifying and managing uncertainty and risk. 

Imagine such a clearly-stated strategy, printed on a single sheet of A4, for all in the org to see, critique, and align on. You can taste the synergy.

Would be a shame to waste an opportunity like that.