Meetings for an effective eng organization.

Published on January 17, 2023. executive (35), management (197)

Some engineers develop a strong point of view that meetings are a waste of their time. There’s good reason for that perspective, as many meetings are quite bad, but it’s also a bit myopic: meetings can also be an exceptionally valuable part of a well-run organization. If you’re getting feedback that any given meeting isn’t helpful, then iterate on it, and consider pausing it for the time being. It may not be useful for your organization yet, but don’t give up on the idea of meetings.

Good meetings are the heartbeat for your organization.

If you look hard enough, you can find narrow exceptions, but the vast majority of well-run organizations anchor around a few valuable meetings, and they’re likely the best starting point for your organization as well. (As an aside, if you want to read a second, excellent take on meetings, I highly recommend Steven Sinofsky’s, which is exceptionally good.)

This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer.

Why have meetings?

The most effective communication within an organization is between peers or between managers and their direct team. Your technology strategy is best communicated in a written document. The clearest plan is tracked in a ticket tracker or a document. None of these ideal approaches are large meetings, which isn’t too surprising: large meetings are rarely the best communication solution for any particular goal. However, they are a remarkably effective backup solution when there are gaps in your default approaches.

At a certain size, you can’t discuss everything with every member of your organization, but you can have each manager talk with their team, and complement that with an org-wide meeting. You can’t include everyone’s input early in every technology decision, but you can ensure that the decisions are well-vetted by sharing them in a tech spec review. While meetings are rarely the best initial solution, they are often the best backup solution to ensure important information is communicated across the organization.

While most leaders view organization meetings as a necessary mechanism to distribute context down the reporting hierarchy, I find that they are also effective at two other important tasks: communicating culture, and surfacing concerns from the organization. Accomplishing all three goals within your organization may require a bespoke mix of engineering meetings depending on its size, communication norms, and all-company meetings.

That said, I’d like to recommend six core meetings that I recommend every organization start with, and that I’ve found can go a surprisingly long way. These six are split across three operational meetings (each manager with their direct team, technical spec review, incident review), two developmental meetings (staff engineers, engineering managers) and finally a monthly engineering Q&A to learn what the organization is really thinking about.

Weekly Team Meeting

One key role is keeping the team moving together towards the same goals–what’s really important right now? Another is setting the team’s pace–what have we gotten done this week? Both are best done with a weekly working meeting for your team of direct reports and key stakeholders.

The engineering leadership meeting, along with a similar meeting run by the CEO with the company’s leadership team, is your core hub for operating the engineering organization. First and foremost, this meeting is a working session for your leadership team to accomplish things together. If there’s something you need to solve (disagreement on strategy, conflict about a new career ladder, etc), use this session to resolve it.

Second, it’s an opportunity for your team to share context with each other instead of just with you. What’s going right or wrong for them this week? How could their peers help them with their current project? Serendipity starts with mutual awareness across the team.

Finally, it’s your forum for forging your directs into a first team who’s top priority is supporting each other. (If you’ve not read Patrick Lencioni’s The Five Dysfunctions of a Team, it’s a quick, remarkable read on this topic.)

Some suggestions for making your team meetings effective:

My weekly team meetings always include my direct reports, and usually include our key partner in the Recruiting, People, and Finance teams. (I’ve also experimented with including engineers, which has been a constructive albeit mixed experiment!) Having cross-functional partners in the room builds trust across functions, and will often allow you to resolve issues immediately instead of putting them on the backlog to resolve later
Maintain a running agenda in a group-editable document, anyone in the team can add agenda topics over the course of the week. Take a few minutes before the meeting starts to prioritize topics for the upcoming session
I’d strongly push the core engineering leadership team to meet weekly. I would only reduce that frequency at very small companies (<20 engineers) or slow-moving businesses (not much changes month to month)

However you decide to run your weekly team meeting, remember that your direct reports are likely to model their meetings off yours. If you run a tight, effective meeting, then it’s likely that your entire organization will run similarly effective team meetings.

