2026-10-02
October 2, 2026 · Issue 112
If the unit of progress is the decision, not the date, then the calendar's only job is to close decisions faster. Audit your meetings against that.
Will Larson's pitch for roadmapping with decisions rather than dates is worth taking seriously even if you discount the AI framing. In an Anthropic partner webinar on September 21, the Imprint CTO argued that the real bottleneck on a plan is "the queue of unresolved questions," and that the schedule is a symptom of that queue. The advertised mechanisms are unglamorous: fewer handoffs, fewer approval gates, open decisions eliminated early through prototyping and feature flags, and fast escalation when none of that works.
Follow that logic to the calendar. If open decisions are what slow a program down, then a meeting is only valuable to the extent that it retires one. A weekly sync where a dozen people hear updates they could have read retires nothing. It also hides the queue, because the open question surfaces as a "topic for discussion" in the last five minutes, when nobody has the context or the authority to close it.
Larson makes a related point in his June "Revised rules of engineering leadership": with AI accelerating execution, the organization has to make binding decisions fast, and slop documents are "actively harmful" because their context poisons the LLMs that read them later. Meetings and documents are the two instruments that move decisions. Both have to get sharper at once.
So here is the editorial position. A recurring meeting should have to name the decision it exists to close, and the owner of that decision. If it can't, convert it to a written update and give the hour back.
Most TPMs manage a meeting calendar: a weekly program sync, a biweekly steering committee, a monthly business review. The calendar is organized around time. Larson's framing suggests organizing around the decision queue instead, and the shift is bigger than it sounds.
Start with the queue. Write down every open decision that is blocking or will soon block your program: build vs buy, API shape, who owns the migration, whether to cut scope for the date. For each one, record the decision owner, the deadline by which it must close to protect the plan, and the cost of the decision staying open. That last field is the one most teams skip. It turns "we should align on this" into "every week this stays open costs us a week on the critical path." Executives respond to that sentence.
Then assign each decision to the cheapest instrument that can close it. Not every decision needs a meeting, and not every decision needs a framework. Quire's comparison of ownership models gives a usable rule of thumb: "RACI is for work. DACI is for decisions. RAPID is for the rare cross-organizational decision with multiple veto-holders." Teams misapply RACI to decisions all the time, and they overuse RAPID, Bain's Recommend-Agree-Perform-Input-Decide model, on choices a single DACI page (Driver, Approver, Contributors, Informed) would settle. The practical test is how many people hold a veto. One approver and a handful of contributors is DACI. Several veto-holders across org boundaries is where RAPID's explicit "Agree" role earns its overhead.
Default to writing, and put the meeting at the end. Attentive's published RFC process, written by Staff Engineer Neha Srivastava in July, is a good model of the written path. RFCs move through Draft, In Review, Changes Requested, Approved/Closed and Blocked/Discarded. Review windows are time-boxed, with one week as the default for a medium-sized RFC. Authors are accountable for the whole lifecycle, approvers are told not to rubber-stamp, and the document stays at roughly 5 to 12 pages because an overlong RFC signals insufficient distillation. The line I'd steal is that an RFC is "a communication artifact, not a code dump." The time box matters as much as the template: it converts a perpetual draft into a decision with a deadline.
Reserve live time for what writing can't do. Synchronous time is expensive and should be spent on the residue: the two or three points of real disagreement that the written review exposed. If a meeting has no pre-read and no named decision, it is probably a status ritual. The pre-read is the filter. When reviewers have already commented asynchronously, the live session starts from the disagreement instead of from a re-presentation.
Watch for the failure mode. Written processes rot into approval theater. Reviewers pile on, approvers stay silent, and the doc drifts past its window. The cure is the same as for meetings: every document and every session has a named decision and a named owner, and a lapsed deadline triggers escalation instead of another extension. Larson's fourth mechanism, escalating quickly when the other approaches fail, is the backstop.
One honest caveat from the source page itself: cheap prototypes may relocate a decision rather than resolve it, shifting it from "can this be built" to "should we operate this." The queue still needs a human owner for the second question.
Try this week. Pull your five busiest recurring meetings. For each, write one sentence: "This meeting exists to close the decision about , owned by ." Any meeting where you can't fill the blanks becomes a written update by Monday, and any decision you discover along the way goes on a one-page queue with an owner, a deadline and a cost of delay.
What it is. Replace slides with a narratively structured memo and begin the meeting by reading it silently together. Jeff Bezos's 2017 shareholder letter describes the practice: "We don't do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of 'study hall.'"
When to use it. Decision meetings where the proposal is non-trivial: a migration plan, a scope cut, an architecture choice, a headcount ask. It fits best where you would otherwise burn the first twenty minutes re-presenting context that half the room skimmed.
How to run it:
When NOT to use it. Routine status exchange, or decisions small enough for a DACI one-pager and a thumbs-up; the study hall is overhead where nothing is contested.
Bezos's own caveat applies: "the quality of these memos varies widely," and a good memo takes real writing time, often a week or more. The method moves the work from the meeting to the author, which is the point.
Will Larson: List "decisions to make" instead of dates on your roadmap — Notes on the September 21 Anthropic partner webinar; the useful claim for TPMs is that the queue of unresolved questions, not the calendar, is the real constraint on a plan.
How Attentive Engineering designed a pragmatic RFC process — A concrete, copyable lifecycle with time-boxed reviews and clear author, approver and reviewer duties; good raw material for your own async decision path.
Revised rules of engineering leadership — Larson on why fast, binding decisions and automated base-case processes matter more as AI speeds execution, and why low-quality design docs now do active damage.
"The narrative structure of a good memo forces better thought and better understanding of what's more important than what."
— Jeff Bezos, on writing memos instead of slides (as quoted by CNBC, 2018)
Don't miss what's next. Subscribe to Critical Path: