This post is specifically about the meetings that matter at the staff engineer level: design reviews, architectural decision meetings, technical alignment sessions, and cross-team coordination. These are meetings worth doing well — they’re how complex technical work gets coordinated. The goal is not to eliminate them but to make them actually work.

The First Question: Should This Be a Meeting?

Before scheduling anything, ask whether a meeting is actually the right format. The most valuable thing you can do to improve your meeting culture is to cancel the meetings that shouldn’t exist.

Hold a meeting when:

• A decision requires input from multiple perspectives that are hard to capture async
• There’s genuine ambiguity that benefits from real-time discussion
• The stakes are high enough that you need to build shared understanding, not just transmit information
• You need to detect and resolve conflicting positions in real time

Use async instead when:

• You’re sharing information (a design doc, status update, proposal)
• You need feedback but don’t need it in real time
• The decision can be made by one person with input from others
• The question can be answered in writing

The “let’s get everyone together to discuss” instinct often reflects discomfort with async alignment rather than genuine need for synchronous discussion. Getting comfortable with async-first is one of the highest-leverage changes an engineering team can make.

Define the Purpose Before Scheduling

Every meeting should have a clear, specific purpose that answers one question: what decision will be made or what shared understanding will be built by the end?

Vague purposes produce vague meetings:

• ❌ “Discuss the database migration”
• ✅ “Decide between Option A and Option B for the migration approach, given the constraints from the platform team”

The purpose determines the invite list, the required pre-read, and the structure. If you can’t write a clear purpose, the meeting isn’t ready to be scheduled.

Pre-Reads Are Not Optional

For any meeting with a decision component, a pre-read is required. The pre-read might be a design doc, a proposal with alternatives, or a brief written summary of the options being evaluated.

The pre-read serves several functions:

• People arrive with context, so you’re not spending the first 20 minutes establishing background
• Written proposals surface questions before the meeting, which improves discussion quality
• It forces the meeting organizer to clarify their own thinking before asking others to engage

A meeting where everyone is seeing the proposal for the first time is not a decision meeting — it’s an information transfer session that should have been an email.

How to enforce pre-reads: Include the pre-read link in the invite with an explicit note: “Please review [link] before the meeting. The first 5 minutes will not be used for summary.” When you actually skip the summary, people learn to read the pre-read.

The Right Invite List

Invite size has a nonlinear effect on meeting quality. Every additional person increases the time required, reduces the percentage of people actively contributing, and increases the chance that no one speaks up because everyone is waiting for someone else to.

For decision meetings:

• Required: The people whose input is needed to make a good decision, and the person who will make the final call
• Optional / silent observer: People who need to know the outcome but don’t need to weigh in

For technical alignment meetings:

• Include one representative from each affected team
• Avoid inviting multiple people from the same team to represent the same perspective

If you’re not sure whether someone should be included, ask yourself: “Does this person need to hear the discussion live, or would a written summary of the outcome be sufficient?” If written summary works, make them optional.

Meeting Structure: The Three Parts

Almost every effective engineering meeting follows the same structure:

1. Setup (5–10 minutes) Restate the purpose and desired outcome. Reference the pre-read. Name any constraints that shape the decision. Answer brief clarifying questions about context — but not design questions, those come in part 2.

The setup should be short. If you’ve sent a good pre-read and people have read it, you need to orient the group, not re-present the material.

2. Discussion (majority of time) This is where the actual work happens. Structure it to surface disagreement and resolve it — not to achieve surface-level consensus while leaving real disagreements unaddressed.

Techniques that work:

• Ask for objections specifically, not just agreement: “Does anyone see a risk with option A that we haven’t addressed?”
• Name the crux when discussion is going in circles: “It sounds like the disagreement comes down to how we weigh X versus Y — is that right?”
• Use quiet rounds for decisions with power dynamics: ask everyone to write down their preference before anyone speaks aloud

3. Close (5–10 minutes) Before leaving the meeting room (physical or virtual), capture:

• What was decided, specifically
• What was explicitly not decided (just as important)
• Next steps with assigned owners and deadlines
• Who needs to be informed of the outcome

If you can’t state the decision clearly at the end of the meeting, either more discussion is needed or the decision was already implicit and you’re doing alignment theater. Reopen the discussion.