Technical Spec Review and Incident Review

Technical Spec Review and Incident Review are weekly sessions to discuss any new technical specs or incidents since the previous week. On a quiet week, both of these meetings might be canceled, but on a great week, both will push the company forward in very different ways.

Each company will run a distinct version of these meetings, and the meetings themselves will evolve a bit over time. A few suggestions on what I’ve seen lead to effective review sessions:

All reviews should be anchored on a concise, clearly written document
Reading the written document should be a prerequisite to providing feedback on it. Some teams find that it’s helpful to start with ten minutes to read the documents. Alternatively, it may be helpful to block the preceding thirty minutes before the review meetings on engineering calendars for independent reading
Good reviews are anchored in feedback from the audience, and discussion between the author and the audience. Bad reviews are anchored in the author presenting their document. You will only have good reviews if you’re diligent about steering folks away from presenting their writeup
There should be a clearly documented, very simple process for getting your incident writeup or tech spec scheduled. The more effective approach I’ve seen is dedicated rooms in Slack to ask to be added to the schedule
Long-term, you can measure the impact of these review meetings by whether folks are submitting their new tech specs and incidents for review. If the forums are struggling to solicit content, it’s generally a sign that you should work to make them more useful to attendees
Prepare first-time presenters with a practice run with an experienced presenter! This will make them more confident, foster more valuable discussions, and prevent thousands of hours of time listening to folks who mistakenly believe the review should be them reading their document out loud
Running these reviews well is time consuming, and I highly recommend finding dedicated owners for each meeting. Although a bit annoying at times, both are highly impactful leadership opportunities that can be run by an experienced engineer

Many engineering leaders skip these reviews when they get busy–and it’s certainly a bad sign when you are the loudest voice in either forum–but they’re important forums to be present in. They’re rare opportunities to see engineers across many teams and a wide range of seniority interact on relatively high-stakes topics. This makes these meetings a clear-eyed barometer of your engineering culture. If you’re uncomfortable, bored, and frustrated by these meetings within your own company, fix it.

Eng Managers and Staff Engineers Monthlies

I run two monthly meetings focused on ongoing team development. The first is the Engineering Managers Monthly, attended by all engineering managers, and the second is the Staff Engineers Monthly, attended by all staff-plus engineers. In most organizations, these groups are in the same order of magnitude, and in all organizations they are equally important to a well-run engineering organization.

The format varies a bit for each session, but is generally along the lines of:

[15 minutes] Ask each member to take 1 minute to share something they’re working on, something they’re excited about, and something they’re worried about
[30 minutes] Someone, often me, presents on a development topic. These can be anything that create an opportunity for the group to develop their professional craft. For the Managers session, it might be something I’ve recently read like a Lara Hogan piece about delegation or something I’ve written about like reading a profit and loss statement. For the Staff Engineers session, it might be a topic from Tanya Reilly’s The Staff Engineer’s Path or my own Staff Engineer
[15 minutes] Close with an open-ended Q&A

If there’s a pressing topic–a recent reorg or some such–then we’ll certainly focus on that instead, but I think it’s valuable to support the team in their personal development. Done well, they’ll leave each session both more valuable to the team and more confident that the company is invested in their success.

Engineering Q&A

The final meeting I recommend is the Engineering Q&A meeting. I run it monthly for an hour, starting with introductions of new team members, and then a few minutes sharing any messages I’d like the team to think about. Then we move into Q&A for the remainder of the session. If we run out of questions, we end early, but I find that rarely happens.

Many engineers won’t get to work with you directly, and they will learn to trust (or distrust) you based on how you respond to the most difficult questions during these Q&As. Similarly, you may not hear their concerns in any other forum. The concerns should bubble up to you through the reporting hierarchy, but sometimes there are communication blockages, and this is one way that information will jump the gap to reach you.

Running a good Q&A depends on consistently getting good questions from the audience. There are a handful of techniques that I’ve found valuable to that effect:

I start every Q&A by saying, “I’m glad to talk about anything, no questions are off limits. If your question is too awkward or private, I’ll just avoid answering it. Ask whatever you want.” This is partially a joke, but it’s also how I run the sessions. Sometimes folks ask angry questions. Sometimes they ask questions that were already answered by an email. I always try to bring an even, positive energy, even when the questions are messy
Having a good tool for taking questions goes a very long way. I recommend three core features: ability to ask questions before the meeting starts, ability to vote on which questions are most important to answer, and support for anonymous questions. I would always prefer difficult anonymous questions over folks feeling too uncomfortable to ask them, even if it makes for an awkward session
Remind folks the day and hour before that the Q&A is coming and steer them towards the Q&A tool to maximize the incoming questions and particularly the question askers
Use the Q&A as an opportunity to highlight individuals doing important work or who are key leaders in your organization. When a question comes in that touches on someone’s work, I warn them that I’m going to share my thoughts quickly before passing the question to them, giving them a few minutes to prepare, share my thoughts, and then pass it over to them
Every organization has a small number of folks who can’t help but ask questions. Nurture those folks to ensure you get at least some questions! Good tooling (a question voting tool) or hygiene (creating pauses even when hands are up to allow others to ask questions too) will mitigate the potential downside of only answering their questions
If your team has a relatively narrow window of timezones (roughly three hours difference), then you can find a fixed time that works for everyone. However, if your timezome window is any larger, consider alternating times between a couple time slots to make sure that everyone is able to easily attend at least every other Q&A. I generally recommend spreading sessions across time zones instead of increasing frequency. I also generally recommend against recording Q&As, as question quality tends to drop. That said, experimentation here is cheap, so try different options if you think they’d work better

Although you may not immediately agree, the Engineering Q&A is often my favorite meeting of the month. It’s where I understand how I’m performing relative to my team and organization’s expectations. Are things going well? Is the team upset about something? Was it a problem I already knew about? Can I fix it to prevent them being upset about it next month? If you’re unconvinced, give it a try for a couple months and then go from there.

What about other meetings?

Many organizations have meetings in addition to the ones I propose above, and that’s totally reasonable. There are other meetings that I’ve run and found quite helpful, ranging from a weekly session to meet new hires to a quarterly Engineering All-Hands where we celebrated launches and spoke about upcoming challenges. To highlight a handful of meetings than many companies find useful:

Execution Meeting: you absolutely do want some kind of weekly or monthly execution review meeting, to track and debug execution. The name of this meeting varies tremendously across companies, from Business Review to Operational Check-In to Plan Review.
My experience is that this meeting needs to be cross-functional rather than engineering specific. Any function-specific execution review is likely to assign responsibility to other functions not in the room, whereas a cross-functional review is more likely to resolve issues
Show & Tell / Demos: are a culture-forming meeting, making it clear to attendees what kinds of work is celebrated at the company. These are often a particularly joyful meeting, centering on folks sharing what they’re proud of. Frequency across companies varies a bit from weekly to monthly
Tech Talks / Lunch & Learn: are an opportunity for members of the team to learn together, either by teaching areas of expertise, or by reading books and papers together
Engineering All-Hands: you do want engineering to spend time together, but exactly how you want to do it will vary quite a bit by stage and other company meetings. The other issue is that All-Hands meetings are a bit open-ended. Is your All-Hands really a Show & Tell? Or a roadmap review? Or something else entirely?

My experience is that most of these additional meetings depend significantly on your broader company meeting calendar. For example, does your company already have a monthly all-hands and what do you talk about there? Running a monthly Engineering All-Hands when you already have a monthly Company All-Hands is often a bit painful to coordinate, which you’ll have to decide about for yourself. I prefer aligning with existing company meetings whenever possible. As important as it is for engineering to know what other engineers are doing, it’s even more valuable for them to know what the folks in other functions are focused on.

