How to run a meeting (1976)
hbr.org
How to run a meeting (1976)
1–10 of 46 posts
Re: How to run a meeting (1976)
#2There are sections of this that overlap with how I treat meetings, but overall it seems like a bunch of verbal fluff that's the opposite of what a meeting should be. Exceedingly clear, short, and purposeful.
I learned a more pragmatic, even meeting-hostile approach to meetings: http://hackaday.com/2016/10/06/life-on-contract-how-to-have-...
Re: How to run a meeting (1976)
#3This is helpful for me. I serve on a local board and this very much describes the type of discourse that occurs there. For reference, we run the meetings according to Bourinot's rules of order: https://www.amazon.com/Bourinots-Rules-Order-Assemblies-Shar...
By the same token, this is not terrible useful for me in terms of work meetings which are extremely informal in comparison. They are also intended to achieve a different goal.
I'd say that both types of meetings are appropriate for their goals, but I've also been surprised at just how effective the more formal meetings have been in achieving progress and consensus.
Re: How to run a meeting (1976)
#4Just a couple of days ago I was thinking about this topic exactly.
Considering that I spend upwards of 2 hours per day in meetings it is amazing how little time I have dedicated into thinking about how to make meetings more efficient. I don't think I'm the only one to make this mistake. Just because you have 5 people sitting in a room talking does not mean we are going anywhere or we are making any decisions.
Does anybody have a book recommendation where I can read more about how to maximize productivity of meetings?
Re: How to run a meeting (1976)
#5There are sections of this that overlap with how I treat meetings, but overall it seems like a bunch of verbal fluff that's the opposite of what a meeting should be. Exceedingly clear, short, and purposeful. I learned a more pragmatic, even meeting-hostile approach to meetings: http://hackaday.com/2016/10/06/life-on-contract-how-to-have-...
The hackaday article is close, but not complete.
1. The Problem, communicated in advance, understood by all parties
2. The Exit Condition
3. Time Boxed
4. The Actionable tasks, when they will be done, who they are communicated to
Re: How to run a meeting (1976)
#6A related classic take on how to run meetings: https://www.youtube.com/watch?v=46BFYo4drLc
Re: How to run a meeting (1976)
#7There are sections of this that overlap with how I treat meetings, but overall it seems like a bunch of verbal fluff that's the opposite of what a meeting should be. Exceedingly clear, short, and purposeful. I learned a more pragmatic, even meeting-hostile approach to meetings: http://hackaday.com/2016/10/06/life-on-contract-how-to-have-...
There's little to no fluff in that article. ("Long" is not the same thing as "full of fluff".) He's simply analyzing a somewhat complex and very abstract topic -- how to run meetings in general. There are a lot of possible cases and exceptions that can come up in that structure, and he goes into detail about all of them.
Not every topic can be covered adequately in a pithy aphorism that fits into 140 characters or less. Attempting to jam such a complex topic as "running meetings" into a short format just for the sake of being short would not work. There are too many exceptions and contingencies. If they are ignored, the article would not be not a useful guide to "meetings" in general.
Re: How to run a meeting (1976)
#8There are sections of this that overlap with how I treat meetings, but overall it seems like a bunch of verbal fluff that's the opposite of what a meeting should be. Exceedingly clear, short, and purposeful. I learned a more pragmatic, even meeting-hostile approach to meetings: http://hackaday.com/2016/10/06/life-on-contract-how-to-have-...
The hackaday article is close, but not complete. 1. The Problem, communicated in advance, understood by all parties 2. The Exit Condition 3. Time Boxed 4. The Actionable tasks, when they will be done, who they are communicated to When the exit condition is satisfied, the meeting is over. If the time allotted to the box goes over, the meeting is over. Once the exit condition is satisfied, tasks are allotted with clear…
This needs to be written up into a cheatsheet.
Re: How to run a meeting (1976)
#9There are sections of this that overlap with how I treat meetings, but overall it seems like a bunch of verbal fluff that's the opposite of what a meeting should be. Exceedingly clear, short, and purposeful. I learned a more pragmatic, even meeting-hostile approach to meetings: http://hackaday.com/2016/10/06/life-on-contract-how-to-have-...
The hackaday article is close, but not complete. 1. The Problem, communicated in advance, understood by all parties 2. The Exit Condition 3. Time Boxed 4. The Actionable tasks, when they will be done, who they are communicated to When the exit condition is satisfied, the meeting is over. If the time allotted to the box goes over, the meeting is over. Once the exit condition is satisfied, tasks are allotted with clear…
"Time Boxed" needs to mean boxed on both ends. If a meeting is scheduled to start at 2:00, it starts at 2:00. Not 2:05, not when the last person wanders in, and not when the organizer figures out how to run the projector. The implied task there is that any setup should be done prior to the start time.
Nothing is more frustrating than company cultures which allow the "meetings never start on time, so I'll show up late" / "not everyone is here on time so I'll wait a few more minutes" death spiral. It's like a game of chicken to see who thinks their time is more valuable than everyone else's.
Re: How to run a meeting (1976)
#10There was an old book on the topic. Roberts Rules of Order