Running Design Reviews

Design reviews are a specific type of meeting with their own patterns. The purpose: to improve the design before implementation begins, not to approve it.

What makes design reviews fail:

• The author presents the design and asks “any questions?” — this produces polite nodding, not useful feedback
• Reviewers engage with implementation details instead of design decisions
• No one challenges the fundamental framing because they don’t want to be difficult

What makes them work:

• Assign reviewers specific review areas in advance (“focus on security model,” “focus on failure modes and recovery”)
• Ask for the hardest objections explicitly: “What would need to be true for this design to fail?”
• Separate “this is wrong” from “I would have done it differently” — both are valid but require different responses

The best design reviews improve designs that were already good. The output is a better document, not just a greenlighted one.

Making Decisions in Meetings

Many meetings end without a decision because the decision-making structure was never established. Before the discussion starts, clarify:

• Who makes the final call? One person, typically the tech lead or owner of the system. Decisions made “by the group” with no named owner tend to not stick or get relitigated.
• What’s the decision-making process? Is this “advice process” (the owner decides after hearing input) or consensus (everyone must agree)? Consensus is rarely appropriate for technical decisions at scale.
• What are the constraints that can’t be negotiated? If some options are off the table, say so early — it prevents people from investing energy in proposals that won’t be considered.

When you reach a decision, state it out loud clearly before moving on. “So the decision is X. [Owner] will proceed with that approach. Does anyone have a blocking concern we haven’t addressed?” Getting explicit confirmation closes the loop.

The Meeting Note

Someone needs to take a decision-focused note during the meeting. Not a transcript — a record of what was decided, what was explicitly deferred, and what the next steps are.

A good meeting note:

Meeting: [title and date]
Attendees: [names]
Decision: [specific, unambiguous statement]
Not decided: [things that were discussed but explicitly deferred]
Next steps:
  - [Owner 1]: [action item] by [date]
  - [Owner 2]: [action item] by [date]
To notify: [list of people to inform of the outcome]

Send it within a few hours of the meeting to everyone who attended plus anyone who needs to know the outcome. This surfaces misunderstandings before they calcify and creates a durable record for anyone who questions the decision later.

Recurring Engineering Meetings

The recurring meetings staff engineers typically own or participate in deserve specific attention:

Architecture review: Should surface the highest-risk or most consequential design decisions being made. Requires mandatory pre-reads. Keeps attendance tight. Produces decisions, not just discussions.

Tech lead sync: Horizontal alignment across tech leads on cross-cutting concerns. Stays at the dependency and coordination level — not a status report meeting.

Incident review / postmortem: Focused on systemic improvement, not blame. Produces action items with owners. Published to the organization.

Engineering all-hands: Information sharing, not decisions. If you’re making decisions in all-hands, you have the wrong format.

Every recurring meeting should be audited quarterly: Is this meeting still worth the time it takes? Has the problem it solves changed? Could it move to less frequently or to async?

What Staff Engineers Do Differently

The difference between staff engineers and senior engineers in meetings is often not what they know — it’s how they manage the room.

They name the thing: “We’ve been in this discussion for 20 minutes and I think we’re stuck on a false dichotomy. The actual question is X.” Naming what’s happening in a meeting is a skill.

They call for closure: “We have 10 minutes left. I want to make sure we come out of this with a decision. Can we commit to option A or B, or is there a third path someone wants to propose?” Pushing toward closure is uncomfortable but necessary.

They distinguish levels: “This is an implementation question that we don’t need to decide in this room. Can we table it and focus on the architectural decision?”

They protect the meeting’s purpose: When a meeting drifts toward a different topic, staff engineers redirect it. “That’s worth discussing, but it’s a different question. Can we note it and come back after we’ve addressed what we’re here for?”

None of this requires formal authority. It requires clarity about what the meeting is for and the willingness to say so.

When done poorly, they’re ignored, debated endlessly, or written as formalities after the decision is already made.

This post is about writing TDDs that work: getting the right people to the right decision with minimum friction.

When to Write a TDD (and When Not To)

Not every technical change needs a design document. Writing an unnecessary TDD creates process overhead without benefit. A useful heuristic:

