2026-10-09
October 9, 2026
Most programs are not limited by engineering time. They are limited by decisions nobody has made yet, and your Friday meeting is where that gets fixed or hidden.
Will Larson recently described a credit card application project at Imprint where the implementation was about two weeks of work and the plan allowed two months. The gap was not padding. It was roughly a dozen ambiguous decisions, each of which would be resolved at the organization's normal, slow pace. Larson's conclusion, in his post "Roadmap decisions rather than dates": for most projects, time is not the binding constraint. Approvals, handoffs and unresolved questions are.
If you run programs, that should sting a little. The standard TPM artifact is a timeline with milestones. The standard weekly ritual is a status meeting that asks whether the dates still hold. Both treat the calendar as the thing under management. Larson's proposal flips the object: keep a list of open decisions, who owns each, and what it blocks. Give the outside world a plausible, slightly conservative date, and then largely ignore that date internally. In his words, an engineer who doesn't know the release date can still ship.
This matters more now than it did two years ago. When prototyping gets cheap, the expensive step is no longer building the thing. It is agreeing on what the thing is. Larson's passkey story makes the point: the feature never made the roadmap, he built it behind a disabled feature flag, the working prototype made the trade-offs concrete, and the team resolved them quickly. The prototype did not replace the decisions. It made them answerable.
The practical read for a senior TPM or an engineering director: your meetings should be shaped like the decision list, not like the Gantt chart. Which brings us to today's deep dive.
Most meeting dysfunction is a category error. We schedule a meeting because a topic exists, when we should schedule one because a decision is ripe. A topic invites discussion. A decision invites a deadline, an owner and a record. Once you shift the unit of work from topic to decision, three things about your ceremonies change.
First, the default medium flips to written and asynchronous. Lukas Niessen's write-up on RFCs and ADRs (on ITNEXT) gives a useful set of timeboxes that match what many teams converge on: about one to two days to draft the RFC, two to three days of async review, then a decision meeting of 30 to 60 minutes with five to eight people at most. The meeting agenda is deliberately small: a couple of minutes of context, ten to fifteen on open questions, the rest on discussion, and the last five to ten minutes to decide. The author runs the meeting. Notice what this does: the live hour is spent only on what the written pass could not resolve. If the async round resolved everything, cancel the meeting. That is a feature, not a failure.
Second, the document does the work the loudest person used to do. Niessen argues against plain pro/con lists and for stating priorities first, then scoring options against them, including an explicit "do nothing" option. That ordering matters because most arguments in engineering reviews are disguised disagreements about priorities. Make the priorities explicit in the doc and the argument moves to where it can actually be settled. The async window also gives quieter reviewers time to contribute, which a live room tends to suppress.
Third, the decision gets a rule for how it will be made, before it is made. Niessen lists four modes: consensus, consent ("can you live with this?"), a single directly responsible decider, and voting, which he suggests using sparingly. The failure mode I see most in large programs is not picking the wrong mode. It is leaving the mode implicit, so half the room thinks they are voting and the other half thinks a director will decide. Say it at the top of the RFC: "This is a consent decision; the DRI is X; the deadline is Thursday."
Now the TPM-specific application of Larson's idea. Keep a decision register for each program: one row per open decision, with an owner, a due date, the work it blocks, and the cost of reversing it. Review it weekly instead of (or before) the milestone review. Two columns do most of the work. "Blocks" tells you which decisions are on the critical path, and it is almost never the ones people are loudly debating. "Reversible?" tells you how much process each deserves. Larson is explicit that mistakes are acceptable when they are cheap to reverse, and that engineers should de-risk with tools such as feature flags. A reversible decision should be made by one person in a day. An irreversible one earns the RFC, the review window and the decision meeting. Most programs run every decision through the heavy process, which is why they are slow.
There is a leadership implication too. If decisions, not engineering weeks, are the constraint, then the scarce resource is the attention of whoever holds the decision rights. Directors and VPs should ask their TPMs for the register, not the timeline, and should treat a decision that has aged past its due date as an escalation in its own right. That is a cleaner conversation than "the date slipped," because it points at a named person and a concrete choice rather than at a vague schedule.
A caution on async. Niessen names the failure modes plainly: analysis paralysis when there is no deadline, too many stakeholders with no one deciding, decisions made without a written record so the reasoning is lost, and hallway decisions that cause rework. Async is not a virtue in itself. It is a way to move the cheap parts of a decision off the calendar so the expensive part, the live disagreement, gets the full attention of a small room.
Try this week. Pick one program and list every open decision blocking it, with an owner, due date and "reversible in under a week? Y/N." Replace the first ten minutes of your next status meeting with that list, and cancel any meeting whose decision is marked reversible and already has a written proposal.
What it is. Amazon replaced slide presentations in senior meetings with written narrative memos of up to six pages, read in silence by everyone at the start of the meeting before discussion begins. Bezos described the rationale in a 2004 email: a good four-page memo is harder to write than a 20-page PowerPoint because the narrative structure "forces better thought and better understanding of what's more important than what."
When to use it. When a decision is significant, cross-functional and not trivially reversible, and when previous meetings on it have been dominated by whoever talks most or by slides that hid the reasoning.
How to run it:
When NOT to use it. For reversible, low-stakes calls, or routine status updates, where the cost of writing the memo exceeds the cost of being wrong.
Pair it with the decision register above: the register tells you which decisions deserve a memo.
Inside Atlassian's developer experience overhaul — Atlassian's Andrew Boyagi says they start by asking developers what slows them down, and protect 10% of developer time for improving their own environment. Useful as a template for funding friction removal as scheduled work rather than a side effort.
The Pulse: new trend of building internal vibe-coding apps — Gergely Orosz reports that Ramp and Stripe built platforms letting non-engineers create internal tools, and expects more companies to follow. Worth watching if your program backlog is full of small internal-tool requests.
Your junior engineers are getting faster but are they getting better? — LeadDev piece by Garima Agarwal on whether speed gains from AI tools translate into real skill growth. A reminder that throughput metrics and capability metrics can diverge.
"...forces better thought and better understanding of what's more important than what."
— Jeff Bezos, on the narrative memo versus PowerPoint (2004 email, as reported by CNBC)
Don't miss what's next. Subscribe to Critical Path: