Continuously Integrated Strategy

Here’s a possibly useful analogy when talking about strategy work with engineering leads. 

It is considered a poor practice to write code without testing. No matter how brilliant we are as engineers, the bugs we produce will sooner or later have to be addressed. There’s even a practice of continuous integration, which encourages that every change, no matter how small, is to be tested as part of being accepted into the shared code repository. As engineers, we write code all the time – and continuous integration helps us account for all the intended and unintended behavior changes we cause while doing so.

Somehow, these amazing ideas don’t seem to extend to strategy. In the same engineering organizations, we appear stuck somewhere at the late stage of the waterfall model. There are annual cycles of strategic planning that march forward for a few months, culminating with docs and slide decks that inform organization’s leaders on where to focus and what investments to prioritize. Don’t get me wrong – these are often useful exercises. I remember the first earnest SWOT analysis I’ve gone through with my colleagues and the (alarming) clarity it brought. However, don’t they seem a bit like a throwback to the early days of software engineering? You know, the time when we still believed that we can ship perfect software if we just planned it hard enough?

Putting it somewhat bluntly, the brief annual focus on strategy feels awfully similar to New Year’s resolutions – all but forgotten by mid-January. Worse yet, the annual cycle naturally confines the perspective. Why think a few years forward when we’ll be doing this again next year? And who has the time? So, our strategic foresight ends up being crimped to a year – if that.

Lastly, the environment around us rarely stays in place. Even though our intentions may remain firm, how we see problems ahead of us changes all the time. When we sketch out our first draft of strategy, we actually know very little. Every step we take teaches us new things, and potentially – no, definitely – affects how we approach the situation. Just like in writing code, every action we take contains unexpected side effects. If we only account for them once a year, our strategies are unlikely to be useful. They aren’t just limited in time – they are also frozen in it. So we engineers just whiff on strategy work. Why waste any more time than absolutely necessary on a useless artifact? No wonder strategic planning exercises are usually just planning.

Perhaps we could choose to do something different? What if, borrowing from our well-learned engineering tricks, we reframed strategy as something that is practiced continuously, and developed a habit for that? Strategy is like writing code. It’s just a guess that mutates as soon as it begins interacting with reality. Why not give our strategy the same respect that we give to our code? What might a continuously integrated strategy look like?

These are the questions I am looking to answer. Take the same SWOT analysis as an example. I am playing with the idea of a “SWOT garden”, where SWOT is no longer something we do as a one-time thing, but rather keep updating as we recognize new threats, opportunities, weaknesses, or strengths. SWOT gardens live and are cultivated. When a new threat is encountered, we add it to the matrix and check to see how it fits with other threats, and reframe them as necessary. We also evaluate to see if the newest addition sheds light on other bits: what are our strengths and weaknesses that make up a threat? What are the opportunities that might exist alongside it? 

I hope the SWOT garden concept makes sense. As a benefit, we get to have a continuously improving picture of the key challenges that our organization faces. And once we understand these challenges, we are in a much better position to make proper diagnosis, which will in turn help us iterate on our guiding policies and coherent sets of actions that follow.