Why are most meetings hell for engineers?
- Meetings aren’t as interesting as coding
- Most attendees aren’t needed to contribute for the whole time
- An engineer’s impact during a meeting is less tangible compared to coding
- Meetings are interruptions that cause context switches
As an engineering manager, you will need meetings to get some things done. Here are some quick tips on how to make them more engaging for the engineers who you’ll be inviting along.
Encourage engineers to ask this question about your meetings
“How will we know when this meeting is over?”
It’s as simple as that. Suggest that your team ask this question of every meeting they attend.
This question instantly reveals if the meeting will be an open-ended, meandering discussion that will consume every minute of what’s booked on the calendar (aka, the quickest way to send engineers to meeting hell), or if it will be a productive use of people’s time.
On a related note, never, ever say the phrase, “well, we have the hour…”.
Outcome, outcome, outcome
A meeting outcome is not the same as an agenda. An agenda is an outline for how the meeting will be conducted, not what it will achieve. A great many pointless meetings have had wonderful well-structured agendas.
Meetings need a reason for existence, and that’s why they need a desired outcome. Make sure the outcome is clear, achievable, and relevant.
To test if you have defined a useful outcome, ask yourself this question: “How will the participants behave differently once the meeting is over?” If you can’t think of anything, you don’t have a good outcome defined.
An inevitable effect of following the above is that you’ll rarely end up using the word “discuss” in your meeting name, and that will be a very good thing for your engineers.
Lean into “decision meetings”
Managers do a lot of their work in meetings, but engineers do their work elsewhere. Don’t force engineers into your management world, instead meet them where they’re at.
Most managers schedule calendar time for synchronous work sessions, but there are other meeting types that are powerful and less interruptive for engineers. My favorite is the decision meeting.
A decision meeting is a forcing function: when your team starts to investigate something in order to come to a conclusion on it, you also schedule a meeting for a future date to review their decision. This is great for investigations like spikes, tool evaluations, or user research.
This type of meeting is especially useful for indecisive engineers prone to “it-depends-itis”. In a decision meeting, the agenda should state clearly that it will last only 5 or 10 minutes, and the engineers should bring their decision in hand.
If it devolves into a discussion meeting, it is up to the manager to either make the decision for them, or (as a last resort) reschedule it until they are ready to bring a decision to the table.
Carefully choose the “when” and “who”
Limit interruptions with an intentional “when”. Engineers are makers, and need contiguous periods of focus and concentration. Run your meeting at a time when the team agrees it will be less interruptive, perhaps at the start of the day before they build momentum on a technical task.
If an engineer could hypothetically attend a meeting, code on their laptop during it, and the meeting still be a success, then that person probably wasn’t needed. Send them a summary of the outcome later. Heck, there are AI bots that will write the summary for you.
Run a nano-retro
Before a meeting wraps up, ask the attendees for a quick 1-10 rating on how valuable it was. If their rating is low, run a super fast retro with a couple of questions like these:
- “Was this meeting needed?”
- “Could we have run the meeting a different way?”
- “Will anything change for you because you attended this meeting?”
Nano-retrospectives like these can build helpful feedback loops, and hopefully lead to more valuable meetings for your engineer colleagues in the future.
Don’t default to meetings
Use meetings only when there’s no better way to move forward. This especially important for remote teams.
As a fully synchronous communication method, meetings are expensive in many ways. There are many asynchronous alternatives which you should consider too: record a video or audio clip with the information you want to convey, run a poll on Slack, write up a page on your internal doc system, and so on.
A meeting appearing on a calendar is an implicit statement that attending it is more valuable than letting engineers remain focused on their code, a higher priority than other things that could be worked on at that time, and deserving of all the interruptions and context switches that it causes.
Make sure that those things are really true, and your engineers will thank you.
Cover photo by Issy Bailey on Unsplash
More Than Coding 
Basically, it’s about “how to have meaningful meetings”. Not only engineers detest waste of time.
But what I also observe is engineers focus only on coding when actually a synchronization activity would be beneficial to the whole team. Avoiding wasting time on meetings cannot be an excuse to avoid design, discussion, planning, collecting requirements, etc.