The only two (or five) useful meetings

The Water Cooler
,
1

A brain-dump of something I’ve been thinking about as a big reorg happens in Red Hat engineering,[1] causing much shuffling of calendars.

  1. Decision-making. Get everyone needed to make a decision together, after the
    basics are understood from prior conversations. Every decider in the room or call, focused only on the unresolved points. No one who doesn’t have decision authority in the room.[2]

    If someone needs to be brought up to speed, it’s not time for this meeting yet.

    If people can’t agree on exactly what remains to decide, it’s not time for this meeting yet.

    If there’s too much for half an hour, it’s not time for this meeting yet. (Or maybe there are two meetings, with work in between.)

    If it seems like more than seven people need to be there, it’s not time for this meeting yet. (And seven is pushing it.)

  2. Deliver vital information. There are two different situations here.

    First, a meeting type that shouldn’t have to exist but in practice must, because of people like me who can’t keep up with email. This meeting makes sure that we hear the most important things, even over the chaos of our daily lives.[3]

    This is the only exception to the general rule that meetings with more than seven attendees are useless. That means they must be rare. If overused, they’ll waste a bunch of time, lose their impact, and people will stop attending (not necessarily in that order).

    Second, when there’s something big and potentially bad or scary. In-person (or at least virtually so) is crucial. You can see and hear people’s emotional reactions, answer questions, gather concerns, and just generally be a human being. Thankfully, I’ve not had many situations where I’m on either side of this kind of meeting — and I hope it stays that way!

  • I’m not counting “one on ones” — just two people, mostly unstructured, talking about anything from immediate concerns to long-term goals, or just socializing at work. These aren’t just for manager-employee relationships. They are for networking, mentoring, and collaborating. In an old-fashioned office, where everyone is in the same actual space every day, many of these are spontaneous.

  • I’m also not counting working sessions or hackfests, where people get together (either on video or in person) and actually produce something. That can be documentation, art, code, ideas — or, even routine decisions (like Fedora’s Go/No-Go meetings before each release).

Okay, so… the last two are often scheduled like meetings, and technically they are people meeting together, so if you want to make my count three or four instead of two, okay, fine.

And if you want to count the two sub-types I’ve put under the second category as separate, I guess it’s five.

But no more than five!

What are your thoughts?

  1. The Quality Engineering organization and Software Engineering organization are becoming one. This is a really good thing long overdue, but also a lot of change. ↩︎

  2. They can watch the recording or read the minutes. ↩︎

  3. Thank you, for example, @dvolavko, for putting up with me on this in planning for Flock! ↩︎

2 Likes
2

I appreciate the view that separates the idea of informing people enough to make a decision from needing to have a meeting to make a decision. I agree that a meeting is more valuable when everyone does their homework before hand rather than having folks attend expecting to get the lesson in the meeting.

1 Like
3

I think you should count “working sessions” and then call the whole thing the " fetch–decode–execute" (“inform-decide-produce”) cycle of Fedora. :stuck_out_tongue:

1 Like
4

Well, I’m in with the “This meeting could have been an email” culture, specially at work.

In the case of a community project, is harder for me to see something like this happening, because that means that every team needs representation in the decisions.

What kind of meeting could be potentially reduced to 7 people?

A SIG meeting to decide over a feature to be included into a Spin? A Council decision over a CoC issue? A FESCo decision over a Change? All of them?

I understand that some meeting could be hard to follow, specially when you’re not in tune (here is important the part of inform people), but with a proper meeting agenda the problem could be solved.

Just thoughts that come to my head.

5

Yeah, I wrote this is mostly in the context of meetings at a company. A lot of of community meetings are more like working sessions, and that’s not necessarily bad.

FESCo meetings are usually the Decision-Making kind, and they do go better when everyone has read the tickets before hand.

We’ve been pretty lax with Fedora Council meeting agendas, though, and I think we need to get better at that.

1 Like