Engineering meetings have a bad reputation, and much of it is earned. Too many meetings are called when an async message would suffice, run without a clear purpose, and end without decisions or next steps. The people who attend feel their time was wasted. The people who called the meeting often didn’t accomplish what they intended.

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.