How to write a decision memo that actually helps you decide

There is a particular kind of document that circulates in organisations — long, formatted, impressively footnoted — that nonetheless leaves everyone in the room less certain than they were before they read it. I have read hundreds of them over the years, and I have written my share of bad ones. What they share, almost without exception, is a confusion between the act of documenting deliberation and the act of actually deliberating. The decision memo, as a form, is supposed to do something quite specific: it should take a person who has not been living inside a problem and move them, in a single reading, to a point where they can make a defensible choice. When it fails — and it fails often — it is usually because the writer has unconsciously prioritised one of three other goals instead: demonstrating effort, hedging against blame, or performing thoroughness. This essay is about how to write one that does the real thing, using the format we have refined through Vault Mind CoreShift engagements, with worked examples drawn from the kinds of problems we encounter most — resourcing decisions, structural changes, build-versus-buy questions, and the always-difficult "do we stop this or don't we" moment that most organisations handle badly.

Why most decision documents are actually avoidance documents ¶

The first thing to understand is that writing a decision memo is a vulnerable act. You are committing, in writing, to a view of what is true and what should follow from that truth. Most organisational writing goes to enormous lengths to avoid this commitment — and it does so through a set of recognisable moves: the passive voice that makes the recommendation appear to float free of any human judgment, the section labelled 'Risks' that lists every conceivable downside with identical weight so that nothing stands out, and the conclusion that says something like 'further analysis may be warranted.' These are not analytical choices. They are self-protective ones. I am not unsympathetic to them — organisations punish bad recommendations more harshly than they reward good ones, and the instinct to hedge is rational at the individual level even when it is destructive at the collective level. But a document written from that instinct cannot help you decide. It can only help you feel that you have been diligent.

The core structure: four sections, in this order, for a reason ¶

The format we use at Vault Mind CoreShift has four sections, and the sequence matters as much as the content. The first is the Decision Statement — a single sentence, no longer, that says what choice is actually on the table and by when it must be made. Not 'an overview of the vendor landscape' and not 'considerations around the go-to-market approach.' The exact choice. 'Whether to renew the Apex contract at the revised rate before the 31st of March deadline, or to begin a competitive tender process.' The second section is Context, which should be no more than two short paragraphs — enough to orient someone who has not been living with the problem, but ruthlessly trimmed of anything that does not bear directly on the decision. The third is the Options Analysis, which we structure as a genuine comparison: each option stated neutrally, its best case, its worst case, and what you would have to believe to prefer it. The fourth — and this is where most memos either earn their keep or collapse — is the Recommendation, which must name a choice, name the reasoning, and name what would have to be true for that reasoning to be wrong.

A worked example: the build-versus-buy question ¶

Consider a mid-sized logistics company deciding whether to build a custom route-optimisation tool or license an existing SaaS platform. A typical document on this question will run to forty slides and end without a recommendation. Here is how the four-section format handles the same problem in two pages. Decision Statement: 'Whether to build a proprietary route-optimisation tool internally or license RouteMax (the leading available option) by Q2 — a choice that, once made, is operationally difficult to reverse within an 18-month window.' Context: The operations team has identified a 12 percent inefficiency in the current manual process. RouteMax costs £140k annually; internal build is estimated at £380k over 18 months with a six-month delay before deployment. Options Analysis: Building offers long-term IP ownership and full customisation but requires a software team the company does not currently have — meaning the true cost includes a hiring programme. Licensing is faster and lower-risk but creates ongoing dependency and limits integration flexibility. What you would have to believe to prefer building: that the competitive advantage from custom IP justifies the delay and the hiring risk, and that the internal team, once built, would maintain the tool effectively. Recommendation: License RouteMax for an initial two-year term and use that period to assess whether the company has the appetite and capacity to develop a proprietary replacement. The reasoning that would have to be wrong: that RouteMax's integration limits are more damaging in practice than they appear in the vendor documentation — which should be tested with a structured pilot in months one through three.

The three structural errors that appear most often ¶

The first error is what I think of as the inverted pyramid problem — the memo builds context and analysis for eight pages and then produces a recommendation in a single, timid sentence at the end. By that point the reader's attention has been exhausted by information they did not need in that order, and the most important sentence arrives when they are least able to receive it. The recommendation should appear early — after the Decision Statement, even before the full analysis — so that the reader encounters the rest of the document knowing what they are being asked to evaluate. The second error is option collapse: the analysis presents two or three options but writes about them with such different levels of sympathy that the comparison is not real. One option gets a full paragraph of nuanced treatment; the others get bullet points of obvious objections. The reader can feel this, even if they cannot name it, and the result is that the recommendation feels like a conclusion that was reached before the memo was written — which, often, it was. Each option must be given the best version of its own argument. The third error is the disappeared decision-maker. The memo is written as if the analysis will somehow resolve itself, with no named person or named body accountable for the final call. This matters because decisions made without clear ownership have a particular way of not being made — they get 'taken offline,' they get 'revisited next quarter,' they get superseded by events. The memo should name who decides, who advises, and who needs to be informed. This is not bureaucracy; it is the minimum condition for a decision to actually happen.

On length, tone, and the courage of the specific ¶

A well-written decision memo should be uncomfortable to write. Not because the writing itself is hard — though it requires discipline — but because committing to specificity is exposing. Saying 'we recommend against the acquisition' is exposing. Saying 'the integration risk in the first six months is the determining factor, and the seller's proposed transition plan does not adequately address it' is more exposing, because now you have made a claim that can be tested and found wrong. This is exactly the quality that makes the document useful. The memo should be as short as it can be while still being complete — in our experience, two to four pages of dense prose handles almost every decision that does not involve regulatory complexity or genuinely contested empirical questions. If you find yourself writing beyond that, the most likely explanation is that the decision itself is not yet clearly defined, and you should go back to the Decision Statement and tighten it before you continue.

What to do when the recommendation is genuinely uncertain ¶

There are decisions where the honest answer is that you cannot yet tell, and a good memo must be able to say this without collapsing into hedging. The distinction is precise: hedging says 'there are many considerations on both sides'; genuine uncertainty says 'this turns on the Q3 revenue figures, which we will have on the 14th, and no earlier analysis is worth the confidence it would imply.' If that is true, the memo's job is to say so clearly and to specify what information would resolve the uncertainty and when it will be available — which is itself a decision-support act, because it prevents the organisation from making the call prematurely. What the memo should never do is simulate certainty it does not have, because that particular failure compounds over time: the organisation learns to distrust its own documents, and the next memo, however good, arrives into a room already primed for scepticism.

I keep coming back to a line I read years ago — I think it was in a late essay by the management theorist Henry Mintzberg, though I cannot locate the exact source now — to the effect that organisations do not lack for analysis; they lack for judgment, and confuse the two. The decision memo, done well, is a form for exercising judgment in writing, which is the only way to make judgment legible to others. It will not make hard decisions easy. But it will stop the pretence that producing a document is the same as making a choice.