This whole work, research and observations led me to musing about meetings in general. You're probably familiar with the “Meetings are Toxic” maxim from the “Getting Real” book by 37 signals. I tend to agree with it. In short, meetings are huge energy drainers and productivity flow breakers, so the deal is to figure out if this energy drain is actually worth it. However, there’s at least one great thing I’m very happy about when it goes about our meetings: there’s no space left for elephants in the room! Unlike in the picture below. :)
I’ve been a part of some meetings in our company, and I’ve talked to people asking if meetings are productive? What are the other ways to reach the desired outcome? As always, there’re pros and cons. If we try to follow 37 signals and their maxim, we will most likely miss something vital at the end of the day. People get together and talk at meetings. Getting together and talking is good, that’s for sure, but is it paying off the value? The answer would be “yes”, despite the subject drift-offs, someone holding the attention of the group for more than it’s appropriate, being poorly prepared due to the overload with other tasks and commitments, etc.
One note though: this “yes” holds true for our company, and it depends. Besides, there’re various kinds of meetings. Developers get together to discuss, sketch and define the way to do some functional feature. These meetings occur all the time, and they don’t seem to interrupt the productivity. They really do matter. What I’m getting at are product management meetings, UX meetings and other larger company meetings.
It appears that the core of the “it depends” is hiding in the ability to create an asynchronous loop of valuable inputs into the product vision and UX concepts. What if we all were able to see as one without the drain of a meeting? To give it a personal perspective, through all the years of working with clients I’ve felt a disconnect, a slight or at times a larger one, between what production does, and what leads and customers want and feel. We’re doing better now, which is great, and people who interface with leads and customers are able to make a meaningful input at the product board meetings. In our company, the product board is a 7-member decision-making unit, which includes developers, UX-ers and people who interface with leads and customers. The only nasty problem that persists is that meetings are a work in itself. If only someone’s job would be solely to attend meetings. There’re other tangible tasks to do. Designers need to actually create sketches and prototypes, developers need to build the architecture and write the code, and marketing/support people need probably even more energy as they are always in the trenches, talking to leads and customers. Oh. And product managers and feature owners are responsible for smart product decisions.
Unfortunately, smart product decisions are not 100% guaranteed by those meetings only. We’re sticking to the board meetings approach so far, and it’s definitely a step ahead in our evolution. Seven minds are always better than one mind. But is there a comfortable, slow-paced way for those 7 minds to unite in one vision? If seven people are trying to share their product perspectives over a short time frame, as in a meeting, that’s where the ultimate, never-mentioned source of this exhausting drain sits. It’s simply about the way we are wired. You just can’t pour your vision from your brain to someone else’s brain in one quick shot. It’s not like with whisky. It’s exactly for that reason that we inevitably face the need for building the gradual, asynchronous awareness of the product as a whole. This is related to Michael’s recent Specialize or Generalize post, and it goes beyond the boundaries of software development as such.
Back to 37 signals. Their “Meetings are Toxic” judgement is sharp, clear and perfectly correct in the context of their evolution. We’re doing things our way, as we try to back up meetings with various asynchronous ways of building and sharing a versatile product vision e.g. Google Groups, internal blogs, wikis, talks in the office kitchen, etc. Asynchronous exchanges are compulsory homework before the meetings; they work great for any knowledge work, for many reasons, and it would take a yet another blog post to tell more about that. For now, I will just reference this great article on asynchronous communication.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)