The TPM's Decision Record: A Durable Craft

TL;DR Program management is a craft, and the single most durable artifact in that craft is the decision record. It's a one-page note that captures the context, the options, the call, and the owner — so your program survives turnover, reorgs, and the six-month memory gap. Below is the exact template and workflow I use.

Tools come and go. The craft stays.

I've been doing some version of this work for 20+ years — founding and scaling GFM Corp from 1 to 75 people across three countries, and now leading programs for Camera & Media on the Android platform at Google for 5+ years. The tooling has changed completely across that span. The craft hasn't.

Here's what I mean. The 2026 Stack Overflow Developer Survey confirms AI coding assistants are now in daily use across the industry, even as trust in their output stays shaky (Stack Overflow Blog). The tooling layer is moving fast. But the thing that actually keeps a complex program from drifting isn't a tool — it's a disciplined habit of writing down why decisions were made. That habit is portable across every tool stack I've ever used.

If I had to teach one practice to a new TPM, it wouldn't be dependency mapping or escalation (both important). It would be the decision record. Everything else gets easier once you have them.

Why decision records beat status reports

A status report tells you what happened. A decision record tells you why. Six months later, when someone asks "why did we cut that feature?" or "why are we using this approach instead of the obvious one?", the status report is useless. The decision record answers in 30 seconds.

On a multi-quarter program spanning engineering, product, UX, and partner teams, the single biggest source of waste is re-litigating settled decisions. Someone new joins. A stakeholder forgets the tradeoff. A dependency shifts and people assume the original reasoning no longer holds. Without a record, you burn a meeting rediscovering context you already paid for.

What a good decision record is not

• It is not meeting minutes. Minutes capture everything; a decision record captures one decision.
• It is not a spec. The spec says what to build. The record says why you chose this over the alternatives.
• It is not permanent law. Decisions get superseded. When they do, you write a new record that points back to the old one — you don't edit history.

The decision record template

Keep it to one page. If it needs more than a page, the decision isn't actually ready to make. Here's the exact structure I use.

The two sections people skip — and shouldn't — are Options considered and Consequences. Options force you to show your work. Consequences force you to name the cost out loud, which prevents the "nobody told me we were trading that away" conversation later.

The weekly workflow that keeps records alive

A template nobody fills out is worthless. The craft is in the cadence. Here's how I wire it into a normal week.

1. Capture decisions as they happen

During a working session, the moment a real decision gets made, I flag it. Not "we discussed options" — an actual commitment. If it's worth a decision record, it gets a stub on the spot: title, owner, one-line decision. The details get filled in within 24 hours while context is fresh.

2. Separate reversible from irreversible

Not every decision needs a record. My filter: would reversing this cost real time or money, or would someone reasonably ask "why did we do that?" later? If yes, write it down. If it's a two-way door you can walk back cheaply, skip the ceremony and move.

3. Review the open set weekly

Once a week I scan the Proposed records. Anything stuck in Proposed for two weeks is a stalled decision — that's a risk, and it goes on the escalation list. Decisions that have quietly become wrong get marked Superseded with a new record. This weekly pass is where the system earns its keep: it surfaces the decisions nobody wants to make.

Where AI fits — and where it doesn't

I run AI-first workflows in my program work, and decision records are a good example of the right division of labor. I use AI to prepare the record, never to make the call. It drafts the Context from meeting notes, formats the options into a clean comparison, and flags inconsistencies in my rationale. That's the same instinct behind vibe-coding throwaway tools — let the machine kill the formatting grind so you spend your attention on judgment.

But the decision, the rationale, and especially the consequences stay human. The whole point of the record is accountability, and you can't delegate accountability to a model. Given the industry's shaky trust in AI output noted in this year's developer survey, I'd be nervous about any team that lets an agent author the reasoning behind a consequential call. Use AI to make the record faster to write, not to make the decision for you.

Why this scales

When I grew GFM Corp across three countries, the hardest problem was that context lived in people's heads, and people are in different timezones, on vacation, or gone. The lesson in what growing a team from 1 to 75 taught me is that written decisions are the only thing that scales across people and distance. A verbal agreement evaporates. A decision record outlives the meeting, the quarter, and sometimes the person who made it.

That's the craft. Not heroics, not a perfect dashboard — just the discipline to write down why, every time it matters.

What I'm doing about this

I'm tightening my own loop in two ways. First, I want my weekly review of open decision records to be genuinely boring — predictable enough that stalled calls can't hide. Second, I'm experimenting with having an AI assistant draft the Context and Options sections straight from my notes, so the only thing I have to write by hand is the Decision and the Consequences — the parts that actually require judgment. My bet is that lowering the cost of writing a record is what makes people write more of them. If the template is a chore, it dies. If it's two minutes, it becomes a habit.

Sources

• The results of the 2026 Developer Survey are here! — Stack Overflow Blog