The Engineering All Hands That Engineers Look Forward To
An engineering all-hands is a regular meeting where the entire engineering team gathers to share updates, discuss direction, and build shared context. The difference between an all-hands engineers dread and one they look forward to is almost entirely in the content: the meetings engineers dislike are status reports. The meetings engineers value are the ones that give them information they could not get anywhere else and create space for honest conversation about technical direction.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- Status updates belong in a written document, not in the meeting. The meeting is for discussion and context that requires presence.
- Engineers look forward to meetings where they learn things they could not find anywhere else and where their input matters to decisions being made.
- The meeting must include something the engineering leadership is uncertain about. Certainty can be written. Uncertainty requires conversation.
- Anonymous question submission before the meeting surfaces the questions engineers are thinking but not saying.
- 60 minutes, monthly, with a written pre-read distributed the day before. This is the format that works.
| Meeting Component | Purpose | Time |
|---|---|---|
| Pre-read review and questions (5 min) | Orient the room to the agenda | 5 minutes |
| Business context update (10 min) | What changed that engineers should know | 10 minutes |
| Technical direction discussion (20 min) | Architecture decision, technology choice, or direction question | 20 minutes |
| Team health and recognition (10 min) | Shoutouts, acknowledged wins, team health signal | 10 minutes |
| Open questions (15 min) | Anonymous Q&A, honest answers | 15 minutes |
The core argument
The engineering all-hands that engineers dread is usually one of two formats. The first is the status parade: each team lead gives a five-minute update on what their team shipped last month, what they are building this month, and what they need from other teams. The combined result is 45 minutes of information that could have been a Slack message. Engineers leave knowing slightly more than they did before and resenting the time.
The second format is the announcement meeting: the engineering leader presents decisions that have already been made and explains why they are good decisions. Engineers sit through a justification for choices they were not consulted on. Questions are answered defensively. The meeting ends with engineers feeling less trusted, not more informed.
The engineering all-hands that engineers look forward to is neither of these. It is a meeting where something happens that could not happen asynchronously: a real conversation about a direction that has not been decided, honest questions that get honest answers, and shared context about where the company is going that helps engineers make better daily decisions without asking for approval.
The format is almost secondary to the content. But the content requires courage from the engineering leader: being willing to share uncertainty, invite disagreement, and change course based on engineering input. The meetings where this happens get attended willingly. The ones that do not eventually get deprioritized.
The pre-read document
The single most effective change to a mediocre engineering all-hands is adding a pre-read document distributed the day before. The document covers: what shipped last month (with links to the work, not just descriptions), key metrics (load time, deploy frequency, incident count, test coverage), upcoming architectural decisions, and any context from the business that affects engineering (funding round, major customer, pivot).
The pre-read replaces the status portion of the meeting. Engineers arrive already knowing what shipped and what the current state is. The meeting starts at the interesting part: the discussion.
The pre-read also enables better questions. An engineer who reads the pre-read and notices that deploy frequency dropped from five per week to one per week will ask about it. An engineer who hears the same information in a verbal update may not make the same connection.
The technical direction discussion
This is the most valuable part of the engineering all-hands and the part most often handled poorly. The typical version: the engineering leader announces an architectural decision and explains why it was made. Engineers ask clarifying questions. The meeting moves on.
The version that builds alignment: the engineering leader presents a decision that has not been made yet. Two or three approaches are described with their trade-offs. Engineers are asked to weigh in, either in the meeting or through a follow-up mechanism. The decision is made after the input, and the engineering leader explains how the input shaped it.
This pattern requires actual willingness to be changed by the engineering team's input. If the engineering leader has already decided and is presenting the decision as an open question, engineers will recognize this quickly and stop engaging honestly. The question must be real.
Handling the questions that matter
The most valuable questions in an engineering all-hands are the ones engineers are thinking but not saying: is the company going to be okay financially, why did the product manager override the engineering team's timeline estimate, is the architecture decision made last year still the right one.
Anonymous question submission before the meeting surfaces these questions without requiring anyone to stake their identity on asking them. A shared Google form, Slido, or similar tool, with questions visible to the whole team before the meeting, lets the engineering leader prepare honest answers rather than being caught off guard.
The answers to these questions must be honest. An engineering leader who deflects the hard questions with corporate language will train the team to stop submitting real questions. The trust required for honest questions requires honest answers, even when the honest answer is "I don't know" or "that was a mistake."
Common mistakes engineering leaders make with all-hands meetings
- Packing too many topics into the agenda. Three topics at 20 minutes each is better than eight topics at five minutes each. Depth beats breadth for building genuine understanding.
- Not leaving time for questions. If the agenda fills the entire meeting, questions are crowded out. Reserve 15 minutes explicitly, and if there are no questions, end early rather than filling the time with more status.
- Treating the all-hands as a performance rather than a conversation. Polished slides and well-rehearsed delivery are appropriate for investor presentations. They create distance in team meetings. Show up prepared but conversational.
- Not following up on open questions from the previous meeting. If an engineer asked a question at the last all-hands and it was not answered, they noticed. Address outstanding questions at the opening of the next meeting.
- Making the all-hands the only place where engineering direction is discussed. The all-hands should reinforce and summarize direction that is accessible in written form. If engineers can only learn about architectural decisions in the all-hands meeting, the documentation is insufficient.
Where to start: a 3-step all-hands format improvement
Step 1: Send a pre-read document before the next meeting. Spend 90 minutes compiling what shipped, key metrics, and upcoming decisions into a document. Send it the day before. Remove the status portion of the meeting agenda.
Step 2: Add one genuine open question to the agenda. Identify a technical decision that has not been made. Present two to three approaches with trade-offs. Ask the team for input during the meeting. Actually change the decision if the input warrants it.
Step 3: Open an anonymous question form before the next meeting. Share the link in Slack with two days of notice. Review the submitted questions. Prepare honest answers, including for the hard ones. If a question is too complex to answer in the meeting, promise a follow-up in writing within one week.
Leadership Through Clarity
Yashveer Singh. Founder of Yashveer Labs. The engineering meetings I care about are the ones where real information is exchanged. I have been in too many meetings where information was rationed and honesty was unwelcome. The format above is the format I would want as an engineer in the room. If you are building an engineering culture and want a perspective from someone who thinks carefully about how technical teams work, the contact page is there.
Related reading
Frequently asked
The reason I write these
I write these because the writing is the proof. Yashveer Singh, founder of Yashveer Labs. The systems I build are not theoretical. They are running right now, serving real users, generating real revenue. That is the bar I hold this writing to. If you want to hire someone who can match that bar, I am the call.
Posts that line up with this one.
- Startup Technical Strategy
The Engineering Performance Review That Engineers Find Useful
How to design an engineering performance review that produces actionable feedback, drives development, and does not feel like compliance theater.
- Startup Technical Strategy
The Engineering Career Ladder That Engineers Trust
What makes an engineering career ladder credible to engineers instead of a performance review document that explains why everyone is underpromoted.
- Startup Technical Strategy
The Engineering Culture Document That Engineers Actually Read
What engineering culture documents actually need to say to be useful, not decorative -- and how to write one that engineers trust.
- Startup Technical Strategy
The Engineering Org Chart at 5, 25, and 100 Engineers
How engineering team structure evolves across the three most critical inflection points as startups scale -- and the mistakes that make each transition harder.