"A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in." — Paul Graham
This week's premise: Synchronous meetings are the most expensive — and most abused — resource in a large company. An 8-person, 1-hour meeting is 8 work-hours, and that's before you count the shattered blocks of focus time. Doc-first isn't a trick for fewer meetings; it's an organizational design that separates "thinking" from "broadcasting": write the decision down clearly, let people read and comment asynchronously, and reserve meetings for what truly needs high bandwidth — conflict, ambiguity, empathy. This week's four principles: replace a meeting with a one-page memo, let decisions take shape through RFCs, leave the "why" behind with ADRs, and systematically cut your meeting load. None of this is remote-only — it holds for any tech lead drowning in meetings.
PRINCIPLE 01
Writing-First: A Memo Instead Of A Meeting
The Memo Over The Meeting
Doc-firstNarrative memoSilent reading
The Principle In One Line
Write important decisions down before you meet. Writing forces fuzzy thinking into clear logic — a slide deck can be bluffed with charisma; a coherent one-page narrative cannot. A meeting is for "discussion after reading," not for someone reading their script aloud.
In Their Words
"The reason writing a good four-page memo is harder than 'writing' a twenty-page PowerPoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what."— Jeff Bezos, Amazon 2017 Shareholder Letter
In Practice
Scenario: You want to push an architecture-migration decision and have booked a 1-hour review with 8 stakeholders.
✗ The Usual Way
You make 20 slides and walk through them. The first 40 minutes are background; you reach the key trade-off with 10 minutes left — and time's up. Half the room never read the background and is just following your narration. Real objections never surface. You "seem aligned" when it ends; a week later three people are each doing their own thing.
✓ Amazon "study hall" style
Before: Write a 4-page narrative memo (context → proposal → rejected alternatives → risks → open questions), send it 24 hours ahead.
Open with: "Let's read silently for 15 minutes and comment inline as we go. Then we'll jump straight to the contested parts."
Result: Everyone is on the same information baseline. The 60 minutes go entirely to trade-offs and objections, not information broadcast. The comments double as a decision record.
The Skeleton Of A One-Pager (Checklist)
Context/problem: Can someone outside this area finish it and understand "why now"?
Proposal: Can you state "what we recommend" in one sentence?
Rejected alternatives: Did you write "why not B and C"? (Most often skipped, most valuable.)
Risks & open questions: Honestly list what's unresolved, not just the good news.
Does it stand alone without slides? The doc must exist without the presenter.
Common Mistakes
Turning slides into a "doc." Stacked bullets aren't narrative. Write full sentences and paragraphs — that's what exposes the logic.
Sending the doc but nobody reads it. That's why you read silently in the meeting — don't assume; give time to read.
Using docs to hide muddled thinking. The pain of doc-first is exactly this: if you can't write it clearly, you haven't thought it clearly. That's the value.
Writing long docs for small things. Reversible, two-way-door decisions need one Slack message. Don't be dogmatic.
Female Leader's Note
Female Leader's Note
Research repeatedly shows women are more often interrupted in meetings and have ideas re-attributed to male colleagues. A writing culture is a structural corrective: ideas live in a doc with a name and timestamp, so who proposed what is unambiguous — it doesn't go to whoever is loudest. As a leader, reinforce this deliberately: when you cite something in the meeting, name the source — "This proposal is Priya's, in section 2; let's build on her thread." Anchor credit to the written word.
Key References
Jeff Bezos, Amazon 2017 Shareholder Letter — origin of the six-page narrative memo, the "no PowerPoint" rule, and silent reading. Camille Fournier,《The Manager's Path》 — writing as a core leverage point for senior engineering leaders.
PRINCIPLE 02
RFC Culture: Decisions That Form In The Open
Request For Comments
RFCDesign docAsync review
The Principle In One Line
An RFC (Request for Comments) / design doc is a proposal that is public, asynchronously commentable, and has a clear lifecycle. It turns "a few people deciding in a room" into "a participatory, traceable decision process" — and it's the lowest-cost way to align at scale.
In Their Words
"The most important section… is the one that describes considered alternative designs and trade-offs. Many design decisions are easier to understand when reading about which alternatives were explored and why they were not chosen."— Malte Ubl, "Design Docs at Google" (2020)
The Lifecycle Of An RFC
In Practice
Scenario: A senior engineer corners you to verbally sell you on adopting a new framework.
✗ Deciding verbally on the spot
Won over by his enthusiasm, you nod: "Sounds good, do it." Two weeks later two other teams surface a conflict — they never knew, and the decision left no trace to trace back to.
✓ Route it into an RFC
"This is worth doing properly. Write a one-page RFC: the problem, your proposal, two alternatives you considered and rejected, and the impact on other teams. Open comments for 3 working days and @ the Platform and Data teams."
"If there are no blocking objections after three days, we approve. This is sturdier than convincing me alone — you're convincing everyone affected, and it's on the record."
Checklist For A Good RFC
Title + one-line summary: a glance tells you what's being proposed.
An explicit comment deadline and decision-maker (DRI) — not "thoughts welcome."
"Alternatives considered" as its own section — the highest-value part of an RFC.
Explicitly @ every affected team, instead of assuming they'll find out.
After the decision, set status to Decided and link to the ADR / implementation ticket.
Common Mistakes
An RFC with no deadline. An infinite comment window = decision paralysis. Doc-first doesn't mean slow; time-box it.
No DRI. "What does everyone think?" means no one owns it, and you end up back in a room.
Treating the RFC as a rubber stamp. If objections are always ignored, no one comments seriously the second time.
RFC-ing everything. Reserve RFCs for "architecturally significant" or cross-team decisions; don't wrap trivia in process.
Key References
Malte Ubl, "Design Docs at Google" (2020) — design-doc structure, especially the "alternatives" section. Will Larson,《An Elegant Puzzle》 — using RFCs and architecture reviews to keep consistency during hypergrowth.
PRINCIPLE 03
Decision Records (ADR): Leave The "Why" Behind
Capturing The Why
ADRDecision logInstitutional memory
The Principle In One Line
Code records "what was done"; an ADR (Architecture Decision Record) records "why we decided, the context at the time, and what we gave up." Six months on, no one remembers why the other path wasn't taken — the ADR is the organization's defense against forgetting.
In Their Words
"We will keep a collection of records for 'architecturally significant' decisions… Each record describes a set of forces and a single decision in response to those forces. We will keep ADRs in the project repository."— Michael Nygard, "Documenting Architecture Decisions" (2011)
In Practice
Scenario: Six months ago you decided to build a lightweight queue instead of using Kafka. Today a new staff engineer challenges it in the channel: "This obviously should be Kafka — who made this call?"
✗ No record
No one remembers the full reasoning. You defend it from memory, which sounds like backfilling; the team starts doubting the decision, and someone wants to rip it out and redo it — paying the sunk cost all over again.
✓ Point to the ADR
"See ADR-014. The constraints then: a 3-person team, < 1k msgs/s, and zero headcount to operate Kafka. In that context, building was right."
"The scale has changed now — feel free to write a new ADR that supersedes it, but argue from today's constraints, not 'that was dumb.'" The ADR pulls the argument from "who was wrong" back to "have the constraints changed."
The Minimal Structure Of An ADR (Checklist)
Context: the constraints, scale, headcount, time pressure at the time — the most critical section.
Decision: what we decided to do, in one clear sentence.
Consequences: the benefits, the costs, and the risks we accepted.
Status: Proposed / Accepted / Superseded by ADR-XXX.
Numbered + in the repo (write only for hard-to-reverse decisions; skip reversible ones).
Common Mistakes
Recording the conclusion, not the context. "We use Postgres" is worthless; "3-person team, need transactions, team knows Postgres best" is valuable.
Editing it later. An ADR is immutable — if the decision changes, write a new one and mark the old one superseded, or you lose the history.
Chasing perfect format. A 5-line ADR beats none. The lower the bar, the more people write them.
ADRs for trivia. Only "architecturally significant" decisions — those affecting structure, dependencies, and hard to reverse.
Key References
Michael Nygard, "Documenting Architecture Decisions" (2011) — the original source of the ADR concept. Will Larson,《An Elegant Puzzle》 — building decision records into how an engineering org operates.
PRINCIPLE 04
Cutting Meeting Load: Sync As A Scarce Resource
Async By Default
Async-defaultMaker scheduleFewer meetings
The Principle In One Line
Default to async; a meeting is an escalation, not the default. Use sync only for what genuinely needs high bandwidth: conflict, ambiguity, emotion, brainstorming. If it can be written clearly, don't meet — before booking, ask "could this be a doc?"
In Their Words
"When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."— Paul Graham, "Maker's Schedule, Manager's Schedule" (2009)
Decision: Does This Need A Meeting?
In Practice
Scenario: Your team's calendar is packed with meetings and engineers complain they have no uninterrupted time to write code.
✓ Systematic moves to cut meetings
1. No-Meeting Day: "Wednesdays are No-Meeting Days for the whole team. I'll clear mine first to set the example."
2. Kill recurring meetings: "Cancel all recurring meetings for two weeks; whoever truly needs one adds it back." Most won't get re-added.
3. Status goes async: "Daily standup becomes async — post three lines each morning: yesterday/today/blockers. Only blockers trigger a sync."
4. Set the rule: "A meeting invite must carry an agenda and a pre-read; without them, you have the right to decline."
Meeting-Cutting Checklist
Is there a doc that could replace this meeting? (Write first; meet only if it won't write clearly.)
Does every meeting have an agenda + pre-read + a clear "what this meeting must produce"?
Are invitees truly needed, or pulled in "just in case"? Trim to the minimum.
Is there protected focus time for the team (no-meeting day / core focus block)?
Are recurring meetings periodically zeroed out and rebuilt on demand?
Common Mistakes
Treating async as "never sync." For conflict, sensitive feedback, and empathy, forcing text is cold and inefficient. Async is the default, not dogma.
Cutting meetings but shifting the load to "ping anytime." Replacing sync meetings with all-day Slack bombardment destroys focus just the same. Async means "no need to reply instantly."
No-meeting day in name only. If you're the first to break it, the rule dies that day.
Cutting 1:1s. 1:1s are relationship and trust; they can't be made async (see Day 1). Cut the status meetings.
Female Leader's Note
Female Leader's Note
"Office housework" — taking minutes, booking rooms, chasing status — falls disproportionately on women over time and rarely converts into promotion capital. When you shift to a written/async culture, fix that distribution while you're at it: make the doc DRI and the note-taker rotate by role (written into the process, not "whoever volunteers"), instead of defaulting to "the woman on the team will jot it down." Making invisible labor visible and rotatable is itself fairness by design.
Key References
Paul Graham, "Maker's Schedule, Manager's Schedule" (2009) — why uninterrupted blocks matter for makers. Jason Fried & DHH,《It Doesn't Have to Be Crazy at Work》 — "meetings as a last resort" and async-default culture. GitLab Handbook — "handbook-first": the extreme of writing everything down by default.
This Week's Exercise · Your Day 18 Action
Do one concrete thing this week — not reflection, not reading:
Pick one recurring meeting on your calendar this week (the one that most resembles a "status broadcast"). Replace it with an async doc: send it ahead, give 24 hours of async comments, and at the time hold only a 15-minute mini-sync on the "still contested" comments (or skip it entirely).
Afterward, note two lines: (1) how many minutes of sync time it dropped from and to; (2) whether the decision quality was better or worse.
Reflection: which of your team's meetings are really using sync time to compensate for "no one being willing to write things down clearly"?
Going Deeper
Does doc-first break down in teams with weak writing culture or mostly non-native English speakers?
It gets markedly harder. Narrative memos demand writing ability, and forcing them can disadvantage people who are strong technically but weak at expression, while amplifying native speakers' advantage. The fix isn't to abandon it but to lower the bar: provide templates, accept bullets + short video (Loom) hybrids, use AI to polish, and make explicit that "we judge content, not prose." Culture is grown gradually, not mandated overnight.
Does over-doing async sacrifice weak ties and serendipitous information flow?
Yes. Hallway run-ins and pre-meeting small talk seed creative collisions and trust — pure async can turn an org into an efficient but disconnected machine. So async is the default, not the entirety: deliberately keep a small number of high-bandwidth occasions (team socials, brainstorms, agenda-less rambles), and use sync for what async does badly — building relationships, handling emotion, sparking ideas.
In a politicized big company where "meetings = visibility" and "docs go unread," is doc-first realistic for a single tech lead?
Pushing it top-down company-wide isn't realistic, but within your own team's boundary it is. Strategy: build a model in the area you control (your meetings all carry pre-reads, your decisions all have ADRs) and let results speak; upward, use docs as a managing-up tool (your boss would rather read a one-page memo than be pulled into a meeting). Culture spreads from local demonstration, not from edicts.
Won't RFC/ADR maintenance eventually become "doc debt" no one updates?
A real risk. The key distinction: an ADR is an immutable historical snapshot — it's not supposed to be updated (when the decision changes, you write a new one), so it has almost no maintenance cost; that's its advantage over "living docs." What becomes debt are the living docs that try to "stay current." Principle: prefer immutable records (decisions, meeting notes) over living docs; living docs need a named owner and a review cadence, or don't create them.
Could cutting meetings backfire on a manager's own influence ("being in meetings" is also how you're seen)?
This is an honest gray area. In many orgs, showing up in the room = political capital, and someone who works purely async can go "invisible." The cost is real: you may be efficient but unnoticed by leadership. A pragmatic balance — invest the time you save into a few high-leverage sync occasions (key reviews, cross-functional, upward reporting) and be "seen" there at high quality; meanwhile let your team's output (docs, decision records) be the evidence of your influence. Don't meet just to be present, but don't naively assume pure output gets noticed on its own.