Write a TDD when:

• The change affects more than one team or system
• There are multiple viable approaches with real trade-offs
• The change is hard or expensive to reverse
• The implementation will take more than 1–2 weeks
• Stakeholders outside engineering need to understand the approach

Don’t write a TDD when:

• The approach is already obvious to everyone involved
• It’s a well-understood pattern you’ve applied before
• The cost of getting it wrong is low and easy to fix
• You’re implementing exactly what was already decided in a previous TDD

The signal for skipping a TDD: if you sat down to write one and there’s nothing non-obvious to decide, you don’t need it.

One exception: when you’re new to a team, writing a TDD even for straightforward work builds trust and gives reviewers a window into your thinking. The value there isn’t the document — it’s the review conversation.

The Sections That Actually Matter

Design documents have a lot of conventional sections. Most of them are useful. A few are often missing.

Problem Statement

This section is frequently too thin. Engineers jump to the solution before establishing the problem clearly enough. A strong problem statement answers:

• What is broken, missing, or insufficient today?
• What is the impact of the current state? (User impact, system impact, operational cost)
• What evidence establishes that this problem is real and worth solving?
• What is the scope of the problem? (One team? The whole platform? A specific user segment?)

If readers don’t understand the problem deeply, they can’t evaluate proposed solutions. Invest more time here than you think you need.

Goals and Non-Goals

Goals should be specific and testable, not vague aspirations. “Improve reliability” is not a goal. “Reduce p99 latency for the checkout API from 2s to 400ms under 1,000 RPS” is a goal.

Non-goals are equally important and often omitted. Non-goals:

• Set scope explicitly (prevents the review from expanding into adjacent problems)
• Signal that you’ve thought about what you’re deliberately not solving
• Protect the design from being evaluated against requirements you never intended to meet

Write non-goals as explicit statements, not silence. “We are not solving X in this proposal” is useful. Leaving X unmentioned is not.

Background and Context

What does a reviewer need to know to evaluate this document who isn’t deep in this area? Include:

• How the relevant systems currently work (high-level)
• Prior attempts to solve this problem and why they failed or were abandoned
• Constraints that shape the solution space (regulatory, contractual, legacy dependencies)
• Why now — what changed that makes this worth solving today

This section is easy to underwrite if you assume shared context. Assume less than you think you should.

Proposed Solution

The meat of the document. Structure it to answer:

• What is the approach at a high level?
• What are the key components or changes?
• How does it satisfy each of the stated goals?
• How do the pieces interact? (A sequence diagram or system diagram often conveys this better than prose)

Resist the urge to write this section before the others. Engineers who jump to the solution first often write problem statements that are shaped to justify the solution they already want. Write the problem clearly first, then write the solution.

Alternatives Considered

This section is not filler. It’s evidence that you explored the space seriously.

For each alternative:

• What is the approach?
• Why might it be preferable?
• Why are you recommending against it?

The alternatives section also protects you. When a reviewer proposes what you considered and rejected, you can point here instead of relitigating it in the review. It also signals to leadership that you didn’t pick the first thing that worked.

Don’t list alternatives you didn’t seriously consider. One sentence strawmen waste everyone’s time.

Risks and Open Questions

Name the risks explicitly:

• What assumptions does this design rely on?
• What could go wrong during implementation?
• What dependencies could block or invalidate this approach?
• What happens to existing users/systems during the transition?

Open questions deserve a section because they’re honest. Not everything is decided when you write the document. Naming open questions tells reviewers where you need input, and it triggers the right conversations.

Mark open questions with an owner when possible: “Decision needed from platform team: [question].” Unowned open questions don’t get resolved.

Implementation Plan and Rollout

Cover:

• What’s the phased rollout plan? (Especially important for changes with production impact)
• What’s the rollback plan?
• What observability will you add to know if it’s working?
• What’s the migration path for existing data or users?
• What’s the timeline and what are the dependencies?

The implementation section separates documents that drive action from documents that sit in a wiki. Reviewers want to know not just what you’re building but how you’ll build it safely.

Writing for the Right Audience

Most TDDs have multiple audiences with different needs:

Technical reviewers (the engineers who will implement this or maintain related systems) need the depth: specific design choices, data models, API contracts, failure modes.

