“We must therefore be prepared to cope – even better, to thrive – in an environment of chaos, uncertainty, constant change, and friction”
Those who work in startups will recognize the tone from blogposts and books spewed by startup mecca, Silicon Valley.
“In practical terms, this means that we must not strive for certainty before we act, for in so doing we will surrender the initiative and pass up opportunities”
This isn’t Reid Hoffman or Paul Graham. These quotes are taken from the US Marines’ primary doctrine, a 70-pager called simply Warfighting, by General Alfred Gray. There’s actually a free online version too.
This post is about the analogies between the approach to war advocated in Warfighting and my experience of startups.1
Startup conditions resemble war
Warfighting begins with a characterization of war, as it stood in 1989 when the book was written. Gray identifies three key features:
- Uncertainty: things are unclear
- Fluidity: things keep changing
- Disorder: things keep happening
These combine to produce friction: in the words of Clausewitz (the OG of this genre), this is “the force that makes the apparently easy so difficult”.
I don’t think it’s really necessary to hammer home that these are also salient features of (at least my) startup experiences.
To be effective, startups must adopt “maneuver warfare”
The central doctrine Gray advocates is that of maneuver warfare, which is best defined in opposition to attrition warfare.
In attrition warfare, you throw an enormous amount of resources straight at the enemy, in the hope of overwhelming them or eliminating their will to keep fighting. The best example is trench warfare: you get a bunch of guys to dig holes in the ground and they shoot at each other until somebody goes home.
By contrast, maneuver warfare involves concentrating your resources, swiftly, upon some weakness you’ve identified in your enemy. The most famous example of this is the German Blitzkrieg at the start of WWII. The French spent a long time building a big wall (The Maginot Line). The Germans went round it and took France in a month. Once they’d punched holes through weakpoints in the defense by the application of intense force at specific locations, it was easy to hoover up the fragmented and encircled units that remained.
Clearly, a startup – by definition a small, low-resource unit – cannot hope to win by attrition warfare. We cannot throw people and software at problems. Trying to beat Google at everything Google does is a bad idea.
Startups must instead find the weak points in the market – which stem from the needs of their customers – where they can apply their force maximally, in the hope of a breakthrough. I think the term ‘product-market fit’ describes exactly this.
To achieve product-market fit, it’s necessary to really understand the needs of the customer. Similarly, Gray points out that you can’t execute maneuver warfare without deeply understanding the enemy:
“It is essential that we understand the enemy on his own terms. We should not assume that every enemy thinks as we do, fights as we do, or has the same values or objectives”
Hence: in a limited sense, the customer is the enemy. To understand what you can build that will actually sell, you need to understand the way your customers do things, and the weakpoints in those process.
Organizing for maneuver warfare
The most striking part of the book is Gray’s description of the organization requirements for manouveur warfare, which reads like a blueprint for optimizing your company for agile product development.2.
Because we’re going to rely upon spotting opportunities and seizing them, things are going to move too fast for centralized leadership. Instead, we’re going to have to distribute decision-making to the ground level.
But as Gray points out, this can be tricky in practice, because you risk your organization fracturing into independent units. Blending decentralized decision-making with unity of purpose is, in my experience, one of the greatest challenges of a rapidly-growing startup.
Gray identifies the following ingredients of a successful decentralized strategy:
1. Clearly defined objectives
“The first requirement is to establish what we want to accomplish, why, and how. Without a clearly identified concept and intent, the necessary unity of effort is inconceivable”
Gray proposes leaving individuals to figure out how to solve problems (what he calls ‘mission tactics’: “the tactics of assigning a subordinate mission without specifying how the mission must be accomplished”). In order for this to be effective, the indiviual decision-makers need clarity about the intent of their commander: the why of the mission.
You can see the same logic in writing ‘user stories’ to define tasks for development teams – often the person defining the task doesn’t seem to describe how it will be completed, but to describe why it’s a useful thing to do 3. At a higher level, this is why companies spend time honing “North Star” visions.
2. Camaraderie & trust
“Our philosophy also requires familiarity amongst comrades because only through a shared understanding can we develop the implicit communication necessary for unity of effort”
Startups often develop fiercely insular, all-consuming cultures. Steve Jobs famously isolated the team creating the Macintosh and hoisted a pirate-flag to articulate their tribal status. A shared understanding allows you to distribute decision-making more effectively.
Note, however, that this is a little in tension with the desire of inclusivity and diversity in the workplace, a struggle that the military is also experiencing. It’s also difficult to sustain this trust in the face of extreme growth: it’s difficult for people to get to know each other if there are 20 new employees every month.
3. A culture of distributed leadership
“A centralized system theoretically needs only one competent person, the senior commander… a decentralized system requires leaders at all levels to demonstrate sound and timely judgement”
This might be why generalists tend to gravitate towards startups, and succeed there. In highly hierarchical organizations, the lower echelons can afford to be extremely specialized for completing whatever task they’re assigned.
An effective startup employee cannot afford to delegate all of that decision-making to their superior, because things are changing extremely fast (we’re at war, remember) and even the most junior engineer will often be better-placed to make a call than their manager.
4. The freedom to make mistakes
Swift, decisive decision making is critical to the success of maneuveur tactics, because opportunities to exploit weakness are often fleeting:
“Whoever can and does make his decisions faster gains a tremendous, often decisive, advantage”
Which echoes the pithier George Patton:
“A good plan violently executed now is better than a perfect plan executed next week”.
For people to make bold decisions, we need to create an environment in which bold decisions under time-pressure and uncertainty are encouraged. To quote at length:
“We must realize that errors by junior leaders stemming from overboldness are a necessary part of learning. We should deal with such errors leniently; there must be no “zero defects” mentality. Not only must we not stifle boldness or initiative, we must continue to encourage both traits in spite of mistakes. On the other hand, we should deal severely with errors of inaction or timidity. We will not accept lack of orders as justification for inaction; it is each Marine’s duty to take initiative as the situation demands.”
This is echoed in the centrality of psychological safety in modern agile; the “move fast, break things” attitude espoused by the Zuckerberg’s of this world, and the oft-repeated moniker that it’s “better to ask for forgiveness than wait for permission”.
Caveats
To bring us back from the clickbaitism I’ve been flirting with, I’ll close with some caveats.
The first is that clearly startups do not resemble the horror of war. You may have to drink some disgusting meal-replacement shake, but that’s usually optional. We’re usually playing with VC money rather than lives.
The second is that the analogy I’ve drawn between the customer and the enemy is imperfect. Clearly you and the customer are actually both interested in the same thing – making more money – and you’re trying to come to a solution together which achieves this.
However, the more intuitive idea that your competitors are your enemy is, I think, misleading, because it incorrectly implies that startups should be obsessing about their competition. Just as knowing your enemy is the most important thing in war, knowing your customer is the most important thing in business – not knowing the other guy who wants to serve your customer.
A final subtlety is that Gray’s doctrine of distributed decision-making partly rests upon the notion that the people on the ‘front line’ are best placed to take decisions. This makes sense, because the guys who are trying to shoot stuff are in a good position to decide how best to shoot stuff.
This is only partly true in startups, because there are several front lines. Most obviously, the people making things and the people selling things are usually different gangs. That’s a bit like commanding an artillery unit: you’ve got somebody with some binoculars who can identify what you should shoot at, and another group of guys who actually understand how to work the gun.
In my experience, the guys who do the aiming often want you to shoot something that’s outside of the range of your gun, and the guys who fire and maintain the gun are interested in making the gun simpler and break down less often. I’m sure the conflicts between the culture and the interest of customer-facing and tech-facing groups underscore the failures of many startups.
Conclusion
You should go and read Warfighting if you appreciate lucid writing about winning wars and running startups. It’s really very good and, unlike this blogpost, very short.
Footnotes
- I know it’s a cliché for testosterone-filled brogrammers and steely-eyed MBAs to characterize business as war, usually for the purposes of justifying doing horrendous things to one another and/or working 100 hour weeks. In my defense, I stumbled upon this book because is was mentioned in the introduction to one of my favourite sci-fi novels, Ender’s Game. Although my intention was not to recast my job writing code as Operation Overlord, the parallels are irresistible.
- “Agile methodologies” are dominant in startup-land: they refer to processes which allow quick iteration and delivery of crude products to make sure you’r building something useful
- A user story is a way of describing a product requirement from the user’s perspective. It usually goes “As a user, I would like X when doing Y”