I’ve been a software engineer for quite some time now and, when someone asks me “how are you doing?” I find myself replying “ugh, too many mee

A guide to good meetings, from a software engineer perspective

submited by
Style Pass
2021-07-05 19:00:07

I’ve been a software engineer for quite some time now and, when someone asks me “how are you doing?” I find myself replying “ugh, too many meetings” more often than I’d like to admit. But, some of us have been in good meetings too. When that happens, we’re so surprised that we find ourselves saying: “Oh, that was a good meeting!”. And it feels good, it feels productive. We need to change our perspective that meetings are inherently a bad thing and focus on improving them.

I don’t know a single software engineer who doesn’t complain about having too many meetings. It’s the status quo. We have to constantly push back so that we get time to do what we enjoy the most: building software. This creates an atmosphere where managers, QAs, and other roles fear creating meetings because they don’t want to fill up developer’s calendars. Why? Because they may be aware of the Maker’s schedule vs Manager’s schedule guidance. Whenever meetings can’t be avoided, they must be productive.

All meetings must have a goal. The goal should be clear from the beginning to everyone who’s participating. Say it aloud when the meeting starts: “this meeting is to make a decision on whether to go with A or B about X subject”. Having too many objectives is a bad sign but there can be exceptions. For example, if many small and quick decisions need to be made. But, usually, software engineering problems aren’t solved with quick decisions. Have one goal and discuss it in depth, otherwise there’ll be confusion and you’ll need another meeting.

Leave a Comment