Developers are famous for disdaining meetings. Meetings force us to context switch, kill our flow, and sap our job satisfaction long term. Yet, managers and scrum masters can't seem to get enough of them, and the resulting tension is all over our calendars. Paul Graham (internet) famously documented this phenomenon in his essay Maker's Schedule, Manager's schedule.
Large organizations are especially known for overstuffing developer calendars with pointless meetings – at least pointless to developers. And when a scrum master goes rogue, a dev can have days when nothing of actual value gets done between retros, sprint plannings, demos, and process alignments.
I sat through a particularly useless meeting the other week with a meeting screen full of other devs – oddly, it was initiated by a tech lead on a different team. During the boredom, I started wondering :
- How can we make a business case for fewer pointless meetings on our calendars?
- How can we add more value to the meetings we attend?
- How can we have fewer meetings of the pointless kind and more of the value-added kind?
The Opportunity Cost
I was an accountant in my previous life, so I want to put a number on exactly how much a meeting can cost. Here's my ballpark calculation of the opportunity cost of a meeting for the company, regardless of whether it is pointless.
Here are my assumptions: these are US-centric, adjust for your local market conditions:
- The meeting is 1 hour long, involving a PM and a team of 4 developers.
- The developers have an average total compensation of $200,000 and 2 Weeks of PTO.
- On average, an employee costs an employer 1.5X their compensation in other benefits.
- An average developer is in a maximally productive flow-state on average between 4-6 hours per day, we'll use 5 hours for our calculation.
- The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle.
- This is a badly scheduled meeting in an organization with too many meetings already – cutting into flow state time. Each developer on average wastes 30 minutes before and after the meeting to context switch and the time is otherwise non-value adding. (See this study for the cost of context switching).
Using these assumptions, we see that each developer's inflow state per hour costs to the company is ($200,000 * 1.5 * 0.8) / ((52-2) * 5 * 5) = $192 per 'flow hour'.
At a cost of 2 hours in 'flow hours' per developer and 4 developers in this meeting, the meeting's developer opportunity cost is $1536. The meeting's opportunity cost is higher than the price of a brand-new M1 MacBook Pro. If the meeting was pointless, might as well cancel it and fly one of the devs to Bali instead.
In my experience, corporations with the most meetings are often also stingiest with dev equipment and educational/training expenses – a classic case of penny wise and pound foolish.
Value-Added Meetings
Because of my accountant tendencies – and because I used to be a freelancer – I try my best to make sure I add enough business value to every meeting to justify my presence. Politics aside, it actually makes me feel a bit bad to only sit in on one. I hate wasting my time.
Value-added can be everything from providing actual technical perspective and expertise to simply keeping everyone on track. Cutting a 15-minute detour in an 8 developer meeting is enough value added to justify attending. Of course, it's even better if you cut the meeting short when it's going nowhere, or suggest it be canceled, to begin with.
An even better way to get value from a meeting – especially for senior devs and tech leads – is to attend for the rest of the team and write a one-page summary that can be consumed at the rest of the team's leisure.
Take the meeting from the previous section: A senior dev hashed out the issue with the PM one on one and spends an extra 30 minutes post-meeting summarizing the key points learned and decisions made. The senior dev just added $1500 worth of business value in an hour and a half of work – a real force multiplier.
Have Better Meetings
I'm by no means a meeting expert (nor do I really wish to become one), but here are some meeting tips that work well for me:
- Batching meetings: When possible, reschedule meetings to right around my team's daily standup and at the end of the day when I'm ready for a mental break. I try to keep the 11 am-4 pm block of my day free. Bonus point: the best way to batch meetings is to skip them.
- Have an agenda: This is meeting 101 stuff, but it is too often ignored. Have the action items and desired meeting results spelled out ahead of time, this allows you to cut them short once a decision is made. Bonus point: be the guy who says 'sounds like we finished everything on the agenda, shall we call it?'.
- Separate the async from the sync: You wouldn't block the main JS thread with functions that can be resolved asynchronously, so why block a synchronous meeting going over information that can be provided via email and read whenever? Bonus point: sometimes the act of writing down the context turns a meeting into an email or slack poll.
Final Word
Skip more meetings, make a case that the shareholders aren't paying you hundreds of dollars an hour to listen – that could get through the MBA types.
Manage your meetings, and crush the ones you choose to attend. Be a force multiplier and your team will thank you for your leadership.
If you found this post helpful, please share it with others. You may also be interested in learning about How an MR comment hierarchy can Speed Up Delivery or Use 'Disagree and Commit' to get through technical disagreements.
Follow me on Twitter @ItsTrueInTheory to get the latest blog updates or subscribe to email updates using the form below.