A technology strategy your team can actually carry

Most technology strategies are too long to remember and too abstract to act on. They are written for the meeting where they are approved, not for the hundreds of small decisions that follow. Six months later the document is still correct, and almost nothing in the organization has changed.

The test of a strategy is not whether leadership agrees with it. It is whether an engineer, a product manager or a finance partner can use it to make a better decision on an ordinary day without asking anyone.

Write it on one page

If a strategy cannot fit on a page, it is usually a list of initiatives wearing a strategy's clothes. A useful page has four parts:

• Where we are — the honest current state, including what is not working.
• Where we are going — the outcome in plain language, not a vendor or an architecture.
• Three bets — the few choices that will move us, and what we are giving up to make them.
• How we will know — the signals that tell us whether each bet is working.

Three is not magic, but it is about as many priorities as a team can hold in its head while doing everything else.

Say what you will not do

Clarity comes from the trade-offs, not the ambitions. "We will not build a custom data platform this year" is more useful than "we will become data-driven", because it tells people what to stop arguing about. Publish the no-list next to the bets.

Give every bet an owner and a quarter

Translate each bet into outcomes for the next quarter, each owned by a named person rather than a committee. Owners should be able to describe the outcome without slides and should know which decisions are theirs to make.

Review it, and delete things

Look at the strategy every quarter. Keep the bets that are working, change the ones that are not, and remove anything nobody acted on. A strategy that only grows is a wish list. The goal is not a better document. It is a team that makes better decisions without needing the document at all.