Engineering All-Hands That People Actually Want to Attend

The format, cadence, and content strategy behind engineering all-hands meetings with 94% attendance and positive sentiment, based on 2 years of iteration.

#all-hands#communication#transparency#engineering-culture#leadership
Cover image for the article: Engineering All-Hands That People Actually Want to Attend

Most engineering all-hands meetings are terrible. I know because I attended hundreds of them before I started running them, and I made mine terrible for the first year too. The format I'm about to describe took two years of iteration across teams of 30-80 engineers to develop. It consistently achieves 94% attendance (voluntary — nobody is required to attend) and 8.2/10 satisfaction scores. Here's the entire playbook.

Why Most All-Hands Fail

After surveying 200+ engineers at three companies about all-hands meetings, the complaints were consistent:

ComplaintFrequencyRoot Cause
"It's just status updates I already know"78%Content duplicates Slack/Jira
"Too long, loses energy after 30 min"65%No time boundaries
"Leadership talks, we listen"58%One-directional communication
"Nothing changes based on what we say"52%No feedback loop
"Doesn't feel relevant to my work"45%Same format for all team sizes
"Could've been an email"42%No interactivity

The core insight: an all-hands that only informs is an email with forced synchronous attendance. The meeting must do something that async communication cannot.

The Format: 45 Minutes, Four Segments

After testing formats ranging from 25 minutes to 90 minutes, 45 minutes is the sweet spot. Attention drops precipitously after 50 minutes, and under 35 minutes doesn't allow for meaningful Q&A.

┌─────────────────────────────────────────────────┐
│ Segment 1: Context (8 min)                      │
│   - What changed since last all-hands           │
│   - Business context engineers don't have        │
│   - Upcoming decisions that need input           │
├─────────────────────────────────────────────────┤
│ Segment 2: Deep Dive (15 min)                   │
│   - One team presents something interesting      │
│   - Technical, not status                        │
│   - "Here's what we learned"                    │
├─────────────────────────────────────────────────┤
│ Segment 3: Open Forum (15 min)                  │
│   - Anonymous questions (submitted in advance)   │
│   - Live questions                              │
│   - Hard questions answered honestly             │
├─────────────────────────────────────────────────┤
│ Segment 4: Shoutouts + Close (7 min)            │
│   - Peer recognition (nominated by anyone)       │
│   - One thing to remember                       │
│   - Preview of next all-hands topic             │
└─────────────────────────────────────────────────┘

Segment 1: Context (8 minutes)

This is NOT a status update. Engineers already know what shipped — they shipped it. This segment provides context they lack:

What to include:

  • Revenue numbers and customer feedback (engineers rarely see this)
  • Hiring pipeline status and upcoming team changes
  • Executive decisions that affect engineering (budget changes, strategic shifts)
  • Industry context that influences our technical direction

