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.

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:
| Complaint | Frequency | Root 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 Size | Cadence | Day/Time |
|---|---|---|
| 20-40 | Every 2 weeks | Tuesday 11 AM |
| 40-80 | Every 2 weeks | Wednesday 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:
- People who missed the meeting stay informed
- Answers are documented and referenceable
- It creates accountability for follow-up items
Measuring Success
We track these metrics quarterly:
| Metric | Target | Current |
|---|---|---|
| Voluntary attendance | > 85% | 94% |
| Post-meeting satisfaction (1-10) | > 7 | 8.2 |
| "I learned something new" | > 70% | 82% |
| "My questions were addressed" | > 80% | 88% |
| Anonymous question volume | > 5/meeting | 12/meeting |
| Deep dive volunteer rate | 100% slots filled | 150% (waitlist) |
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
-
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.
-
45 minutes, four segments, hard stop — energy dies after 50 minutes. The format creates predictability, which builds attendance habits.
-
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.
-
Teach, don't report — the deep dive segment should make attendees think "I'm glad I was here" because they learned something useful.
-
The written companion creates accountability — documenting answers and action items means follow-through is visible and leaders are held to their commitments.
-
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.
Recommended reading

The Legacy of Leadership: What Remains When You Leave
The thing people remember is not your architecture. It is not your processes. It is how you made them feel. Reflections on what actually endures from engineering leadership.

What 3 A.M. Incidents Taught Me That AWS Certifications Never Did
Twenty production incidents reviewed: why understanding beats fixing, what certifications actually train, and the habits that keep a team calm at 3 a.m.

An Engineering Leader's Sustainable Weekly Rhythm
A realistic weekly rhythm that balances strategy, people, and operational work — without burning out or losing yourself in back-to-back meetings.

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