Raw Strategic Assets

A little over a year ago I wrote my very first strategy, pulling together a diagnosis, a guiding policy and a set of coherent actions for the capacity management domain.

Now, a year later, it's obvious that we didn't achieve everything we set out to, but we did move the needle on a bunch of things and we consistently made use of the strategy when having directional conversations internally.

That sounds like a win to me.

Which is good because I'm about to do it again.

Today We March Forward Into Our Future

Unsurprisingly, a lot has changed over the last year in my little corner of Atlassian.

No business stays still for long, especially in the technology industry, so slavishly following an old and outdated strategy is generally a bad idea. At best you'll waste a bunch of time and effort achieving the wrong things, which isn't good for you, the business or the people in your area.

In our case, our old strategy isn't even invalid. In fact, it's still pretty good, it's just too narrow, because since we wrote it, we've expanded our domain and thus our scope of responsibilities.

The good news is that once you've written one strategy, it's not all that difficult to follow the same pattern to write another. It doesn't matter if you're iterating on top of your current strategy or nuking it entirely and starting from scratch, the very first thing you need to do is still the same.

Figure out who needs to be involved.

A Stronger People, A Divine People

Strategies exist in order to provide direction to a group of stakeholders.

Some of those stakeholders only care that there is a strategy and the approximate direction that it is aiming in, while others care about the intricate details for how said strategy is going to be executed.

Suffice to say, no strategy exists in a vacuum and thus no strategy should be created by a single person, regardless of how awesome that person might be.

When you embark on the journey of creating a strategy it's important to clearly identify all of the people who will care and what role they will fill in the process.

To me, there are three clear groups:

• core
• contributors
• consumers

The core group are the ones who will actually create the strategy itself, sifting through all of the raw information and ideas and distilling them down into something that everyone else can consume. They are the ones who are going to be making decisions about what the strategy actually is, and also the ones who are going to be dealing with the feedback that everyone will almost certainly have.

You should keep this group small. I find three to be a good number, because it allows you to avoid deadlocks in decision making, which, if they occur, can really drag things to a halt. I also recommend being clear about who in the core group is responsible for facilitating the creation of the strategy and who is going to provide the coherent voice for any resulting documentation.

The last thing you want is a Frankenstein document that feels like it was stitched together from a bunch of cadavers.

The second group of people are the contributors.

These people are the ones who are going to participate in any brainstorming activities for what goes into the strategy. They should have context about the domain in question and opinions about how the domain should evolve moving forward.

Beyond providing raw information, they are also the ones who will be responsible for reviewing any resulting strategy that the core group creates, offering feedback based on their own, hopefully extensive, knowledge of the situation.

The third group of people are the consumers.

These people are the ones who will actually care about the strategy for some reason and who will need to consume it, though are not expected to contribute heavily on their own.

This is, by far, the largest group, and honestly, there is probably room for further demarcation within it. For example, other leaders in the business would fit into this group, but they need different things to the people who live and work in the domain that the strategy is for.

Regardless, it's still useful identifying the major players in this group and thinking about how to communicate the strategy to them.

Of course, the content of the strategy needs to exist before you can do that, which leads nicely into my next point.

Enhanced By And For A New World

I briefly touched on it in the section above, but a good strategy is built up out of bits and pieces of information extracted from a wide variety of people, distilled down into something clear and concise by the core group.

The most common way to generate the raw thoughts ideas that go into a strategy is through brainstorming, specifically with the core and contributors groups, or a subset thereof.

Not only do you need these ideas to create a well-rounded and thus more valuable strategy, it's also important for engagement. The contributors are likely to be leaders in the domain that the strategy is for, so the more they are involved in the early stages, the more they get to have input of their own, the more likely it is that they will care about the result.

And when it comes to the eventual execution of the strategy, you'll need every advantage you can get.

When it comes to actually doing the brainstorming, I recommend doing it in a structured way, providing specific prompts that encourage people to contribute their ideas in a specific way.

Some structured brainstorming activities that are relevant to creating a strategy include:

• SWOT (Strengths, Weaknesses, Opportunities and Threats
  • This is a classic four-quadrant activity, where you get everyone to think about a specific dimension of the current domain. There is lots of information about this one online, so I'm not going to go into any more detail here
• Capabilities
  • This activity is useful if you are having a hard time drawing boundaries around your domain. You use it to clearly identify what the capabilities are that the domain provides to the business or to your users and then give them consistent names, creating a ubiquitous language
• Capability Maturity
  • This activity builds off the one above, where you analyse the maturity of each of the identified capabilities, which is then used in further brainstorming activities or in creating the diagnosis part of the strategy (i.e. a critical analysis of the current state)
• Problems & Opportunities
  • This is a more specific version of the SWOT analysis that focuses instead on just problems and opportunities that exist within the domain. Funnily enough, if you do this activity, you'll find that there is often a lot of overlap between the two categories (after all, a problem is just an opportunity to be better)
• Units of Work (aka Projects)
  • This is classic solutionising, which most people do naturally, especially engineers. This is useful for understanding what sort of change people think is necessary in the domain and complements the other brainstorming activities quite nicely, especially when used as an input into the coherent set of actions part of the strategy
• Vision Statements
  • This activity involves everyone coming up with their own grandiose statement about where they want the domain to be in a set timeframe (i.e one year, three years, five years). I've found that this is the activity that is most difficult for people, because it's basically what the strategy is intended to create anyway, but it can be useful to prompt conversation and create raw ideas all the same

Regardless of which activities you choose to run to create the raw components of the strategy, make sure you also have a structured mechanism to capture everything.

If you're physically co-located, sticky notes and a big old wall are a great way to do all of the things above, but that can be difficult to reuse later, so my own personal preference is a virtual collaboration tool like Confluence Whiteboards or Miro.

One Vision, One Purpose

Once you have the right people involved, a clear understanding of what role those people should be filling and an accumulation of raw information and ideas, it's time to put everything together to create the actual strategy.

The best way I've found to do this is to just get the core group together on a regular basis and chip away at the resulting document, which, like all good strategies, should consist of a diagnosis, a guiding policy and a set of coherent actions.

It's not trivial and involves a lot of back and forth and writing and rewriting and that's before you've even pushed it to the rest of the contributors and stakeholders for review and feedback.

Still, it's worth it though.

A coherent strategy can make all the difference when it comes to achieving the goals of the business and even if the strategy itself isn't perfect, all of the conversations that led up to it likely led to an improved shared understanding of your domain for everyone involved.

Which, like tiberium, is worth more than its weight in gold.