Does anyone do an Engineering All Hands? If so, what topics do you discuss?
- “For my part, I can say that one of the most consistent challenges I’ve had with all-hands has been engineers presenting work done without any sense of context or value. To offset that, I have brought in product managers to help give that context and/or give it myself when it was lacking. I’ve found that when engineers have models discussing the “why” of their work, they get better at it themselves.”
 - “I like to discuss: strategic shifts that will affect our future plans, interesting work happening in other parts of the company (a fun opportunity to bring in guest speakers and build connections)”
 - “I do an eng all-hands every other week. The end of the month one is a monthly wrap up of what the org worked on. I reiterate the quarter’s goals so that we keep repeating what we are all supposed to be focused on. (And if these change we can communicate that out). I like to show “We planned X projects, we shipped X projects with X number of incidents”. I also do a hiring update to keep folks in the loop about new people coming onboard soon, or to remind them if they know folks to refer them. Then we do demos for the remaining 30-45min. On the other weeks we are just now starting to have the Eng Mgrs go over the work their teams completed for the past 2-3 weeks. They will update what they promised and what has gone out the door and what is left, then we will do demos. The CEO then selects some of those demos to present at the company all-hands the next week.
 - “We don’t do any show and tell, mostly because we have a separate dedicated show-and-tell meeting. Typically I cover: New teammate intros (if any), Hiring and open roles, Org-wide initiatives or announcements (e.g. we’re wrapping up goal setting right now, major product milestones), Improvements based on our quarterly DevEx surveys”
 - I have a slide that keeps the running metrics for that quarter, so for example, it shows January’s chart, then Feb’s chart, then it’ll show March’s chart this month. It’s pretty basic (simple bar chart), but I think it helps the engineers to see how they are tracking, and it helps show the rest of the company that eng is shipping things and how many major incidents they are contending with each month. I then take those numbers and roll them into the board presentation each month. I may just put the previous quarter’s metrics in the slide when a new quarter starts (I just started doing this in January, as I just started here back in November). I think trends over time is INCREDIBLY helpful, I keep many metrics running for my own use day-to-day.
 - “It’s my experience that folks just need info coming from the top. So I try and show that I see folks’ work and including the incidents shows that I see when folks are paged in after-hours, or are working on critical interrupts. I reiterate our goals to make sure that I am doing my #1 job as ‘Chief Repeating Officer’ so that folks remember why we are doing the work we are doing. I communicate down any changes that happened in conversations/meetings that engineers weren’t in, or may not be aware of. I make sure to explain WHY things are important, and communicate a sense of urgency for things that are REALLY important (but I do this sparingly, so that if I do it it actually means something)”
 - “When our group ran the best, we had weekly or every-other-week (“fortnightly”) all hands. Weekly was back in the time of 40 people in all of Eng, fortnightly we had a group of over 200. I prefer fortnightly over monthly because it makes it more real-time and project relevant. If you only meet once a month, that isn’t enough time to correct and still make a commit on a monthly or even quarterly timeframe. But other people really disliked it, because it is a lot of work to prepare and it takes up valuable meeting bandwidth. If director groups (40-100 people) wanted to have their own all-hands, and teams have a weekly team meeting, then suddenly it is a lot of meetings. I never came to a solution to that problem that I liked.”
 - “I work with my head of eng and head of product to do a “tech org all-hands”. It’s scheduled to be once/month, but we assess it ahead of time to make sure it will be valuable time spent for everyone, and really only have it once/quarter. Example topics: where are we going? (I shared slides that I presented to the board - which include product-ish metrics but not yet eng metrics that I’d like to have), Roadmap Intro for next 4-6 months, Project reviews (prod+eng leads), Any team shuffling (share-out or selection exercise) to best address the upcoming quarter’s priorities, Architecture guild update / Central definition library, * Platform team’s asks of other teams, CEO guest”
 
Questions and answers
- “I always leave the last 10-15 min to answer questions. Some months folks will have questions about where certain potential customers are in the sales pipeline, or how some new product roadmap item impacts their team. And others it’s just radio silence.”
 - “Q&A is hard. In my experience, the questions they really want answered feel too spicy to ask in public. Have you ever tried collecting anonymous questions and answering them at the all-hands?”
 - “Planting questions is a good idea. You could also just repeat and answer good questions that came up in 1:1s yourself.”
 - “One of my favorite bosses used to call the anonymous questions “Rude questions” and that was helpful. So maybe collect anonymous questions, but frame it around “rude questions” so that folks will ask the spicy questions?”
 - “As for Q&A, I enjoyed doing it, but it was hard to protect the time for it. And the only working system is to just always answer all the questions, even the spicy ones. A question ignored or evaded is a question you’ll get again just out of spite.”