Takeaways from Good Strategy Bad Strategy

The how matters more than the what.

In the early 2000s there was a trope in the programming community about “a friend with an app idea” 1:

“Hey, you’re a programmer right?”

Yeah.

“I have a great idea for a social network - I just need someone to build it. Are you available? Split it 50/50?”

The ensuing eyeroll and punchline, of course, was that the act of building an app / social network is significantly more than 50% of the job than having an idea for one. In the immortal words of Jesse Eisenberg, “If you guys were the inventors of Facebook, you’d have invented Facebook.” Ideas are cheap, execution is everything. Obvious, right?

But Richard Rumelt, author of Good Strategy / Bad Strategy, wrote an entire book about the fact that companies often operate this way:

Executives who complain about “execution” problems have usually confused strategy with goal setting. When the “strategy” process is basically a game of setting performance goals — so much market share and so much profit, so many students graduating high school, so many visitors to the museum — then there remains a yawning gap between these ambitions and action. Strategy is about how an organization will move forward. Doing strategy is figuring out how to advance the organization’s interests. Of course, a leader can set goals and delegate to others the job of figuring out what to do. But that is not strategy. If that is how the organization runs, let’s skip the spin and be honest — call it goal setting.

To illustrate this further, I’ll include my favorite excerpt from the book: the story of Rumelt’s consultation with Chad Logan, the CEO of a graphic arts company: GSBS: Chad Logan. 2

Rumelt speaks to my core takeaway from the book in the following quote:

Many people assume that a strategy is a big-picture overall direction, divorced from any specific action. But defining strategy as broad concepts, thereby leaving out action, creates a wide chasm between “strategy” and “implementation.” If you accept this chasm, most strategy work becomes wheel spinning…

A good strategy includes a set of coherent actions. They are not “implementation” details; they are the punch in the strategy. A strategy that fails to define a variety of plausible and feasible immediate actions is missing a critical component.

Plausible and feasible actions

My two favorite words in this quote are “plausible” and “feasible.” These two conditions give the entire premise of Good Strategy its punch.

When a company wants to build a thing, there are two arenas of feasibility to consider: technical and organizational. The easier arena is technical feasibility: do we have the people, skillsets, and software/hardware to build it? I’m not saying this is easy, but it’s easier, because it can be scoped and bounded with objective facts: headcount, tooling, metrics, project breakdowns, etc.

The harder arena is organizational feasibility: do incentives align across all relevant stakeholders to prioritize this thing being built? Do the accountability structures exist to prevent teams from deviating from that alignment? Is someone able to break the ties between competing priorities? Organizational feasibility is more difficult because the barriers are less visible - blockers are due to people and political realities that are often left unspoken but nonetheless inhibit work.

Good strategy addresses both. Most strategy starts with a breakdown of work into workstreams, but that’s only the tip of the iceberg. Good strategy identifies technical and organizational blockers, acknowledges which can and cannot be resolved, and evaluates realistic alternatives in the midst of those challenges. An alternatively good ending is to conclude that workarounds are not possible and thus work should not be started in the first place.

The writers of good strategy - both ICs and managers - must be in the work enough to know the difference between implausible and plausible actions. Being in the work is absolutely critical. When you craft outcomes disconnected to lived realities you might as well be writing a wish list. And when leaders are in the work, it prevents pushing the work of overcoming these blockers down the organizational hierarchy to people and teams that increasingly lack the authority to do so. 3

The Kernel, and PTO Handoff documents

The most famous takeaway from GS/BS is “The Kernel,” or how Rumelt defines the three components of good strategy:

  1. Diagnosis
  2. Guiding Policy/Policies
  3. Coherent Actions

I’ll define The Kernel via an example of using it to create a process in real life: PTO Handoff documents.

During the earliest parts of the Covid lockdown in 2020 it was clear many of us were struggling mentally and emotionally, and I wanted to make sure my team felt like they could take necessary mental health breaks from work without the cost of dropping important work in flight. I’m happy to report that my teams still use PTO Handoff documents today.

Diagnosis

Defines the challenge. What’s holding you back from reaching your goals? A good diagnosis simplifies the often overwhelming complexity of reality down to a simpler story by identifying certain aspects of the situation as critical.

As a manager I want to ensure teammates manage their own mental health appropriately, and given work’s flexible PTO policy, take whatever PTO they need in order to do so. However, when people went on PTO the team’s output was impacted negatively, as commitments and coordinated efforts were unintentionally dropped.

Guiding Policies

An overall approach chosen to cope with or overcome the obstacles identified in the diagnosis. Like the guardrails on a highway, the guiding policy directs and constrains action in certain directions without defining exactly what shall be done.

  1. I’d like to ensure that teammates explicitly consider and communicate work in flight / work to be handed off before going on PTO.
  2. I’d like to ensure on-call rotations are handed off by those going on PTO.
  3. I don’t want creating a PTO doc to feel so overbearing that it disincentivizes their use. I don’t want the writing the document itself to feel like too much work, and I want the criteria to qualify for the doc to feel reasonable.
  4. I want discoverability of PTO documents to be easy for any remaining team members who may need to reference them.

Coherent Actions

Dictate how the guiding policy will be carried out. The actions should be coherent, meaning the use of resources, policies, and maneuvers that are undertaken should be coordinated and support each other (not fight each other, or be independent from one another).

  1. Create a PTO handoff document by duplicating and editing an existing template in a specified Google Docs folder.
  2. All PTO handoff documents follow the same naming format, meaning there’s semantic meaning to the contents of the folder and it’s easy to scan for PTO docs based on date.
  3. PTO handoff documents are required to be shared before going on PTO >= three days.

PTO Handoff Template

For the curious, the final PTO Handoff Template.

Footnotes

  1. It’s interesting that I don’t hear about this happening at all anymore. I assume it’s because coding feels significantly more democratized/accessible than it was then, and the “someone has already built an app for that” factor is so high now. 

  2. If you liked that excerpt you will enjoy the rest of the book. Rumelt really holds no punches for ideas he considers stupid, which makes an otherwise sterile topic an easy and entertaining read. 

  3. This is why I don’t believe in technical leadership that is removed from shipping work. If you are on the IC track, you must to be in the code. If you are on the management track, you must actively participate in planning and shipping projects to production. If you can’t explain the basic architectures or workflows of the systems and teams you’re leading, how do you expect to be a strong arbiter of the decisions around their future direction? 


More posts

Previous post

Don't Skip 1 on 1s

Next post

Delivering Balanced Feedback