Skip to main content

> asynchronous_engineering_decision_making_&_working_in_public

Asynchronous Engineering Decision Making & Working in Public

Why do distributed engineering teams that mandate written, asynchronous RFC deliberation achieve higher quality architectural outcomes than meeting-heavy cultures?

Stack: LEADERSHIP INCIDENTS STACK →Senior (L5-L6)pattern

⚡THE SHORT ANSWER

Written asynchronous deliberation forces authors to think through edge cases and failure modes deeply, eliminates timezone exclusion, prevents the 'loudest voice in the room' bias, and automatically creates permanent searchable institutional documentation.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

Asynchronous decision making replaces consensus-by-meeting with structured written narratives (e.g., 2 to 6 page RFCs). Proposers publish a clear problem statement, evaluated options, and explicit tradeoffs in a public tool (GitHub Discussions, Notion, Google Docs). A mandatory 5-business-day review window allows engineers across all timezones to review and comment in depth. If a synchronous meeting is required, it follows the Amazon model: the first 20 minutes are spent in silent reading before structured Q&A begins.

🎯2. Appropriate Use Context

Scope

Essential for all globally distributed, remote-first, or multi-hub engineering organizations designing cross-team interfaces, infrastructure migrations, and foundational libraries.

⚠️3. Production Failure Modes

P0 Risk
  • ✓

    Calendar gridlock: Staff engineers spend 35 hours per week in Zoom calls, leaving zero time for architectural thinking

  • ✓

    critical decisions made informally in private DMs lead to production schema mismatches across timezone hubs

📡4. Diagnostic Signals & Telemetry

Telemetry

Engineers complaining of Zoom fatigue, important technical discussions happening in private 1-on-1 Slack channels, and remote engineers surprised by unannounced API changes.

🛡️5. Prevention & Safeguards

Safeguards
  • ✓

    Establish a 'No Meeting Without a Pre-Read Doc' policy

  • ✓

    enforce 'Work in Public' by defaulting all technical Slack channels to public

  • ✓

    designate an explicit Decider and hard deadline for every RFC

⚖️6. Architectural Trade-offs

Trade-off

Requires disciplined technical writing skills and slightly extends calendar elapsed time for decisions in exchange for vastly higher design quality and zero calendar fatigue.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

A remote team replaced their 2-hour weekly architecture review meeting with asynchronous RFCs in GitHub Discussions. Over 6 months, deep comment engagement increased by 400%, junior engineers contributed 45% of critical edge-case catches, and calendar meeting time dropped by 80%.

Interactive Concept Drills

3 Cards
Q1

What is the 'Silent Meeting' practice popularized by Amazon?

Attendees sit in silence for the first 15-20 minutes of the meeting reading the printed 6-page memo and writing comments before any verbal discussion starts.
Q2

Why is 'Working in Public' critical for remote engineering organizations?

It ensures all technical debates, decisions, and progress happen in open channels and repositories, preventing information silos and unintentional exclusion.
Q3

How does written asynchronous deliberation mitigate the 'loudest voice in the room' bias?

Written arguments are judged by their logical coherence, data, and edge-case handling rather than an extrovert's verbal charisma or seniority.

Asynchronous Engineering Decision Making & Working in Public — Technical FAQ

How do you prevent asynchronous RFC discussions from dragging on indefinitely?

Every RFC must have a designated 'Decider' and a strict deadline (e.g., 5 business days). Once the deadline arrives, the Decider accepts or rejects the RFC regardless of pending comments.

When is a synchronous meeting actually justified in an async-first culture?

Only for active Sev-0 incident command bridges, sensitive personal 1-on-1 career discussions, team bonding/socials, or resolving deadlocked 2-way RFC disagreements.

How should junior engineers be encouraged to write and review RFCs?

Provide clear RFC templates, pair them with Staff mentors for first drafts, and celebrate thoughtful review comments from junior engineers in public retrospectives.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸

    Organizations that transition to written async decision making reduce weekly meeting overhead by over 60% while increasing architectural documentation coverage to near 100%.

  • ▸

    High-quality engineering writing is a force multiplier for remote organizational scalability.

Common Misconceptions

  • ✗

    Assuming that asynchronous communication means slow progress and lack of urgency.

Decision & Governance Guidance

Mandate written RFC narratives for all significant architectural changes and enforce a 5-day review window with a designated decider.

Authoritative Sources & Standards

Technical terms on this page

Edge Computing