As software developers, it's common to spend too much of our time in several meetings. Some are routine, some are sporadic, like announcements at a company-wide level for example, and, others yet are the really important ones, like how to ship that new feature that's just ready, or how to gain clarification at the start of a new project.

It's important to know which meetings are worth your time, and focus most of the energy on those, while some of the others can be seen as optional and are better skipped to enable the space to do deep work. But, after all, what does constitute a good meeting, and how to differentiate a good meeting from a bad one?

What makes a good meeting

For a meeting of any kind with any number of stakeholders to be relevant, it's important that its relevancy is showcased just when the meeting itself is being planned and subsequently auto-added to all of the invited peoples' calendars:

• a meeting should have an agenda: if there is none, than, what exactly will be discussed and in what fashion is it going to benefit all the people involved?

• clear inputs: what is expected from the participants who will be attending as well as from the organizer. The most important thing is to ensure everyone joining is in the same page;

• expected outputs: just like knowing the inputs to a meeting is key, it's peraphs even more important to know the outputs: what is expected as the result of the meeting? This can be a document written by a previously appointed person, can be gathering the thoughts of people involved and structure them into a coherent set of notes, or it can be talking to someone;

• timeboxed: nobody likes appointments which drag longer than initially expected. Same with meetings. Timebox them and wrap up when the desired outputs have been reached;

Next time you will need to decide whether to attend a meeting or plan one yourself, keep these aspects in mind and you'll run better, more successful meetings!