Async Workflows

Async standup variations

Classic three-question standup

Best for small teams (3-8 people). Post daily in a dedicated channel.

• What I completed yesterday
• What I'm working on today
• Any blockers

Progress-and-plans standup

Best for project-focused teams. Post at end of day (captures what actually happened).

• Progress: What moved forward today (with links to PRs/docs)
• Plans: Top 1-2 priorities for tomorrow
• Signals: Anything the team should know (risks, delays, discoveries)

Weekly async standup

Best for senior/autonomous teams where daily updates add friction without value.

• Shipped: What was completed this week
• In flight: Current focus areas
• Upcoming: What's planned for next week
• Help needed: Where input from others would accelerate progress

Standup implementation checklist

1. Choose a channel or tool (Slack channel, Geekbot, Linear updates, etc.)
2. Set a consistent posting window (not a fixed time - a 3-hour window works)
3. Establish the read norm: standups are write-only unless someone needs help
4. Rotate a weekly "standup reviewer" who scans for patterns and raises risks
5. Review the format quarterly - adjust if people are writing boilerplate

---

Async code review protocol

Setting expectations

• Author tags reviewers and sets a review-by date (default: 24 hours for standard PRs, 4 hours for hotfixes, 48 hours for large architectural changes)
• PR description includes: what changed, why, how to test, and any areas where the author wants specific feedback
• If no review by deadline: author pings once. If still no review after 8 hours: author can merge with a note explaining the situation

Review quality standards

• Comments should be actionable: "Consider X because Y" not "I don't like this"
• Use comment prefixes to signal intent:
  • nit: - Style preference, non-blocking
  • suggestion: - Improvement idea, author decides
  • question: - Need clarification before approving
  • blocker: - Must be addressed before merge
• Approve with comments means the nits can be addressed in a follow-up

Reducing review round-trips

• Author self-reviews the diff before requesting review (catches 30% of issues)
• Use PR templates that force the author to fill in context
• For complex changes: record a 3-5 minute Loom walkthrough of the code
• If a review thread exceeds 3 back-and-forth exchanges: move to a 10-minute call, then document the outcome in the thread

---

Async brainstorming techniques

Silent brainstorm (brainwriting)

1. Share a prompt or problem statement in a doc
2. Each participant adds ideas independently (set a contribution window: 24-48 hours)
3. No commenting on others' ideas during the contribution phase
4. After the window closes, a facilitator groups ideas into themes
5. Team votes asynchronously (dot voting: 3 votes per person)
6. Top ideas move to evaluation (can be async or sync depending on complexity)

Why it works: Removes anchoring bias, gives introverts equal voice, allows deeper thinking than real-time brainstorming.

Structured proposal round

For decisions with 2-4 clear options:

1. Each option gets a one-page brief (written by its advocate)
2. All briefs shared simultaneously
3. 48-hour comment period where people ask clarifying questions
4. Advocates update their briefs based on questions
5. Team votes or decision-maker decides with written rationale

Async design critique

For visual or UX work:

1. Designer shares work in a doc/Figma with specific questions ("Is the nav hierarchy clear?" not "What do you think?")
2. Reviewers leave contextual comments tied to specific elements
3. Designer responds async, grouping feedback into "will do," "won't do (because)," and "need to discuss"
4. Only the "need to discuss" items require a sync touchpoint

---

Async decision-making frameworks

RAPID for distributed teams

• Recommend: One person writes the proposal (async, in a doc)
• Agree: Named stakeholders must sign off (async comments, explicit +1/-1)
• Perform: The person who will execute - confirms feasibility in comments
• Input: Broader team provides input during the review window
• Decide: One named decider makes the call after the review period closes

Consent-based decision making

Instead of seeking consensus (everyone agrees), seek consent (nobody objects).

1. Proposal is shared with a review deadline
2. Team members respond with: "consent" (no objections), "concern" (minor issue, not blocking), or "objection" (fundamental problem that must be addressed)
3. If no objections by deadline: proposal is accepted
4. If objections: author addresses them and re-shares for a shorter review period
5. Silence after deadline = consent (state this norm explicitly in your charter)

---

Tools and automation

Bot-assisted standups

Use tools like Geekbot, Standuply, or custom Slack workflows to:

• Prompt team members at their preferred time
• Collect responses and post them in a shared channel
• Flag when someone misses a standup (gentle nudge, not surveillance)
• Generate weekly summaries from daily standups

Async video messages

For context-heavy updates where text feels insufficient:

• Loom, Vidyard, or screen recordings for code walkthroughs
• Keep videos under 5 minutes (if longer, it should be a doc)
• Always include a text summary below the video link
• Videos are supplements, not replacements for written artifacts

Documentation Templates

