Live data from Hacker News

How to run a meeting (1976)

hbr.org

11–20 of 46 posts

Re: How to run a meeting (1976)

#12
post #7

There 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 le…

That sounds like a lot of verbal fluff. I learned a more pragmatic, even posting-hostile approach to posting:

1. Post message

2. Get upvotes

Re: How to run a meeting (1976)

#14
post #9
post #5

Earlier quoted context omitted.

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 lat…

This is a much more difficult problem at large companies where meeting rooms can be a scarce resource, and other meetings that run long can negatively impact yours.

Having a plan for the meeting and having everybody trying to keep the meeting short helps a lot. I think if you're in a place where you need to write ground rules for meeting there's a larger cultural problem that needs to be addressed.

Re: How to run a meeting (1976)

#15
post #9
post #5

Earlier quoted context omitted.

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 lat…

Our meetings always start late but always end right on time. Either somebody rambles for half an hour to fill the time or the meeting closes in the middle of finding a solution.

Re: How to run a meeting (1976)

#16

There 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-...

Not billing for meeting time? Amateur :P

Re: How to run a meeting (1976)

#17
How meetings are run:

1) Wait 5 to 10 minutes for everyone to join

2) Spend additional 5 minutes getting your computer hooked into the projector and shared with remote participants

3) Read through your powerpoint

4) Ask for feedback. Receive comments about your choice of font for the powerpoint.

5) Thank everyone for the meeting and head to the next one.

Re: How to run a meeting (1976)

#19
My take: 0) invite the right people 1) send all relevant reading material 2 days before meeting 2) have an agenda for the meeting - in the invitation 3) agree who runs the meeting 4) follow the agenda, keep a log of issues that hijack the discussion but leave it at that and keep on with the subject 5) document decisions 6) send email with decisions/actions

Not that complex. I run meetings quite often, and they always work fine. Now workshops are a different think...

Re: How to run a meeting (1976)

#20
post #17

How meetings are run: 1) Wait 5 to 10 minutes for everyone to join 2) Spend additional 5 minutes getting your computer hooked into the projector and shared with remote participants 3) Read through your powerpoint 4) Ask for feedback. Receive comments about your choice of font for the powerpoint. 5) Thank everyone for the meeting and head to the next one.

> Receive comments about your choice of font for the powerpoint.

That would be 2.5, they will be unsolicited, and yes, your font really is too small.

2.6 is where you spend another five minutes faffing about with the font size until everyone is happy.

(which is why I rarely use slides and even more rarely put any text in them)

(but if you're demoing anything on a computer screen, the same applies)

Post reply on HN