Strategic Launch Detected

Not so long ago, I admitted that I was not strategic enough.

I can safely say that I am now slightly more strategic than I used to be!

Because now, I've actually written and published a strategy.

Software Held Such Hope For Humanity

This isn't the first time I've tried to write a strategy. I gave it a stab a little over a year ago and failed miserably.

But, failure is the first step on the road to success, like hope is the first step on the road to disappointment. After all, it's pretty unlikely that you're going to be great at everything the first time you try, so the best thing to do is accept your initial failure, move on with your life and try again.

Which is exactly what I did. A few months back I gave it another go, with more motivation, time and support from the people around me.

I actually succeeded this time!

I'm as surprised as you are.

Obviously, I can't publish the strategy here, that would compromise all sorts of secrets. Atlassian is very Open Company, No Bullshit, but it's not quite that open.

Still, there is value in talking about how it was written. Mostly so I can remember how I did it for the next time. There's always a next time.

From a structural point of view, the strategy was aligned with the guidelines in the Good Strategy, Bad Strategy book.

That means it consisted of:

• A diagnosis
• A guiding policy
• A set of coherent actions

I think you can probably guess how I'm going to structure the rest of this blog post.

A Fresh Start, A Chance To Be Better

Creating a diagnosis for any domain requires you to do some research, or to have a huge amount of ambient knowledge and context because you've been immersed in it for a while.

I did both, but I can only really write about the research here because no-one wants me to try and summarise my time within the Capacity domain in Atlassian over the last two and a bit years.

Not in this blog post anyway. It's long enough as it is.

Anyway, the research was straightforward: talk to the major stakeholders.

In this case it took the form of a few hours of workshops, specifically oriented around identifying any problems that are currently holding us back, along with any opportunities that the business could benefit from.

The workshops went a bit further than that though, and also explored the core purpose of the Capacity domain, potential solutions to the problems and opportunities, internal domain and team relationships (i.e. dependencies in both directions) and a few other things.

With all that raw information swirling around inside my head, it was time to put pen to paper. Well, fingers to keyboard is more accurate.

At the end of the day, the first part of the strategy, the diagnosis, consisted of a short guiding statement about why the strategy was relevant now (i.e. how it fit into the greater context of the business) along with a short, sharp list of problems with the current state of affairs and potential opportunities that could be exploited to create more value.

But a diagnosis is useless by itself.

Countless Programs Were Written

Creating a guiding policy is a bit harder than the diagnosis. Or at least it was for me.

Diagnoses are mostly reflective. They require you to gather a bunch of information, digest it, and come up with some salient points about the situation.

In comparison, the guiding policy is more of a decision about what to do, with very little information about how it's going to be done. It's a high-level statement describing a direction forward, usually in the form of a vision or painted picture of what the future could look like.

Funnily enough, some people start with the guiding policy, having already subconsciously created a diagnosis. Don't do this, as it makes it harder to get people onboard with the strategy. Do the diagnosis first to create a shared understanding of the need, and the guiding policy second.

If you've done it right, the policy can be summarised in a few sentences. Short enough to be remembered, long enough to allow the reader to really visualise what that potential future is going to look like, how it's going to impact them and why they should care.

In the case of the strategy that I just finished writing; the guiding policy was pretty straightforward: it was all about a future where Capacity Management was available to any service in Atlassian that wanted it.

It also went into detail about some of the capabilities that such a platform would offer, along with the principles that it would be built on top of.

Also, it had at least one picture. Everyone loves pictures, especially the visual thinkers who need them in order to really understand what is going on.

It really is a shame I can't share the guiding policy here, as I think it was probably the best part of the strategy. It really struck the right balance between abstraction and detail.

Ah well.

A great diagnosis and guiding policy is all well and good, but it's meaningless if you stop there.

Governed By Sound Patterns and Principles

A set of coherent actions is the last element of a good strategy. The first two elements are focused on context and direction respectively, but the last one is all about explaining how you're going to do things.

And that means a roadmap of some sort.

Because strategies are written early in the process, in order to align people and get endorsement for the path forward, you won't have a fully fleshed out roadmap.

You wouldn't want one either.

That would be like creating all of the tickets in a backlog for a project right at the start; it's a waste to do all that work when you are the least informed that you will ever be.

Instead, you should focus on having a pretty good idea of what's next, some idea of what comes after that and a sort of vague and fuzzy outline about what comes after that.

That means the set of coherent actions consists of milestones or key pieces of work distributed across three horizons:

• soon
• later
• much later

Depending on how confident you are in your breakdown of the work required, you might even be able to attach some sense of timeframes to those horizons as well. Maybe soon means months or quarters and much later is years. It's up to you to understand what your audience needs.

For example, there were no times attached to any of the actions the strategy I wrote, it was pure sequence. I had no idea when we were going to be able to deliver any of those stepping stones.

Finally, be aware that your set of coherent actions is probably going to be wrong. As I alluded to above, if you create a plan right at the start, you're literally doing it at the time when you have the least possible information.

You'll learn more as you move forward. As you try, succeed, fail, and adapt to the ever-shifting and unforgiving nature of reality.

In other words, don't get too attached to your set of actions.

Thus, A Golden Age Began

And that's that. I actually wrote a strategy, people read it and they were generally on board with the diagnosis, the guiding policy and the set of coherent actions that it presented.

I mean, after giving a tonne of feedback about why it was wrong and how it needed to be changed.

Which is very pertinent and something you need to wrap your head around right from the start.

You don't write a strategy alone.

I didn't write a strategy alone.

It involved my entire leadership team, a group that is seven people strong and consists of fellow engineering managers, principle engineers, a head of engineering and a principal architect.

I may have written a lot of words, but they read them all, critiqued them furiously, proposed improvements, and had just as much part in the creation of the end result as I did.

But even ignoring participation of others for a moment, the creation of a strategy is also an intensely iterative process. Even if you were doing it alone you'd still want to go over it again and again.

You won't get it right the first time.

And that's okay. Change is good. Especially when it comes from feedback, because it means people are engaged and interested and the more of their thoughts you take into account, the more persuasive the end result is going to be.

Of course, now that I'm done, all I need to do is execute it.

That's the easy part.

Right?