When technical strategy lives in hallway talk, everyone rebuilds their own version: the team decides one way, product another, and the board gets a summary with no trade-off in it. A one-page document fixes part of that because it forces a written decision and fits any meeting. Below is the format I use with CTOs and staff engineers in consulting engagements, with four sections and a review ritual.
Start with the deadline and the money
Five lines of context and constraint. State which real constraint the document serves: revenue stuck on a platform limit, an acquisition deadline, infrastructure cost rising faster than revenue. Simon Wardley, in Wardley Maps (2020), insists that strategy without constraint turns into a wish list. Five lines are enough for anyone on the board to grasp the problem without reading a line of code.
The decision in two lines, in the second paragraph
One decision per one-pager. Write the decision, the date it takes effect and who owns it. Brad Stone documents in The Everything Store (Little, Brown, 2013) that Jeff Bezos required six-page memoranda because slides hide reasoning; the one-pager plays the same role in a single page. If the document holds two decisions, split it into two documents.
Rejected alternatives, one sentence each
Three options, the reason, and the evidence that settled it. This is the first section the board asks about, and having it written saves twenty minutes of defensive meeting time. Will Larson, in Staff Engineer (O'Reilly, 2021), treats written reasoning as the main instrument of influence for someone with no formal authority to order anything.
90 days of delivery and a review point
Three to five deliverables with an owner and one signal metric: latency, cost per request or feature lead time. State what stays out of those 90 days, because the cut is part of the decision. Without a review date the document becomes an open-ended promise, and the board stops trusting it in the next round.
30-minute review every week
One owner for the document and comments written in the file itself. When something changes, update the paragraph and log the date. A living document beats an approved one, because the team finds the current version in a single place, and the file history shows the order of decisions. During audits and due diligence, that history saves the whole explanation.
