Meetings#

Meetings are the most expensive activity in engineering organisations. A one-hour meeting with six engineers costs six hours of engineering time plus the context-switch cost on either side. Use them wisely — they’re a powerful tool when needed and a destructive waste when not.

When NOT to Have a Meeting#

Before scheduling a meeting, ask: “Could this be an async message, document, or decision?”

The “No Meeting” Test#

If you can’t fill in ALL of these, cancel the meeting:

1. Goal — what will be different after this meeting?
2. Attendees — who is essential (not just “nice to have”)?
3. Preparation — what should people read/do beforehand?
4. Output — what artifact will result (decision, action items, document)?

Running Effective Meetings#

Before the Meeting#

During the Meeting#

flowchart LR
    A[Open: state goal<br>2 min] --> B[Discuss: work through agenda<br>bulk of time]
    B --> C[Decide: confirm decisions<br>5 min]
    C --> D[Close: action items + owners<br>3 min]

After the Meeting#

• Post written summary within 1 hour (decisions, actions, owners, deadlines)
• Share with attendees AND relevant people who weren’t there
• Follow up on action items in the next meeting or async check-in

Facilitation Techniques#

Facilitation is the skill of running a meeting so everyone contributes and the group reaches a useful outcome. It’s separate from participating — the facilitator manages process, not content.

Making Space for Quiet Voices#

Managing Dominant Speakers#

• “Thank you, [Name]. Let’s hear from others on this.”
• “I want to make sure we get all perspectives. Who hasn’t spoken yet?”
• “Let’s use a round-robin for this question.”
• Private conversation after: “Your input is valuable, but others are being squeezed out. Can you hold back and let others go first?”

Managing Conflict in Meetings#

Decision-Making in Groups#

Groups default to discussion without decision. Use explicit decision-making processes.

Decision Methods#

RACI for Meeting Decisions#

Before a discussion that will end in a decision, clarify:

Stand-ups#

Daily stand-ups are the most common — and most commonly dysfunctional — engineering meeting.

Stand-up Done Right#

Stand-up Alternatives#

Retrospectives#

Retros are how teams improve their process. Without them, the same problems repeat indefinitely.

Retro Structure#

flowchart LR
    A[Set the stage<br>5 min] --> B[Gather data<br>10 min]
    B --> C[Generate insights<br>15 min]
    C --> D[Decide actions<br>10 min]
    D --> E[Close<br>5 min]

Common Retro Formats#

Retro Anti-Patterns#

Meeting Hygiene Checklist#

Before every meeting you schedule:

• Is a meeting the best format for this? (or could it be async)
• Is the goal clear and specific?
• Are only essential people invited?
• Is pre-reading shared in advance?
• Is the agenda time-boxed?
• Is the decision-maker identified?
• Is someone assigned to capture notes and actions?

Key Takeaways#

• The best meeting is often no meeting — async first, synchronous when needed
• Every meeting needs a goal, an agenda, and a note-taker
• Facilitation is a distinct skill from participation — learn both
• Use explicit decision methods; groups default to discussion without resolution
• Stand-ups should surface blockers, not recite status
• Retros only work if actions have owners, deadlines, and follow-up
• End every meeting with: who does what by when