I recently read Will Larson’s post on engineering strategy, and I admit – something funny happened. For the first time, I disagreed with him. This is missing a lot of components of good strategy, I thought. This is limited to organizational strategy of the engineering org. Before I go on, I want to insert: I think very highly of Will Larson. His posts make you think. So, it is to be expected that fans may sometimes disagree! And that’s all this is.
OK, I will stop with the praise and the gushing, because now for the rest of this post, I am going to poke holes in his example strategy. While I don’t agree with Will’s example strategy, I did get an amazing book recommendation from that post – Good Strategy/Bad Strategy by Richard Rumelt. Yes, Will follows the instructions from this book (emphasis mine):
The kernel of a strategy contains three elements: A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical. A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis. A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.
However, I argue the example given is weak in the diagnosis and set of coherent actions department. Before we can dig into that, I’d like to take a step back and not assume everyone has read Good Strategy/Bad Strategy or heck, even agrees with it. Then we can dive in with additional detail on writing a good strategy.
First: Knock it off with the “fluff”
It is sad this section is needed first, but it is. Just open LinkedIn – seriously, do it. I bet it’ll take no longer than five seconds to stumble upon a post with the word “strategy” in it. And I bet you’ll read it and go –
If that’s your reaction – good. The post in question is probably nothing but fluff – and that’s the first sign of bad strategy. If you want an example, here’s a recent one I stumbled upon. I will summarize it as “just do these 10 easy steps and you’ll define everything you need for your entire company” 🤦♂️! I admit, this line from Good Strategy/Bad Strategy hits home:
A hallmark of true expertise and insight is making a complex subject understandable. A hallmark of mediocrity and bad strategy is unnecessary complexity—a flurry of fluff masking an absence of substance.
Here’s a good rule of thumb: if you need more than one sentence to describe what a strategy is, you’re doing it wrong.
What strategy is
As always, let’s head on over to Merriam Webster and take a look:
a: a careful plan or method : a clever stratagem
b: the art of devising or employing plans or stratagems toward a goal
“a careful plan or method” – only five words! That wasn’t so hard, was it?
This definition rules out a lot. A strategy isn’t just a mental framework. For example, “work smarter, not harder” or “believe in yourself” are not strategies. Neither are goals or objectives a strategy (and this is what I argue the “strategy” in my example LinkedIn post above is). For example, “increase revenue by 300% in three years” is not a strategy. Everyone’s goal is to win; every for-profit company has a goal to increase revenue and profits. Rather, a strategy is how you win. Richard puts it well in his book:
Despite the roar of voices wanting to equate strategy with ambition, leadership, “vision,” planning, or the economic logic of competition, strategy is none of these. The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing actions to deal with those factors.
…
A good strategy does more than urge us forward toward a goal or vision. A good strategy honestly acknowledges the challenges being faced and provides an approach to overcoming them.
If you play any strategy games, this may feel obvious to you. Real-time Strategy (RTS) games like StarCraft, 4x games like Civilization, or table top games like Warhammer (40K) are all strategy games. The objective of these games is to win. But how you win, well, there are many strategies to do so. And if your strategy is “Do aLL tHe tHiNgS!!1,” well, a generalists’ strategy is a strategy, but rarely is it a winning strategy. No, the hard part about a winning strategy is that it isn’t all the things. You must make sacrifices and trade-offs. And this – this hard part – is why there are so many “not strategies called strategy” out there. Nobody wants to make the tough calls.
So what’s wrong with Will’s post?
And this is where I take umbrage with Will’s post about strategy – what are the challenges being solved? What are the tough calls being made? He provides four bullets for his “diagnosis,” but only the second two are challenges being faced. For example, he mentions supporting three business lines, but he doesn’t mention what the challenges are for those business lines in order to achieve the forecasted growth. Nowhere does it mention how the tech stack will have to evolve to support this growth. Will new systems need to be created? Will some systems need to evolve into platforms to support multiple business lines in a multi-tenant fashion? The list of questions is endless.
But the reason for this gap becomes obvious further in the article, when you see his Venn diagram that has product strategy and engineering strategy completely separate. I already made 
my opinion clear that I believe in integration over functional isolation, so it should come as no surprise that I believe there should be some bleed-over between the two here.
It can make sense to have separate product vs engineering strategies, but if the two aren’t connected, there will be a never-ending game of tug-of-war. For example, if the product strategy is to build native mobile for customer usability reasons, then the engineering strategy needs to take this into account. You can’t just have backend developers, but you need iOS and Android developers as well. Perhaps your company is already staffed in this manner, but if it isn’t, this may be one of the top challenges your engineering strategy needs to overcome. Does every team need to now add mobile developers? Is there a standard expected ratio of mobile developers for a team? Rather than budget net-new headcount, do we need to convert backend developer budget to support this new function? Will this function report directly into existing engineering teams, or will it require its own dedicated manager? While this is but one example, there are lots of questions and problems to solve by connecting the engineering and product strategy.
When reading about the intersection of Design, Product, and Engineering strategy, you usually come across this trichotomy: Desirability (Design), Viability (Product), and Feasibility (Engineering).1 While cute, I argue this is the fluff we must avoid, as we can come up with a lot of other abilities that are missing from this list. What about usability? Does that fall under desirability? Is desirability limited to design only? What if we’re 10x cheaper than our main competitor – that has nothing to do with design, but it sure makes us desirable! And isn’t the ability to survive – viability – dependent on the scalability of our systems? As in, that falls under engineering, not product, right? The point is, you can argue in circles across these false boundaries all day long.
The reality is, your strategy needs to balance these things appropriately. Of course your strategy must be feasible – if it isn’t, it’s a bad strategy. And if it can’t survive after launch (viability), it’s also a bad strategy. And if it won’t have any users (desirability), guess what? Yup – it’s a bad strategy. Good strategy must take this all into account, and Will’s example is simply too light on the details to know if it’s a good strategy or bad strategy.
Don’t worry – my company “gets it.” We do “strategic planning.”
And here I must insert yet another “oh boy” moment. Honestly, go watch this Harvard Business Review (HBR) video (and thanks to Federico Chapa for sharing this with me a while back):
If you watch this, you’ll notice some challenging things. First, it changes the definition of a strategy from Merriam Webster’s above. After all, it must in order to disambiguate between a strategy and a plan, given the word “plan” is in the definition of strategy above! Let’s take a look at the definition of the word plan:
a: a method for achieving an end
b: an orderly arrangement of parts of an overall design or objective
At least this makes it is clear that a strategy and a plan are two separate things. Yes, a strategy should be executed against. Meaning, it should have a plan (or set of plans), but they are still separate things. While a strategy must share how challenges are overcome, it does not say when. It does not list every line-item of needed work broken out, give a priority and order to the line items, and say who is responsible for each line item. A strategy doesn’t have a Gantt chart or a red/yellow/green status. Most importantly, a strategy is a hypothesis (or theory), that if you do x, y will happen. A plan is a list of items to say “this is what doing x means.”
From a pure etymological standpoint, I argue “strategic planning” can exist – as in, developing the detailed plan to achieve the company strategy – the problem is just that in practice, it usually takes a flawed approach. The video says it well:
[planning] tends to be a list that has no internal coherence and no specification of a way that that is going to accomplish collectively some goal for the company.
In my experience, this statement holds true. My belief here should come as no surprise given my recent post about quarterly planning (and why you should stop doing it). Put another way, strategy is top-down, but planning is bottom-up. Additionally, a strategy usually interrupts an existing planning process done on a regular cadence, thus disrupting in-flight plans and causing tension between the two. This conflict leads to a common outcome: bottom-up planning rarely meeting the needs of a top-down strategy. However, I argue this is avoidable. After all, you have to execute on a strategy for it to be successful!
So how do I make a good strategy and then execute against it?
Ah, yes – the secret sauce. I wish I could tell you “follow these simple steps for a good strategy,” but that would be a lie. The reality is a good company strategy requires the following hard steps. Skip any one of these steps, and your strategy is likely doomed to fail from the start. So, be ready to do some work!
- Get complete buy-in from the top. Strategy can be informed and/or produced by individuals of all levels, but it must be backed by company leaders. This is where Will and I are in complete agreement: a strategy is fundamentally top-down. Not all strategies need to be at the company-level, however, so define “the top” for your situation.
- Have an operating model to execute on the strategy. Do you need to change your organizational structure at all? Appoint a single-threaded leader for the strategy to ensure prioritization of it in your existing planning processes? A strategy is only useful if executed against; be sure your strategy will be executed against, even if it means changes to your existing planning processes and/or operating model.
- Have interdisciplinary contribution. Your strategy better be feasible, and viable, and desirable, etc. to have the highest chance of success. This requires interdisciplinary thinking. You can have product strategy and engineering strategy produced separately, but the overall strategy must make sense with these separate artifacts together. Thus, these separate functional strategies cannot be produced in isolation; they should explicitly link to one another as necessary. However, it is recommended to instead have one overall strategy artifact to serve as the source of truth. This source of truth can then leverage these disparate, more detailed artifacts as necessary.
- Make the painful decisions. Your strategy isn’t just a list of all of your company projects. While you want company-wide buy-in, it is an anti-goal to try and make every employee happy with a strategy. Face these challenges head-on as part of your strategy definition. It is recommended you explicitly include these decisions in your strategy artifact to minimize “what about x?” questions in response to the strategy. For a good read on a process for this, see this post about the anti-roadmap.
- Be known and understood by everyone in its scope. If your strategy isn’t shared and understood, it is not going to succeed. In order for employees to execute against a strategy, they must understand it. Even better, you want your strategy to motivate your employees, not be something that must be overcome. The interdisciplinary approach above should help achieve this step.
- Be comfortable with evolution. As you execute against your strategy, you are going to learn; embrace this! Plan on updating your strategy as you learn. These changes can be big or small and do not need to be made on any regular cadence. However, if you let your documented strategy atrophy yet continue to insist you execute against it, it will likely become more of an obstacle than a useful tool.
If you do all of this, then you can start planning to execute against the strategy. And yes, perhaps you can even call this “strategic planning” 😅.
Appendix: Good External Resources
- What Makes a Strategy Great – A post on A Smart Bear that is well worth the read!
- Product Strategy Overview – One of many posts by Marty Cagan of Silicon Valley Product Group (SVPG) about strategy. This one is my favorite, but check out his others too!
- The goal of a “strategy” is to change our own team’s behavior – This one is all in the title!
- This is the only Strategy Framework you need – This one is also in the title, but there is more to it than just a discussion of a strategy framework.
3 Comments
Leave your reply.