On reading documents in meetings

Amazon famously has meeting attendees read documents at the beginning of the meeting. It seems to work well for them (I’m not sure that’s the secret sauce, but that’s for another day). Tech exec Jason Crawford recently had a Twitter thread promoting this concept.

He got some disagreement on this, including from my friend Julia who considered it “inaccessible and exclusionary”.

Her arguments are right on and sufficient on their own. But there’s a broader point too: this is solving the wrong problem.

[ed note: The previous paragraph does not sufficiently express my intent. The exclusionary effect that Julia points out are reason enough to not engage in this practice. Full stop. My point about “solving the wrong problem” are more along the lines of “even if it weren’t exclusionary, here’s why you shouldn’t do it.” Thanks to Ruth for the comment that calls this out.]

Is your document too long for people to understand and digest? Fix that! Identify people who can act as editors that can help others within your organization write better documents. Or better yet, pay for writing training for your employees. It costs money, but it produces real (but hard-to-quantify) savings. Not only will you save time by having more understandable documents, but you may even have better ideas.

Are people not reading it because they’re too busy or don’t care? Fix that! Maybe it’s irrelevant to the person; that’s an indication that they don’t need to be invited to the meeting anyway. Or maybe they’re overworked, or mis-worked. That’s a management problem that will manifest elsewhere. Or maybe they’re just not doing it. Again, that’s a management problem — if that doesn’t show up in their performance evaluation, then you’re showing that it’s not actually important to you.

Jason suggests scheduling a 90 minute meeting if the document takes 30 minutes to read. That’s a waste of 30 minutes. Yes people should absolutely read the document. But they should also have the flexibility to do it when it makes sense to them. Maybe they have a train ride home that they’d rather do reading on. Maybe they like to block out time around their other meetings. It’s not valuing their time to decide when they get to read the document.

He also says it avoids “negotiation” about how soon in advance a document should be sent. This is a cultural norm that you can set. All of this comes down to a shortcut to avoid the hard work of setting a culture that gives people flexibility while still holding them accountable.

#info as a measure of meeting productivity?

It all started with a tweet:

That started a discussion between Matt and Karsten Wade about how to measure whether or not a meeting was productive. Matt suggested a count of “#action”, “#agreed”, and “#info” MeetBot commands.

about how to measure whether or not a meeting was productive. Matt suggested a count of “#action”, “#agreed”, and “#info” MeetBot commands. At this point, I had to jump in. “#info”, I felt, did not really belong in a measure of whether a not a meeting was productive.

My take is that #info should be used primarily as a reminder of things that have already been brought up on the appropriate mailing list. It serves as context for what’s going on in the discussion and should not be used to bring up new ideas.

Fedora teams particularly, and many open source teams generally, are too geographically distributed for IRC meetings to be where new items come up. Ideally, even #agreed should be mostly a formal recognition of the consensus on the mailing list. When contributors span the globe, it is nearly impossible to find a time when everyone can meet, making asynchronous communication essential.

This lines up with my philosophy about meetings in general. It’s better to share information ahead of time so people can evaluate it before the meeting. This saves time, since less explanation is required during the meeting, and it gives people the opportunity to more rationally consider their position on the topic.

Matt also suggested that #info is a way to call out things that were brought up as new in a meeting. To the extent that it’s better than not calling out new things, I agree. However, as Karsten suggested, perhaps #idea is a better.

Each team will have, to some extent, its own culture and its own rules for coming to decisions. The important thing is to make sure that contributors who can’t regularly attend IRC meetings still have the opportunity to participate in the decision-making process.