If You Can't Draw Your Technical Strategy on One Page, You Don't Have One

Tuesday afternoon, about three o'clock, a whiteboard in a room with no windows. I asked our lead architect to draw the target state so I could understand it. Forty minutes later the board was full, he was pleased, and I could not have told you what we were building or why.

He was not a bad architect. He was one of the best I have worked with. He just did not have a strategy. He had a very detailed picture of a destination, which is a different thing, and the gap between those two nearly cost us a year.

People hear "one page" and assume it is about communication. Making it digestible for executives. Something to put in a pack.

It isn't. The one page is a diagnostic, and the diagnosis is usually uncomfortable. When you sit down to draw the whole direction on a single sheet and find you can't, it is almost never because the thinking is too sophisticated for the format. It is because there are two competing directions in the team and nobody has picked one. Or because there is a decision you have been avoiding for five weeks and every version of the page runs into it.

That is the value. The page finds the hole. A 60-slide deck lets you walk straight past the hole for months, because there is always another slide and the meeting always ends.

Four things, and there is no fifth.

The target state, drawn, not described. Boxes and lines that a competent engineer who has never met your project could look at and roughly understand.

The constraints, written as specific facts rather than as sentiment. Not "limited budget" but "no additional headcount until the next financial year, capital already committed, and the current support contract ends in March". Constraints are the part most teams leave off, and they are the part that makes the rest of the page believable. A strategy that ignores its constraints is a wish with a diagram attached.

The sequence. What gets done first, second, third, and crucially what has to be true before each one starts. This is where most one-pagers turn out to be fiction, because the sequence exposes that step two depends on a team who have not been asked yet.

The non-goals. The things you have consciously decided not to do in this phase, with a line of reasoning next to each. Non-goals are the single most useful thing you can hand to an engineer, because they end the quiet arguments that otherwise run for months in pull requests.

Owner names on every box. If a box has no name under it, you have not finished.

A mid-size logistics operator, an ageing order management platform, roughly 30 engineers across four teams, and a rebuild that had been discussed for two years and started three times.

We spent two days getting it onto one page. The first day was awful. Every attempt fell apart because two of the four teams had genuinely different ideas about whether the existing database was being kept, and nobody had ever put those two ideas in the same room. Two years of parallel design work, both perfectly reasonable, both funded.

The version that survived had four boxes, three constraints, one sequence line with four steps on it, and five non-goals. One of the non-goals was "we are not replacing the reporting stack in this phase, even though it is the thing everyone complains about", with the reason underneath. That single line stopped an argument that had been recurring in planning meetings since the previous summer.

The database question got decided, by the way. Keep it for 18 months, then reassess against two named trigger conditions. Not the elegant answer. The one we could resource.

Here is the part that gets skipped by almost every technical leader I have coached, and I skipped it myself for years.

Drawing the page is maybe a third of the work. The rest is getting it into other people's heads, and that does not happen by attaching it to an email or presenting it once at a town hall where 40 people are half looking at their laptops.

Do it in ones and twos. Twenty minutes each, sitting next to the person. Walk them through it, then stop talking and ask them to explain it back to you. What you are listening for is not agreement. You are listening for whether the version in their head matches the version on the page, and it usually doesn't, and the places where it doesn't are the places where your page is wrong or unclear.

I aim to do this with everyone who makes technical decisions on the work, plus the sponsor, plus the one sceptic who thinks the whole thing is misguided. The sceptic is the most valuable half hour you will spend. They have been rehearsing their objections for weeks and they will hand you the weakest part of your thinking for free.

Then keep the page alive. Date it, version it, and put a recurring review on it, monthly on something that runs for a year. When reality contradicts the page, change the page. A strategy document that has not been edited in six months is not stable, it is abandoned, and everyone on the team knows it apart from the person who wrote it.

Block 90 minutes, on your own, with paper. Not a slide tool, it will make you write bullet points instead of thinking.

Draw the target state, write the constraints as facts, write the sequence, write the non-goals, and put a name under every box. When you hit the thing you can't draw, that is the decision you have been avoiding, and it is now the most important item on your list.

Then book twenty minutes with the person on your team most likely to tell you it's wrong, and ask them to break it.