RFC (Request for Comments)

Use for any decision that affects more than one person, is hard to reverse, or where you want structured input from the team.

# RFC: [Title]

**Author:** [Name]
**Status:** Draft | In Review | Accepted | Rejected | Superseded
**Created:** [Date]
**Review deadline:** [Date - typically 3-5 business days from sharing]
**Reviewers:** [Names - tag specific people, don't rely on "the team"]
**Decision maker:** [Name - one person who makes the final call]

## TL;DR

[2-3 sentences. A busy person should be able to read this and know what you're
proposing and why.]

## Context

[What is the current situation? What problem are we solving? Include data,
metrics, or user feedback if available. Link to related docs or past decisions.]

## Proposal

[What do you recommend? Be specific and concrete. Include enough detail that
someone could implement this without further clarification.]

### Implementation plan

[How would this be executed? Key milestones, rough timeline, who does what.]

## Alternatives considered

[What other options did you evaluate? For each alternative:]

### Alternative A: [Name]

- **Description:** [What is it]
- **Pros:** [Why it could work]
- **Cons:** [Why the proposal is better]

### Alternative B: [Name]

[Same structure]

## Trade-offs and risks

[What are we giving up by choosing this path? What could go wrong?]

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | Low/Medium/High | Low/Medium/High | [How to reduce it] |

## Open questions

[What do you need input on? Number these so reviewers can reference them.]

1. [Question 1]
2. [Question 2]

## Decision log

[Filled in after the review period closes]

- **Decision:** [Accepted/Rejected/Modified]
- **Date:** [When decided]
- **Rationale:** [Why, incorporating reviewer feedback]
- **Dissenting views:** [Any strong objections and how they were addressed]

RFC process rules

• Author shares the RFC and pings reviewers with the deadline
• Reviewers comment inline, referencing specific sections
• Author responds to all comments (even if just "acknowledged")
• After deadline: author summarizes feedback, updates the proposal if needed, and the decision maker makes the call
• Silence after deadline = consent (state this norm explicitly)
• Accepted RFCs are archived in a known location (docs folder, wiki, Notion)

---

ADR (Architecture Decision Record)

Use for technical decisions that future engineers will need to understand. Lighter than an RFC - captures the decision after it's made, not the deliberation.

# ADR-[NNN]: [Title]

**Date:** [Date]
**Status:** Accepted | Deprecated | Superseded by ADR-[NNN]
**Deciders:** [Names]

## Context

[What is the technical context? What forces are at play?]

## Decision

[What did we decide? State it clearly in one paragraph.]

## Consequences

### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Trade-off 1]
- [Trade-off 2]

### Neutral
- [Side effect that's neither good nor bad]

## Related

- [Link to RFC if one existed]
- [Link to related ADRs]

ADR conventions

• Number ADRs sequentially (ADR-001, ADR-002, etc.)
• Store in a /docs/adr/ directory in the repo
• Never delete an ADR - mark it as "Superseded by ADR-NNN" instead
• Keep ADRs short (under 50 lines) - they capture what and why, not how

---

Post-mortem / incident review

Use after any incident, outage, or significant project failure. Focus on learning, not blame.

# Post-mortem: [Incident title]

**Date of incident:** [Date]
**Duration:** [How long the incident lasted]
**Severity:** [P0/P1/P2/P3]
**Author:** [Name]
**Reviewers:** [Names of people involved in the incident]

## Summary

[2-3 sentences: what happened, what was the impact, how was it resolved.]

## Timeline

[Chronological account of events. Use timestamps with timezone.]

| Time (UTC) | Event |
|---|---|
| HH:MM | [What happened] |
| HH:MM | [Detection: how we found out] |
| HH:MM | [Response: first action taken] |
| HH:MM | [Resolution: what fixed it] |

## Root cause

[What was the underlying cause? Go deeper than "a bug in the code" - why did
the bug exist? Why wasn't it caught?]

## Impact

- **Users affected:** [Number or percentage]
- **Revenue impact:** [If measurable]
- **Data impact:** [Any data loss or corruption]

## What went well

- [Thing that worked in our response]
- [Process that helped us resolve faster]

## What went poorly

- [Gap in our process or tooling]
- [Communication breakdown]

## Action items

| Action | Owner | Deadline | Priority |
|---|---|---|---|
| [Specific fix or improvement] | [Name] | [Date] | P0/P1/P2 |

## Lessons learned

[1-3 key takeaways that should change how we work going forward.]

Post-mortem process

• Write the draft within 48 hours of resolution (while memory is fresh)
• Review with all involved parties before publishing
• Focus on systems, not individuals - "the deploy process allowed X" not "person Y did X"
• Action items must have named owners and deadlines or they won't happen
• Review action item completion in the next team sync

---

Project brief

Use at the start of any project to align stakeholders before work begins.

# Project brief: [Project name]

**Owner:** [Name]
**Team:** [Names and roles]
**Created:** [Date]
**Target launch:** [Date]
**Status:** Planning | In Progress | Shipped | Paused

## Problem statement

[What problem are we solving? Who has this problem? How do we know it's worth
solving? Include data if available.]

## Goals and success metrics

| Goal | Metric | Target |
|---|---|---|
| [Goal 1] | [How we'll measure it] | [What success looks like] |

## Non-goals

[What are we explicitly NOT trying to do? This is as important as the goals.]

- [Non-goal 1]
- [Non-goal 2]

## Proposed solution

[High-level approach. Enough detail to evaluate feasibility, not enough to
implement. Link to RFC or design doc for details.]

## Key milestones

| Milestone | Target date | Owner |
|---|---|---|
| [Milestone 1] | [Date] | [Name] |

## Dependencies and risks

- [Dependency on another team or system]
- [Key risk and mitigation]

## Communication plan

- **Updates:** [Where and how often - e.g., weekly digest in #project-channel]
- **Decisions:** [Where decisions are documented - e.g., RFC folder]
- **Escalation:** [Who to contact for blockers]

---

Status update template

Use for regular project updates posted async (weekly or biweekly).

# Status update: [Project name] - [Date]

**Overall status:** On Track | At Risk | Blocked

## TL;DR

[One sentence: what's the most important thing to know this week?]

## Progress since last update

- [Completed item with link to deliverable]
- [Completed item]

## In progress

- [Work item] - [Owner] - [Expected completion]

## Risks and blockers

| Issue | Impact | Mitigation | Help needed from |
|---|---|---|---|
| [Issue] | [What happens if unresolved] | [Current plan] | [Name/team] |

## Decisions needed

- [Decision] - [Context link] - [Deadline]

## Next week's focus

- [Priority 1]
- [Priority 2]

---

Document hygiene rules

1. One canonical location - Every document type has a known home (e.g., RFCs in /docs/rfcs/, ADRs in /docs/adr/). Never let docs scatter across tools.
2. Link, don't copy - Reference other docs by link. Copied content rots.
3. Date everything - Every doc has a created date. Status updates have the reporting period. Decisions have the decision date.
4. Name owners - Every action item, every review request, every decision has a named person. "The team" owns nothing.
5. Archive, don't delete - Old docs are historical artifacts. Mark them as superseded or archived, but keep them discoverable.
6. Front-load the TL;DR - Busy stakeholders read the first 3 lines. Put the most important information there.

Meeting Facilitation

Universal facilitation rules

1. No agenda, no meeting - Cancel any meeting without a shared agenda
2. Start on time, end 5 minutes early - Respect calendar boundaries
3. Cameras optional, engagement mandatory - Don't police cameras; do call on people
4. One speaker at a time - Use a raise-hand queue in the tool (Zoom, Meet, etc.)
5. Capture decisions in real time - The note-taker writes decisions as they happen, not from memory afterward
6. End with action items - Every meeting outputs: who does what by when
7. Share notes within 1 hour - Post in the team channel or doc before moving on

---

Meeting type playbooks

Project kickoff

Purpose: Align the team on goals, scope, roles, and timeline for a new project.

Duration: 45-60 minutes

Pre-work: Share a project brief doc at least 48 hours before. Attendees must read it and post questions as comments before the meeting.

Agenda:

1. (5 min) Context and motivation - Why are we doing this?
2. (10 min) Walk through pre-read questions - Address comments from the brief
3. (10 min) Scope boundaries - What's in, what's explicitly out
4. (10 min) Roles and responsibilities - Who owns what
5. (10 min) Timeline and milestones - Key dates and dependencies
6. (5 min) Communication plan - Where updates live, cadence, escalation path
7. (5 min) Action items and next steps

Output: Updated project brief with decisions, RACI or ownership list, and first set of action items.

Sprint/iteration planning

Purpose: Decide what the team will work on in the next cycle.

Duration: 30-45 minutes (keep tight; the backlog should be pre-groomed)

Pre-work: Product owner or tech lead pre-prioritizes the backlog. Team members review top items and flag concerns async before the meeting.

Agenda:

1. (5 min) Review previous sprint outcomes - What shipped, what rolled over
2. (5 min) Capacity check - Who's available, who has competing priorities
3. (20 min) Walk the backlog top-down - For each item: clarify, estimate, commit or defer. Stop when capacity is full.
4. (5 min) Identify risks and dependencies
5. (5 min) Confirm sprint goal in one sentence

Facilitation tips:

• If estimation debates exceed 2 minutes per item, take it offline
• Use async estimation (planning poker via Slack bot) before the meeting to pre-align and reduce live debate
• The sprint goal should be writable on a sticky note - if it's a paragraph, it's too vague

Retrospective (sync version)

Purpose: Reflect on what went well, what didn't, and commit to improvements.

Duration: 30-45 minutes

Pre-work: Use the async retro collection phase (see SKILL.md) to gather input before the meeting. The sync session focuses on theming and action items only.

Agenda:

1. (5 min) Review action items from last retro - Did we follow through?
2. (5 min) Present themes from async collection (facilitator)
3. (3 min) Dot-vote on themes (use a poll or Miro board)
4. (15 min) Discuss top 2-3 themes - Root cause, not blame
5. (10 min) Propose action items for each theme - Named owner, deadline
6. (2 min) Close - One word from each person on how they feel

Facilitation tips:

• Use a "no blame" ground rule: focus on systems and processes, not individuals
• If someone dominates, use round-robin: each person gets 1 minute per theme
• Rotate the facilitator role each retro to prevent staleness

All-hands / team sync

Purpose: Share updates, celebrate wins, and surface cross-team information.

Duration: 25 minutes max (if it needs more, it's too much content for one session)

Agenda:

1. (5 min) Wins and shoutouts - Celebrate shipped work and individual contributions
2. (10 min) Key updates - Only things that affect everyone; use the "so what?" test
3. (5 min) Q&A - Pre-collected questions (async) plus live questions
4. (5 min) Upcoming focus areas

Facilitation tips:

• Publish a written version of all updates before the meeting so attendees can read ahead. The live session is for Q&A and celebration, not information transfer.
• Make attendance optional for anyone who reads the written update
• Record it for async viewers - but always publish written notes too

1:1 meeting (manager-report)

Purpose: Support the individual, remove blockers, discuss growth.

Duration: 25-30 minutes, weekly or biweekly

Format:

• Maintain a shared running doc (both parties add topics throughout the week)
• Report's topics first (at least 50% of the time)
• Manager's topics second
• Last 5-10 minutes: career development, feedback, or general check-in

Topic categories to rotate through:

• Work: Current projects, blockers, priorities
• Team: Collaboration issues, process feedback
• Growth: Skills development, career goals, stretch opportunities
• Wellbeing: Workload, energy levels, remote work challenges

Facilitation tips:

• If the report has nothing to discuss, don't fill the time - cancel or shorten
• Take notes in the shared doc during the meeting
• Follow up on action items from last time before adding new ones
• For remote 1:1s: occasionally do a "walking 1:1" (audio only, both people walk) to break the screen fatigue pattern

Difficult conversation / conflict resolution

Purpose: Address a specific interpersonal or process conflict.

Duration: 30 minutes

Pre-work: The facilitator (often a neutral third party or manager) talks to each party separately to understand perspectives. Shares a brief, neutral framing doc before the meeting.

Structure:

1. (3 min) Ground rules: assume positive intent, speak from your perspective ("I" statements), focus on behavior not character
2. (5 min) Person A shares their perspective uninterrupted
3. (5 min) Person B shares their perspective uninterrupted
4. (2 min) Each person summarizes what they heard the other say
5. (10 min) Identify shared goals and specific points of disagreement
6. (5 min) Agree on concrete next steps and follow-up cadence

Facilitation tips:

• Never attempt this async - tone and nuance matter too much
• The facilitator's job is to keep the conversation safe, not to judge
• If emotions run high, call a 5-minute break rather than pushing through
• Document agreements and follow up in writing within 24 hours

---

Remote-specific facilitation challenges

Managing time zone spreads

• Rotate meeting times for recurring meetings so the same timezone doesn't always get the inconvenient slot
• Record meetings and share timestamped notes for async attendees
• For meetings spanning 5+ hour time zone differences: consider splitting into two sessions or moving to fully async

Handling video call fatigue

• Default to 25-minute meetings (not 30) and 50-minute meetings (not 60)
• Make cameras optional - engagement can be measured by participation, not faces
• Use collaborative docs instead of screen sharing where possible (everyone can read and edit simultaneously)
• Schedule meeting-free blocks and enforce them

Engaging quiet participants

• Use round-robin for important topics (everyone speaks once before anyone speaks twice)
• Pre-collect input async so quiet people have already contributed before the meeting
• Use chat/reactions for quick polls instead of asking "any objections?"
• Directly invite input: "Alex, you've worked on this area - what's your take?"

Dealing with poor connectivity

• Always have a dial-in phone number as backup
• Share the agenda doc as the "single source of truth" - if someone drops, they can follow along in the doc
• Summarize key points in chat as the meeting progresses
• For critical decisions: confirm in writing after the meeting, don't assume everyone heard everything