2 ms·

> There's a nice theory that this could be done with email, but the reality is that having meetings and reviewing documents via email tends to turn up different

> There's a nice theory that this could be done with email, but the reality is that having meetings and reviewing documents via email tends to turn up different issues. Why? I have worked on developing technical review processes in more than one organisation, and spent many hours reading the books, studying the research and conducting practical trials. I have never encountered any evidence to suggest that everyone-sitting-there meetings are more productive than sending people copies of the material to check over in their own time and providing a sensible tool to record the findings. On the contrary, my experience is that technical review processes often make fine examples of how to get meetings wrong. Calling a multi-hour, all-hands meeting every time something comes up for review seems to be as sure a guarantee as anything in life that your review process will fail and your staff will wind up with a permanent grudge against the very idea of reviews as a worthwhile use of their time. That is because many issues raised during reviews are simple, and can be resolved simply and quickly between the reviewer who found the issue, the author of whatever is being reviewed, and possibly a small number of other reviewers who made the same or related observations. Making a wider group sit through dozens of typically short and bilateral discussions as you work down a list of every little point is enough to induce sleep even in the most dedicated and conscientious of participants. Of course, there may be some issues that can't be resolved easily in this way. Perhaps discussion via e-mail/review tool/document comments/whatever is too inefficient for the number of reviewers/comments involved, or there are multiple people making related but subtly different points. This can lead to a productive meeting, but now you have both a specific point where a decision is needed and a clear list of interested parties to invite.

Goladus 16y ago
> I have worked on developing technical review processes in more than one organisation, and spent many hours reading the books, studying the research and conducting practical trials. So have I, although perhaps I've read fewer books and run more releases. > I have never encountered any evidence to suggest that everyone-sitting-there meetings are more productive than sending people copies of the material to check over in their own time and providing a sensible tool to record the findings. My experience differs. I did not suggest that meetings are more productive. They are just different. Whether they will be useful to you, in particular, almost certainly depends on exactly how your organization is put together and how your software is built. And now that I think about it-- the physical layout probably matters, too. But the pattern I've observed (for the release meeting in particular) is the following: Send out the materials in an email and get feedback. Call the meeting and review the materials-- usually about 5-10 people for 30-60 minutes. There will be completely different feedback. Both will be helpful, and both will help reduce the need for SysAdmins to escalate issues and prolong downtime. There will be crosstalk, there will be issue resolved via discussion that everyone can understand. Sometimes, the nature of confusion about a something is best observed through tone of voice and body language. Sometimes it's all useless-- the plan was right from the beginning, and nobody has any issues. Calling a multi-hour, all-hands meeting every time For the example I mentioned, 30 minutes to 1 hour is usually sufficient. If the meeting goes longer than that, usually it's for a good reason and people who clearly don't need to be there will leave anyway.
- Chris_Newton 16y ago
  It seems our experiences have been quite different, but such is life. I'm certainly not claiming that there is no other valuable use for meetings than making specific decisions or determining the answers to specific questions. The briefing-style meeting I mentioned before is another kind of event entirely, and so is a review meeting of the kind you're describing. They should be conducted accordingly. That said, FWIW, I found that there is a serious danger of groupthink in a review meeting if the participants haven't each taken a pass at the material independently before that meeting. There are always "loud" people and "quiet" people, and a good chairperson will be able to moderate that effect, but almost everyone seems to latch onto a trail of thought easily once the suggestion is there. That is the last thing you want, if you're trying to get multiple points of view on something during a review. In practice, I've found that can reduce review meetings to finding essentially those basic issues that a subset of the attendees would have found independently anyway, but lose the input from others. The upside is that sometimes you will explore the issues you do find more deeply, but you could do that either way.

Goladus 16y ago

> I have worked on developing technical review processes in more than one organisation, and spent many hours reading the books, studying the research and conducting practical trials. So have I, although perhaps I've read fewer books and run more releases. > I have never encountered any evidence to suggest that everyone-sitting-there meetings are more productive than sending people copies of the material to check over in their own time and providing a sensible tool to record the findings. My experience differs. I did not suggest that meetings are more productive. They are just different. Whether they will be useful to you, in particular, almost certainly depends on exactly how your organization is put together and how your software is built. And now that I think about it-- the physical layout probably matters, too. But the pattern I've observed (for the release meeting in particular) is the following: Send out the materials in an email and get feedback. Call the meeting and review the materials-- usually about 5-10 people for 30-60 minutes. There will be completely different feedback. Both will be helpful, and both will help reduce the need for SysAdmins to escalate issues and prolong downtime. There will be crosstalk, there will be issue resolved via discussion that everyone can understand. Sometimes, the nature of confusion about a something is best observed through tone of voice and body language. Sometimes it's all useless-- the plan was right from the beginning, and nobody has any issues. Calling a multi-hour, all-hands meeting every time For the example I mentioned, 30 minutes to 1 hour is usually sufficient. If the meeting goes longer than that, usually it's for a good reason and people who clearly don't need to be there will leave anyway.

Chris_Newton 16y ago
It seems our experiences have been quite different, but such is life. I'm certainly not claiming that there is no other valuable use for meetings than making specific decisions or determining the answers to specific questions. The briefing-style meeting I mentioned before is another kind of event entirely, and so is a review meeting of the kind you're describing. They should be conducted accordingly. That said, FWIW, I found that there is a serious danger of groupthink in a review meeting if the participants haven't each taken a pass at the material independently before that meeting. There are always "loud" people and "quiet" people, and a good chairperson will be able to moderate that effect, but almost everyone seems to latch onto a trail of thought easily once the suggestion is there. That is the last thing you want, if you're trying to get multiple points of view on something during a review. In practice, I've found that can reduce review meetings to finding essentially those basic issues that a subset of the attendees would have found independently anyway, but lose the input from others. The upside is that sometimes you will explore the issues you do find more deeply, but you could do that either way.