Why Meetings can be High-ROI activity and How Engineers can Learn to Lead them
Leading meetings can be a useful skill, if you know what you're doing.
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.
Software development is a team sport, so once in a while, engineers will have to flock to a meeting room and discuss. Projects require constant collaboration among team members, including developers, designers, product managers, and stakeholders. Many cool things can happen in meetings: discussion, alignment, ideation, learning, bonding. Meetings are a fact of our "work lives". It's how organizations work. They're a tool to focus many brains on a topic and get the best outcome for the given topic.
Efficiently leading meetings ensures clear communication, aligned objectives, and effective collaboration. Leading effective meetings is an essential skill that most engineers completely gloss over or discard as useless. And yet, if you are (or aspire to be) a senior engineer, you must know how to get a chaotic meeting back on its rails and push it forward gracefully. That's especially true if you're the leader in the pack.
recently wrote, "driving meetings is a critical skill for growing to Senior."If the issue at hand involves complex problem-solving and brainstorming or requires immediate clarification and interactive feedback - call a meeting! Meetings are a high-bandwidth medium that enables real-time discussion and immediate questions and answers, and they can be course-corrected in real-time. However, suppose the information contains a lot of detail (e.g., technical design). In that case, a medium that would allow engineers to digest the information over time is better (e.g., an RFC).
An expensive exercise
In the famous article "Maker's Schedule, Manager's Schedule," Paul Graham said, "When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in." Engineers perceive meetings as a waste of time. Meetings interrupt their flow and drain energy. Yet, the average engineer spends roughly 11 hours per week in meetings. That's more than a whole day's worth every week.
Meetings are expensive. Shopify's recent exercise to reduce meetings found that the average cost of a 30-minute meeting with three employees can be from $700 to $1,600. Are all meetings worth this cost? Hell no. That's why at the start of 2023, Shopify canceled 12,000 calendar series and events and reinstated 'no meeting Wednesdays.' The average time per person spent in meetings decreased by 14% in the first five months of the year relative to the same five months of the previous year.
The ROI of a Meeting
An example: an hour-long operational review with a team of 6 plus their manager, using Shopify's math, costs the company ~$3500. My question to you is: Is the operational review worth it? Abso-friggin-lutely. Operational reviews, where the team reviews their dashboards and looks into how their systems perform, are high ROI meetings. Any potential system issue uncovered in these reviews can prevent massive problems down the line, so they're worth the engineering team's time. Suppose that the same proverbial team has an operational review every two weeks. In that case, they'd annually spend $91,000 (26 weeks x $3500) on operational reviews. Yet, said reviews can prevent a multimillion-dollar incident down the line. Even if the reviews prevent one big incident every five years - money well spent.
Not all meetings are equal. Nor do they cost the same. As an engineer, sometimes it's worth it to pay the price of the meeting. An hour-long brainstorming session in front of a whiteboard can be the most impactful hour of an engineer's time in a month (or even a quarter). For example, if said brainstorming results in setting the right technical strategy, it can be a game changer for their team or entire organization. Meeting with the right people can unlock a whole avenue for an engineer's learning, leadership opportunities, and career growth.
There are more examples of high-ROI meetings. One-on-ones with your manager. Incident retrospectives. Interviewing. Onboarding newcomers. The list goes on. We need a more nuanced perspective on meetings. We shouldn't flat-out reject them. We must make peace with it - that's how most companies work. They're "a necessary evil", as
said. We must be very intentional with our time and invest it only in meetings whose outcomes and results we can influence. If the group can achieve the same result without input, then our time is better spent elsewhere.How do you lead an effective meeting as a software engineer?
Before even calling a meeting, we need to figure out the purpose of the meeting and its objectives. What do we aim to achieve with the meeting? For example, are we trying to get to a decision? Alignment? Brainstorm? The purpose has to be clear, as it'll set the meeting's direction (and the destination). Talk with allies beforehand if you're unsure what the proper format is. For example, say, "I think we should approach the meeting as a brainstorm; what do you think?" and calibrate.
Once the purpose is clear, set objectives; these are a few goals or outcomes you want the group to achieve. Make them practical. For example, do not say, "discuss the viability of microservice architecture," but rather "decide on go/no-go for the microservice architecture prototype." "Discuss" is what you do in a meeting anyway. The objective is not to discuss - it's to get an outcome you want out of that discussion.
Using the purpose and the objective, you can create the agenda. In it, list the topics to be discussed, including a brief description and the goal for each. Once you're happy with the list, assign a realistic amount of time to each agenda item. Lastly, share the agenda with the participants well before the meeting. Sharing the agenda allows the participants to prepare for the discussion. Add the agenda to the calendar invite, i.e., to the description field, so it's easy to find.
When creating the invite, choose the right participants. How? Think about the people with lots of context, knowledge, or stake in the topic. Invite only those whose input is necessary to arrive at the best decision. Engineers' managers might be interested in the subject as well. Still, sharing the notes with them after the meeting might be enough. But, if the meeting is between multiple teams and you can see that the topic might be contentious, having the teams' managers on the call might be a good idea. They can act as unblockers should the need arise.
During the actual meeting, stay punctual and focused. Join the call on time, and announce that you'll give everyone 2 minutes to join. Then, start the meeting once those two mibs are gone. You have to respect everyone's time.
Keep conversations aligned with the agenda and objectives. Redirect off-topic discussions as needed. Don't ignore off-topic or tangents - jot them down and tell the group you'll revisit those points separately. Be respectful: you should appreciate the tangent, but the facilitator's goal is to respect everyone's time and keep the discussion on track.
Should any disagreements arise, seek to understand the different perspectives. Once you have the different sides of the argument, summarize them for the rest of the group and ask for an acknowledgment. Say something like, "OK folks, to summarize: on one side, I hear [summary of first argument]; on the other side, I hear [summary of second argument]. Is this correct?". Once you get a solid understanding of the two sides, then it's good to ask the group for ideas on tradeoffs to make to bridge the disagreement. Keep repeating this and work towards a consensus.
If the group can't progress on a particular disagreement, it's time to decide: is the disagreement a blocker? Or could the meeting continue without alignment on that specific topic? If blocking, then as the facilitator, you must respectfully ask the group's decision-makers (i.e., the manager) to step in. Once the manager decides, the group must (disagree but) commit to the decision. If the manager(s) cannot decide on the spot or the argument is getting heated, it's best to move to the next agenda item. Use something like, "OK, I don't think we can arrive at a decision now. I will restart the conversation via Slack and schedule a follow-up conversation on the topic once we regroup. Any objections?".
We're all different. Some of us are self-confident and like to speak out. Others come from cultural backgrounds where speaking up is frowned upon if not asked. Some people are loud, but others perceive loudness as confidence and knowledge, which might be incorrect. That's all to say that it's on the facilitator to ensure all voices on the call are heard and all opinions get attention and be valued. As the facilitator, you must create a safe space where team members feel comfortable sharing their ideas and concerns. Say, "Hey [name], what do you think about that?". Or "Hey [name], you've been a bit quiet. Anything you'd like to add?".
Once the group goes through all agenda items - hopefully on time - it's best to review the decisions and rationale behind them. Then, read all the action items and call out their owner and deadline. Before everyone hops off the call or leaves the meeting room, it's best to ensure everyone leaves with the same understanding of the meeting's outcomes. So, read out the decisions, jot them down in the notes document, and read out the action items. Before you wrap up, ask, "Have I misrepresented or skipped anything?". If all you get is silence - you're golden. Time to stretch your legs!
An excellent way to wrap up a meeting facilitation is to share a meeting summary with the attendees. In the summary doc or email, you should include the decisions and action items with all participants, relevant stakeholders, and deadlines (if any). Make sure each action item has an owner and is prioritized accordingly. Or communicate the action item with the owner's manager to ensure the team will adequately prioritize it.
Leveraging your manager before and during meetings
There are qualities that managers have that you can leverage. Managers usually have clout because, well, they're managers. Managers have a network in the company. They have experience and have been in a bunch of meetings - both great and terrible. They know what a well-run meeting looks like. So, lean on your manager when preparing to lead a meeting.
What can you ask of your manager? So. Many. Things.
For starters, if you feel insecure about leading a meeting, you can talk to your manager. Your success is your manager's #1 priority, so they will figure out ways to debug your insecurity and help out with your confidence. Confidence can significantly impact your performance and how good of a job you'll do at facilitating the meeting. Ask them to work with you on the meeting prep. They can review your write-ups, the meeting agenda, and objectives and provide you with feedback.
Your manager can kick off the meeting. They can clarify your role as the discussion leader to everyone in the meeting. Communicating your role in the call will set the stage for you to take charge and others to respect your leadership in the session.
In cross-functional meetings, like product reviews or technical discussions, your manager can review the proposal document and provide helpful feedback. You can also leverage your manager for "backchanneling" – they can talk with other leaders and feel out if your proposal will get pushback from the other team(s). Use them to get that feedback. Then, eliminate any contentious points before the meeting so the meeting is (hopefully) smooth sailing.
If you have an inkling that an upcoming meeting might be contentious, explicitly inform your manager. You can have a prep session together and form an attack plan. Your manager can help with keeping the meeting vibes in check. They can keep your back if you run into headwinds (e.g., strong feedback) or if attendees go on tangents and you find it challenging to keep them focussed. Your manager can be a co-host of the meeting and take an active role. Or be a liaison who can bridge the gap between attendees by translating technical jargon or clarifying project goals and constraints.
After the meeting, you can ask your manager for constructive feedback on what went well and areas for improvement. Tell them to highlight specific instances where you excelled, and query them for actionable advice for future meetings. If you have to learn - ask them for resources or training opportunities in areas like public speaking, project management, or leadership.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija