4 ms·
> I have worked on developing technical review processes in more than one organisation, and spent many hours reading the books, studying the research and conduc
by 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 agoIt 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.