I wrote recently about how a Strategic Architectural Initiative (SAI) helps align autonomous teams around a technical strategy. In this post we’ll look in detail at how to create an SAI, and how to ensure it’s widely understood.

Building a Strategic Architectural Initiative

As discussed in my previous post, a good technical strategy is one formed to help achieve a business goal. The next step is to clearly define that strategy, as a Strategic Architectural Initiative.

The way we create a strategy is as critical to its success as the strategy itself. A strategy created in collaboration with the teams that will be carrying it out gains much from their insight and observations. A co-created strategy is also much more likely to be embraced by folks on the ground, who’ll take it and make it their own. Kicking off an SAI by spending a few hours with a handful of senior engineers that represent a reasonable cross-section of the teams that’ll be involved in the SAI is a very sound investment.

Start with Current State

When co-creating an SAI with a group, I like to start by getting everyone aligned on the Current State. I use workshop-y exercises like Anchors & Engines to engage everyone in the group in sharing their perspective of the current state of affairs. Participants are often surprised by what they learn about other team’s realities!

For example, as a Chief Architect I might gather the tech leads for all the engineering teams and asked them to describe the current deployment process in terms of where it’s helping them succeed, and where it’s holding them back. Everyone writes their items on sticky notes and puts them up on a wall. Then we cluster everyone’s observations into themes, and talk through these themes to boil them down into a summarized statement describing the Current State of the deployment process.

Brainstorm on Target State

A good Target State has a lot of the qualities of a Big Hairy Audacious Goal. It’s an ambitious, easily-understandable goal, with clear differences from the Current State. A Target State should also have objective success criteria - a well-defined “finish line” for teams to run toward.

We can start by revisiting the business goal that we’re supporting with this technical strategy: we want to aggressively accelerate our deployment tempo, so we need to automate and streamline our deployment processes. Given that, and our newly formed view of our Current State, our group of tech leads works together to brainstorm a Target State, with a senior leader (our Chief Architect or our CTO) providing guidance, and veto authority if needed. For example, our group might come to the conclusion that to we need to consolidate our deployment processes to a single “Paved Road”, which enables engineeers to perform most production deployments with a “single click” and no manual processes.

Define some Next Steps

The last part is usually the easiest - given our freshly-formed understanding of our Current State, how are we going to start making progress toward the Target State that the group just defined?

The group should define two or three chunks of work that can be started today by different teams to help move towards that Target State. Ideally, these first tasks also help to reinforce understanding of Current State and Target State - as we saw earlier, some people find a strategic goal easier to understand when it’s couched in terms of concrete tactical action.

The creation of these Next Steps of work is a good gut check on the quality of the Current State and Target State that you just created. If the group that just defined these are struggling to agree on Next Steps then it’s likely that the rest of the engineering org will likewise struggle to make coherent progress on this strategy. It’s perfectly acceptable for the group to go back and revisit the definition of Current State or Target State in this situation.

Socializing your strategy

It’s really sad when leadership develops a strong strategy, but few people on the ground understand it, meaning that little concrete progress is made. What’s even sadder is that this is not uncommon - studies show that many leaders struggle to share their vision in a way that draws others in.

To avoid this tragedy, leaders must work hard to share a SAI broadly once a core team has defined it. Hope is not a strategy here - getting all the elements of an SAI into everyone’s awareness requires sustained, intentional effort.

Over-sharing

I’ve found that the best approach is over-sharing. Find every avenue and opportunity you can to share SAI, and share it in different ways. Tech leads who helped create the SAI should share it with their team in standup, as well as covering it in more detail during planning discussions. The Chief Architect could describe it briefly in the next company all-hands. The CTO could present it at the next product management meeting. Create a visual representation of the strategy and post it somewhere highly visible in the office.

Share in different ways

Speaking of visuals, it’s also good to find different ways to describe the SAI. Some people are naturally visual, some prefer long-form prose, while others prefer to learn about things through interactive dialog. You should come up with ways to communicate the SAI that fit all those modes. A long-form wiki page describing the details. An architecture diagram that show Current State and Target State. A lunch-and-learn with the CTO for anyone who wants to learn more. A short, catchy phrase that encapsulates the initiative.

Keep reminding people

I once worked with a VP of Engineering who put his engineering org’s mission statement on the first slide of every single presentation he gave. It worked - almost every engineer knew what the mission was, as did most of the engineering org’s stakeholders.

Once you have developed useful media for sharing your initiative - a catchy phrase, a concise diagram, and so on - keep using them, consistently, over and over again. I’ve even heard of having different members of a team draw out the same diagram ever time it’s needed, as a way to get that model internalized.

Sharing an SAI is not a one-and-done endeavor. It’s important to keep revisiting the initiative with people over time, both to share progress and to keep reminding everyone of those three elements. However, you should also expect to iterate on those elements somewhat.

Iterating on a strategy

Any good strategy evolves over time. Our understanding of the situation improves, and the situation itself changes. Given that, the right thing to do is to regularly assess how our SAI is progressing, and make course corrections if necessary. The core team which first created the SAI should reconvene to reflect on what progress has been made, and if anything has changed externally that might affect the broader goals served by the SAI - perhaps a change in broader business strategy makes the initiative less valuable, or a recent acquisition makes it more pressing. The team should look together at progress from the previous Current State, as well as re-confirming that the Target State still aligns with our broader objective.

After reflecting on what’s changed, the team might decide to make some adjustments to the SAI’s Target State. If things are progressing well, the team will certainly want to update the Current State (since progress has been made here!) They’ll also want to identify a new set of Next Steps which drive further progress towards the SAI’s Target State.

Guided grassroots initiatives

The way to actually deliver significant technical improvements is to engage directly with the folks working “at the code face”. Co-creating Strategic Architectural Initiatives with team leads ensures that they deeply understand the work, and feel empowered to iterate on the approach as new facts emerge. Put intentional effort into sharing the SAI broadly once it’s defined, using different media for different audiences, to get maximum value from it.

While I’m a big fan of the SAI approach, I’m also really interested in learning what else people are doing to drive technical strategy in their engineering orgs. If you’re applying similar ideas, or have an alternative approach, please get in touch and tell me all about it!