Test-Driven Meetings

Write a test, make it fail. Write the code to make it work. Refactor.

This "red-green" cycle is something most modern developers understand. Many of us have built our whole workflow with this concept in front and center.

We also identify with each other's pain when it comes to meetings.

Why are we meeting again? Why does this meeting have to last 2 hours? Doesn't everyone already have this information? Wouldn't it be better if we would all just go back to our work? This isn't real work... it's just making us feel like we're working.

Some meetings feel more productive than others. Maybe you really enjoy daily standup meetings, but can hardly tolerate "town hall" meetings.

Wherever you are in your career, you can make meetings drastically more useful by applying the test-driven model of thinking to your meeting schedule.

Let's break it down!

1. Look at your calendar and identify all events that are meetings.

Not every event is a meeting. Make a calendar specific for your meeting events. If you have informal meetings, put them on the calendar too.

2. In the calendar event, write out the expected output of the meeting.

Arguably, great functions always produce output. What will you take away from this meeting? Here are some types of output:

• Tasks - is your meeting intended to generate work to be completed?
• "Decision record" - wherever you keep documentation of your work in progress, the output of a meeting might be as simple as making a decision about something and documenting it.
• Notes - At the very least, your meeting should be able to output a simple summary about what was discussed.

3. In the calendar event, also write out the desired side effects of the meeting.

While most of your meetings should produce functional output, you will also have meetings intended to produce side effects. Here's a list of side effects you may care about.

• Camaraderie - Does your team feel closer to each other after a meeting?
• Belonging / in-the-know - does your team feel like they are included on important information?
• Emotional support and expression - do your team members feel emotionally supported? Has everyone had a chance to express their opinions?

Don't fly blindly into a meeting.

It's easy to ignore meeting prep as a practice. It's difficult to immediately see the value in stopping the "important" work you are doing for something seemingly less important.

Make your meetings matter by creating these expectations, and testing against them. If a meeting is failing to produce expectations, do what a good developer does when tests fail: refactor the meeting!