Who runs the meetings?

As head of engineering, you’ll generally lead your team meeting, Manager and Staff Engineer Monthlies, and Engineering Q&A. You may also lead the Tech Spec Review and Incident Review, but it’s likely that one of your direct reports or a Staff Engineer will take on leading those forums as your organization grows (because they take a level of persistent attention that can be difficult to sustain as an executive focused on putting out fires). If you introduce further meetings like a Show & Tell, it’s varies widely who will run it.

Three important points to consider here are:

Leading a meeting doesn’t necessarily mean that you need to do the coordination work to make it a success. You’ll often partner with an executive assistant or program manager on those aspects
The team will watch you closely and take cues from your behavior. Even if you say a meeting is important, they’ll only believe you if you show up regularly. It’s very difficult for others to lead organizational meetings if you don’t attend
Even if you don’t lead or coordinate one or more of these forums, you are accountable for making it a good use of the organization’s time. That is something that you can’t delegate.

As with all things, there are no firm rules about who does what across organizations. If you want to try something different, then give it a try.

Scaling meetings

Many organizations have more meetings than this, and that’s totally fine. Do what works well for you. Similarly, an organization with five engineers would only need one of these meetings, the weekly meeting with their direct team. Scaling down is relatively easy–drop meetings that aren’t helpful–but scaling up can get a bit messy.

Generally, I would recommend:

Scale operational meetings to optimize for the right participants. If your technical spec review sessions are skewing towards mobile concerns, but most attendees don’t have context on mobile, then you may want to split out a dedicated mobile session
Scale developmental meetings to optimize for participant engagement. If you have more than ten folks in a developmental meeting, many of them will stop participating or even stop attending. If you have 20+ engineering managers, consider pushing this meeting one layer down the reporting hierarchy, such that your reports run their own development meeting with their managers rather than you running it with the entire organization. (You can, of course, find hybrid approaches! You could run the meeting every other time. You can focus on splitting into small discussion groups after introducing the content, etc.)
I would recommend keeping the Eng Q&A as a whole organization affair, but you could absolutely consider your directs rolling out their own Q&As as well at a certain size (e.g. an engineering organization with 600 engineers can certainly tolerate an Eng Q&A and also a Product Eng Q&A every month)

Finally, I find that many organizations split meetings prematurely because there are one or two individuals who behave badly in important meetings. For example, you may have an antagonistic engineer who joins every technical spec review meeting to advocate for a particular technology. It’s extremely valuable to solve that problem by holding that engineer accountable to a higher communication standard. You cannot scale large meetings without holding participants responsible for their behavior.

1:1s and skip-levels

For completeness, I also strongly recommend weekly 1:1s with your direct reports and peers you work most closely with. Borrowing from my concrete experience at Calm, during my first year I met with three executive peers every week, and my other peers once a month, for an hour. I met with each member of my team for an hour, although as we’d worked together for several years, some weeks those 1:1s happened to be thirty minute meetings instead.

Skip-level meetings with your organization are very valuable as well, although I’ve found them difficult to create space for as your organization grows. My recommendation is to determine a fixed amount of time to devote to skip-levels, say one to two hours a week, and to iterate on frequency and format to stay within that allocation (do group skip-level meetings, meet once a quarter instead of once a month, etc). Skip-levels feel productive, and you’ll probably feel bad if you don’t do them as often as you’d like, but don’t let them get in the way of performing your core work.

Meetings don’t stand alone

Finally, a couple of ending notes. First, it’s important to point that you cannot build effective communication within your organization solely through meetings. Great communication includes meetings, but requires strong individual relationships and working through many other channels (email, chat, etc).

Second, you should integrate your approach to meetings with the wider company’s approach. In some cases, you’ll find that many of these meetings already exist, and you want to integrate with those existing forums instead of creating duplicates. In other cases, you may even find that running these within engineering, or even a subset of engineering, can be an effective way to create awareness that they’re a good use of time.