# Meeting Architecture

> Meeting Architecture

- Skill: `sairam0424/meeting-architecture` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sairam0424/meeting-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sairam0424/meeting-architecture/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: sairam0424 (https://skillmd.com/u/sairam0424)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sairam0424/meeting-architecture

---


# Meeting Architecture

## When this skill activates

This skill activates when designing effective meetings, implementing async-first communication patterns, optimizing standups, documenting decisions, creating RFC processes, or facilitating remote meetings. It applies to tech leads, engineering managers, and senior engineers responsible for team communication effectiveness.

## Mandatory actions when this skill is active

### Before scheduling any meeting

1. **Apply the async-first test** — Can this be an email, Slack message, document, or recorded video? Only schedule a synchronous meeting if you need real-time discussion, debate, or decision-making.
2. **Define the meeting purpose** — Is it informational (status update), collaborative (brainstorming), or decisional (approve/reject proposal)? Different purposes require different formats.
3. **Identify required vs optional attendees** — Required: people who must participate for the meeting to succeed. Optional: people who benefit from being there but aren't essential. Respect people's time.
4. **Create a clear agenda** — No agenda = no meeting. Agenda should include: topics, time allocation, desired outcomes, and pre-reads. Send agenda 24 hours in advance.

### During meeting design

#### Meeting Type Catalog

**1. Daily Standup (15 minutes max)**
- **Purpose**: Synchronize team, surface blockers, maintain momentum.
- **Format**: Each person answers: (1) What did I accomplish yesterday? (2) What am I working on today? (3) Am I blocked?
- **Optimizations**:
  - Keep it to 15 minutes. If you need more time, the team is too big or the updates are too detailed.
  - Do it async if possible (Slack standup bot, Geekbot, GitHub comments on project board).
  - Timebox each person to 1-2 minutes. Use a timer.
  - Blockers get discussed after standup, not during. Don't derail everyone's focus.
- **Pitfall**: Standup becomes a status report to the manager. It should be peer-to-peer synchronization, not upward reporting.

**2. Sprint Planning (1-2 hours)**
- **Purpose**: Commit to work for the upcoming sprint.
- **Format**: Review backlog, prioritize, estimate, assign ownership, identify dependencies.
- **Pre-work**: Product or tech lead preps the backlog. Engineers review tickets ahead of time. Don't do backlog grooming during sprint planning.
- **Optimizations**:
  - Timebox story estimation. Use t-shirt sizes (S/M/L) or Fibonacci (1/2/3/5/8) to avoid false precision.
  - Identify blockers early. If a task depends on another team, escalate before the sprint starts.
  - Set a realistic capacity. Don't overcommit. Leave 20% buffer for unplanned work (bugs, support, incidents).
- **Pitfall**: Spending 30 minutes debating whether a task is a 3 or a 5. Estimates are guesses. Move on.

**3. Retrospective (45-60 minutes)**
- **Purpose**: Reflect on what went well, what didn't, and how to improve.
- **Format**: What went well? What went poorly? What should we start/stop/continue doing?
- **Facilitation**:
  - Everyone contributes. Silence from some people means they're not engaged or don't feel safe.
  - Focus on systems, not individuals. "Code reviews are too slow" is better than "Alice didn't review my PR."
  - Action items must have owners and deadlines. Otherwise they're wishes, not commitments.
- **Optimizations**:
  - Rotate facilitator. Prevents one person from dominating.
  - Use techniques like Start/Stop/Continue, 4Ls (Liked/Learned/Lacked/Longed For), or Rose/Bud/Thorn.
  - Review action items from the previous retro. Did we follow through? If not, why?
- **Pitfall**: Retrospectives devolve into venting sessions. Keep it constructive.

**4. Design Review / Architecture Review (60-90 minutes)**
- **Purpose**: Vet technical designs before implementation. Catch issues early.
- **Format**: Presenter shares design doc (sent 24-48 hours in advance). Team probes assumptions, identifies edge cases, suggests alternatives.
- **Pre-work**: Attendees read the design doc before the meeting. Don't use meeting time for reading.
- **Optimizations**:
  - Use a design doc template: problem statement, requirements, proposed solution, alternatives considered, tradeoffs, open questions.
  - Assign a devil's advocate. Their job is to poke holes. Prevents groupthink.
  - Document decisions in the design doc during the meeting. Don't rely on memory.
- **Pitfall**: Rubber-stamping designs that are already implemented. Design reviews should happen before code is written, not after.

**5. Incident Postmortem (60 minutes)**
- **Purpose**: Learn from incidents, identify systemic improvements.
- **Format**: Timeline, root cause analysis, what went well, what went poorly, action items.
- **Facilitation**:
  - Blameless. Focus on systems, not individuals.
  - Use the Five Whys to get to root cause.
  - Every action item needs an owner and a deadline.
- **Optimizations**:
  - Share postmortem document 24 hours before the meeting. Use meeting time for discussion, not writing.
  - Invite all incident responders + relevant stakeholders.
  - Timebox to 60 minutes. If you can't finish, schedule a follow-up.
- **Pitfall**: Postmortems that generate 15 action items but complete zero. Prioritize. Pick the top 3 and execute.

**6. 1:1s (30 minutes, weekly or bi-weekly)**
- **Purpose**: Manager-engineer relationship building, career development, feedback, unblocking.
- **Format**: Open agenda. Employee drives the conversation. Manager listens, coaches, provides context.
- **Optimizations**:
  - Don't use 1:1s for status updates. That's what standups and project boards are for.
  - Ask open-ended questions: "What's on your mind?" "What's frustrating you?" "What do you need from me?"
  - Take notes. Reference previous 1:1s. Show that you remember and care.
  - Cancel other meetings, not 1:1s. 1:1s are sacred.
- **Pitfall**: Manager dominates the conversation. The 1:1 is for the employee, not the manager.

**7. RFC (Request for Comments) Review (Async + Optional Sync Meeting)**
- **Purpose**: Propose architectural changes, gather feedback, build consensus.
- **Format**: Author writes RFC document (problem, proposal, alternatives, tradeoffs). Team comments asynchronously. Optional sync meeting to resolve open questions.
- **Optimizations**:
  - Set a comment deadline (e.g., 5 business days). After deadline, author addresses feedback and makes a decision.
  - Use a template. Consistency reduces cognitive load.
  - Distinguish between blocking concerns (correctness, security) and non-blocking suggestions (style, minor optimizations).
- **Pitfall**: RFCs that linger for weeks with no decision. Set a decision deadline and stick to it.

#### Async-First Communication Patterns

- **Default to async** — Status updates, announcements, design proposals, and decisions should be written and shared asynchronously. Reserve sync meetings for real-time collaboration.
- **Use threads, not channels** — In Slack or Teams, use threads for discussions. Keeps channels scannable. Main channel is for announcements, threads are for details.
- **Document decisions publicly** — Every significant decision (architectural choice, roadmap change, policy update) gets written down in a shared doc or wiki. Don't let decisions live only in someone's head or in a Slack thread.
- **Record meetings** — For all-hands, demos, or important discussions, record the meeting and share the link. Accommodates different time zones and allows people to catch up asynchronously.
- **Set response time expectations** — Async doesn't mean "respond whenever." Set norms: Slack messages within 4 hours during work hours, emails within 24 hours, RFCs within 5 days.

#### Decision Documentation

- **Use Architecture Decision Records (ADRs)** — Every significant architectural decision gets a lightweight ADR:
  - **Title**: Short description (e.g., "Use Postgres for primary datastore")
  - **Context**: What's the situation?
  - **Decision**: What did we decide?
  - **Consequences**: What are the tradeoffs?
  - **Alternatives Considered**: What else did we evaluate?
- **Maintain a decision log** — Store ADRs in the repo (`docs/adr/`) or wiki. Version control ensures decisions are traceable.
- **Link decisions to code** — In PRs, reference the ADR. Future engineers will thank you.

#### Remote Meeting Facilitation

- **Video on by default** — Encourages engagement. People are less likely to multitask when video is on.
- **Use collaborative tools** — Miro, Figma, Google Docs for real-time collaboration. Screen sharing alone is passive.
- **Timebox discussions** — Use a timer. When time's up, move on. Prevents bikeshedding.
- **Mute when not speaking** — Reduces background noise. Unmute to contribute.
- **Use breakout rooms for large meetings** — If you have >8 people, break into smaller groups for brainstorming. Reconvene to share findings.

### After meetings

- **Publish meeting notes within 2 hours** — Key decisions, action items, owners, deadlines. Share in the team channel or wiki.
- **Track action items to completion** — Review action items in the next meeting. If they're not getting done, either they weren't important or there's a resourcing issue.
- **Measure meeting effectiveness** — Periodically survey the team: "Are meetings productive? Too many? Too few?" Course-correct based on feedback.
- **Cancel recurring meetings that lost their purpose** — If a meeting becomes a status update or no one has updates, cancel it. Don't let zombie meetings linger.

## Self-check before task completion

- [ ] Meeting passes the async-first test (can't be an email or doc)
- [ ] Agenda is created and shared 24 hours in advance with topics, time allocation, and desired outcomes
- [ ] Required vs optional attendees are explicitly identified
- [ ] Meeting type is appropriate for the goal (standup, planning, retro, design review, 1:1)
- [ ] Design reviews and RFC reviews require pre-reading; meeting time is for discussion, not reading
- [ ] Decisions are documented using ADRs or decision logs and shared publicly
- [ ] Meeting notes with action items, owners, and deadlines are published within 2 hours
- [ ] Recurring meetings are reviewed quarterly and canceled if they've lost their purpose