Decisions That Stick

How often have you seen the same architecture debated across three meetings—only to end up back at square one because the context got lost in Slack or someone wasn’t in the room?

That’s the cost of undocumented decisions and unstructured discussion.

At the Staff+ level, you’re expected to drive clear, durable decisions that scale. That means setting up your team to decide once, move forward, and have a written record when questions resurface.

This lesson walks through a simple, repeatable process for making and documenting those decisions using:

• RFCs to align stakeholders before the meeting.

• Async reviews to surface trade-offs early.

• Decisive meetings with a clear outcome.

• ADRs to capture the decision and when to revisit it.

Let’s get started.

Request for comments

An RFC is a short, open document that collects the context, options, and comments before the meeting so that the meeting can actually decide, and the result is captured so it won’t get lost.

It’s a simple workflow to make decisions and record them:

1. Draft the RFC (1–2 pages).

2. Circulate for async comments (time‑boxed).

3. Decide in one meeting.

4. Capture the outcome in an ADR.

Run an async review

This is where real value happens. You avoid wasting a meeting by allowing people to weigh in beforehand—with clarity.

What good comments look like:

A solid comment should do three things:

1. Tie feedback to the stated goal.

2. Propose a concrete change.

3. Acknowledge the trade-off.

Ask stakeholders to comment directly in the doc—not in DMs. The conversation should live where future readers can see the reasoning.

Decide in one meeting

When you get to a meeting, the goal is to decide.

Use the RFC doc to:

• Revisit the decision goal.

• Summarize comments.

• Align in one direction.

• Note any remaining objections or follow-ups.

Then, immediately capture the outcome in a simple ADR. No one wants to debate this again next sprint.

Write ADRs that actually stick

Your ADR should be boring and searchable.

Four short sections are enough:

1. Context: One paragraph linking the RFC and the goal.

2. Decision: One sentence, active voice.

3. Consequences: What this enables and constrains (good + bad).

4. Revisit when: Explicit trigger to reopen. (e.g., “If cache hit rate < 60% for two weeks” or “If p95 stays > 2.3s after rollout”).

RFC: Reports dashboard

Here’s a sample RFC for the “Reports” dashboard example.

John Quest: Write a RFC

Turn your 5-Line PRD or 2-pager into a 1-page RFC:

• A TL;DR

• A tiny options table

• A one-line proposed decision

• Two open questions

• Review window

Then add an ADR stub at the bottom with “context → decision → consequences → revisit-when.”

Share it with your Decider/Approver first (remember to ask for edits in doc).