Cross-functional stakeholders (product, data, security, legal) need the impact and the trade-offs, not the implementation details. If you’re sharing a doc with this group, a one-page executive summary at the top saves everyone time.

Future engineers reading this six months later need context they don’t have: why was this chosen over alternatives, what was the state of the system at the time, what constraints applied.

Write with all three in mind. Structure the document so reviewers can navigate to the parts relevant to them. Bury the deeply technical detail in sections that cross-functional stakeholders can skip.

The Review Process

A TDD with no review process is a document, not a decision mechanism. Structure the review deliberately.

Set a deadline. “Please review by Friday EOD” produces responses. “Let me know when you’ve had a chance to look” produces silence.

Designate required reviewers vs. optional. Required reviewers must sign off. Optional reviewers get to weigh in but can’t block. Be explicit about who is in each category.

Time-box the comment period. Two weeks of open-ended review often results in more confusion than a focused 3-day window. Scope creep in review is a real problem.

Hold a synchronous review meeting for high-stakes designs. Async comment threads are efficient for small details. For designs that affect multiple teams or have significant architectural implications, a 1-hour synchronous review often resolves more than 2 weeks of async back-and-forth.

Distinguish blocking feedback from non-blocking. Reviewers should label comments: “blocking” (must be addressed before approval), “suggestion” (take or leave), “question” (just curious). This prevents good-faith questions from becoming approval blockers.

Common Failure Modes

Written after the decision. The TDD is created to document what’s already been decided, not to make the decision. Reviewers are asked to ratify, not evaluate. This produces rubber-stamp reviews and skips the alignment that makes TDDs valuable. The fix: write the TDD before writing code, not after.

Too long to read. A 30-page design document gets skimmed or skipped. If your TDD is over 10 pages, it’s probably covering too much scope or including implementation details that belong in code comments. Aim for 3–6 pages of substantive content.

Pitched at the wrong level. A highly technical document sent to a VP-level audience, or a high-level document sent to engineers who need to implement it. Write the right document for the right audience, or write a document with a layered structure.

Alternatives section that’s a formality. One-line alternatives that obviously weren’t seriously considered signal that you’ve already decided and are going through the motions. If you can’t write a genuine case for each alternative, remove it — or go back and do the exploration.

Never updated. The design changes during implementation but the document doesn’t. Later engineers read the original document and draw wrong conclusions. Either keep the document updated or add a prominent note: “Implementation diverged from this design in the following ways: [link to followup doc].”

Living Documents vs. Archived Decisions

Some TDDs stay relevant long after implementation — architectural decisions, data model choices, API contracts. These should be kept in a stable location and updated when the design evolves.

Others are point-in-time decisions that become irrelevant after implementation. For these, mark them clearly: “This design was implemented in Q3 2026. The system now works as described. For current architecture, see [link].”

The worst outcome is a design document that describes something that no longer exists, sitting in the same location as current documentation with no indication that it’s outdated.

A Minimal TDD Template

Title: [What this designs]
Status: Draft / In Review / Approved / Implemented
Author: [Name]
Reviewers: [Required] / [Optional]
Created: [Date]
Last Updated: [Date]

---

## Problem Statement
[What is broken, missing, or insufficient? What's the impact?]

## Goals
- [Specific, testable goal 1]
- [Specific, testable goal 2]

## Non-Goals
- [Explicitly out of scope: X]
- [Explicitly out of scope: Y]

## Background
[Context reviewers need. Prior attempts. Constraints.]

## Proposed Solution
[High-level approach. Key components. How it satisfies the goals.]

## Alternatives Considered
### Option A: [Name]
[Description, pros, why rejected]

### Option B: [Name]
[Description, pros, why rejected]

## Risks
- [Risk 1: impact, likelihood, mitigation]
- [Risk 2: ...]

## Open Questions
- [Question] — Owner: [Name], Needed by: [Date]

## Implementation Plan
- Phase 1: [...]
- Phase 2: [...]
- Rollback plan: [...]
- Observability: [...]

The template is a starting point. Add sections when your design needs them. Remove sections when they’d be empty. A TDD that follows a template perfectly but says nothing useful is worse than no TDD at all.