What to exclude:

  • Sprint summaries (that's what standups and demos are for)
  • Detailed project updates (async via written updates)
  • Anything available in Slack or project tools

Example script: "Last month our infrastructure costs grew 12% while traffic grew 8%. That gap matters because we have a $2M annual budget and we're tracking to exceed it by Q3. The cost optimization efforts from Platform team are directly tied to whether we can fund the two new hires we planned. Context: this is why I'm asking every team to include cost-per-request in their service scorecards."

Segment 2: Deep Dive (15 minutes)

A rotating team presents something technically interesting they learned or built. The key rule: this must teach something, not report progress.

Good topics:

  • "We tried X and it failed. Here's why and what we learned."
  • "Here's a technique we discovered that could help other teams."
  • "We made an architecture decision. Here's our reasoning and the tradeoffs."
  • "We benchmarked three approaches. Here are the surprising results."

Bad topics:

  • "Here's what our team shipped this quarter."
  • "Let me walk you through our roadmap."
  • "Here's a demo of our new feature."

We maintain a rotation schedule. Every team presents once per quarter. Teams volunteer for slots — we've never had trouble filling them because the format rewards interesting content, not polished presentations.

Segment 3: Open Forum (15 minutes)

This is where the meeting earns its existence. Two mechanisms:

Anonymous questions (submitted 48 hours in advance): We use a simple form (Google Forms or Slido) where anyone can submit questions anonymously. I review them before the meeting and prepare honest answers. The anonymity is critical — people ask what they're really thinking.

Questions we've answered honestly:

  • "Are there going to be layoffs?"
  • "Why did [person] leave?"
  • "The new architecture seems over-engineered. Did anyone push back?"
  • "Leadership says X but does Y. Which is it?"

Live questions: After addressing pre-submitted questions, we open the floor. Having addressed hard anonymous questions first establishes that no topic is off-limits, which makes people braver in live Q&A.

The commitment: Every question gets an answer. If I don't know, I say "I don't know, I'll find out by [date]." If I can't share, I say "I can't share details about that because [reason], but here's what I can say." Never dodge.

Segment 4: Shoutouts and Close (7 minutes)

Peer recognition submitted through a form throughout the two-week cycle. Anyone can nominate anyone. We read 3-5 shoutouts per meeting:

  • "Shoutout to Maya for debugging the payment outage at 2 AM on Saturday"
  • "Shoutout to the Infrastructure team for the new CI pipeline — builds went from 12 minutes to 4"
  • "Shoutout to James for mentoring three junior engineers simultaneously"

Then one closing line — the single most important thing to remember. And a preview of next meeting's deep dive topic so people can prepare questions.

Cadence and Timing

Team SizeCadenceDay/Time
20-40Every 2 weeksTuesday 11 AM
40-80Every 2 weeksWednesday 10 AM
80+Monthly (with written async updates between)First Thursday

Why Tuesday/Wednesday at 10-11 AM: Avoids Monday chaos and Friday disengagement. Late morning means people are settled but not yet in deep work mode. We tested multiple slots — this window had the highest voluntary attendance.

Why every 2 weeks: Weekly is too frequent (not enough changes to discuss). Monthly is too infrequent (people feel disconnected). Bi-weekly creates rhythm without fatigue.

The Written Companion

Every all-hands has a written companion document posted 24 hours after the meeting:

# Engineering All-Hands - April 8, 2026

## Key Decisions & Context
- Infrastructure budget tracking 12% over. Cost optimization priority increased.
- Two new hires approved for Platform team, starting May hiring process.
- Product strategy update: B2B pivot confirmed for Q3.

## Deep Dive Summary
**Team**: Search & Relevance
**Topic**: Why we're moving from Elasticsearch to a hybrid approach
**Key Takeaway**: Vector search handles 40% of queries better, but ES
still wins for structured filters. Hybrid gives 23% improvement.
[Link to full technical write-up]

## Q&A Answers
- Q: "Are there going to be layoffs?" A: No. [full context in doc]
- Q: "Why is the migration timeline slipping?" A: [honest explanation]
- [3 more Q&As]

## Shoutouts
- Maya: Incident response excellence during payment outage
- Infrastructure team: CI pipeline optimization (12min → 4min)

## Action Items
- [ ] Cost-per-request scorecards due by April 22
- [ ] Deep dive nominations for May meeting open

This serves three purposes:

  1. People who missed the meeting stay informed
  2. Answers are documented and referenceable
  3. It creates accountability for follow-up items

Measuring Success

We track these metrics quarterly:

MetricTargetCurrent
Voluntary attendance> 85%94%
Post-meeting satisfaction (1-10)> 78.2
"I learned something new"> 70%82%
"My questions were addressed"> 80%88%
Anonymous question volume> 5/meeting12/meeting
Deep dive volunteer rate100% slots filled150% (waitlist)

All-Hands Metrics Over Time

Anti-Patterns to Avoid

1. The Victory Lap All-Hands: Every segment is about wins. Engineers see through this — they know what's not working. Address challenges alongside successes.

2. The CEO Guest Star: Bringing in executives who deliver prepared remarks kills the intimacy. If the CEO joins, they should answer questions, not present.

3. The Surprise Announcement: Major changes (reorgs, strategy shifts, departures) should be communicated directly to affected teams first, never announced at all-hands first.

4. The Running-Over Meeting: If you go to 50 minutes once, you'll go to 55 next time. Hard-stop at 45 minutes. People trust a meeting that respects their time.

5. The No-Follow-Up Meeting: If you say "I'll find out" and don't post the answer within a week, you've taught everyone that asking questions is pointless.

Starting From Zero

If your current all-hands is broken, don't try to fix it incrementally. Cancel it. Wait two weeks. Then announce a new format with a different name ("Engineering Forum" or "Team Sync") and start fresh with this format. The rebrand signals that this is genuinely different.

First meeting: be vulnerable. Say "Our previous format wasn't working. Here's what we're trying. We'll iterate based on your feedback." Then deliver on the format and follow up on feedback.

Key Takeaways

  1. An all-hands must do what async cannot — if it could be an email, it shouldn't be a meeting. Interactivity, Q&A, and real-time discussion justify synchronous time.

  2. 45 minutes, four segments, hard stop — energy dies after 50 minutes. The format creates predictability, which builds attendance habits.

  3. Anonymous questions are the superpower — people ask what they're really thinking when identity is removed. Answer every question honestly and you'll build extraordinary trust.

  4. Teach, don't report — the deep dive segment should make attendees think "I'm glad I was here" because they learned something useful.

  5. The written companion creates accountability — documenting answers and action items means follow-through is visible and leaders are held to their commitments.

  6. Measure and iterate — quarterly satisfaction surveys identify what's working and what's stale. Formats that don't evolve lose engagement over time.

The best all-hands I've ever attended made me feel informed, heard, and connected to the broader team. That's the bar. Everything in this format serves those three outcomes.

Comments

    No comments yet. Be the first to share your thoughts.