I've found that the person running a meeting really defines the success/utility of a meeting.<p>Some bad practices I've learned from:<p>a) Instead of making a simple decision, plan a meeting, at that meeting plan other meetings.<p>This Dilbert pointy haired boss-style really happened at a very large corporation I once worked at. I actually thought it was a joke the first few times it happened. Ultimately the simple decision was never made, and the endless meetings delayed oversight because the logic was that the decision could come out of just one more meeting. It had the awesome side-effect of making the manager look incredibly busy. At the end of my first 9 months there, the sum total output of a 5 man team came to a 5 page checklist in Excel.<p>Finally, and long overdue, that manager was "realigned". I was put in charge of the team and after an initial kickoff where I assigned appropriate people their tasks, we produced the desired deliverable in 90 days and not a single structured meeting after that...just a few ad hoc get-togethers to check status and align priorities. 7 Years later, that deliverable is still used as the gold standard.<p>b) Be disorganized.<p>If you think pointless meetings are a drag, wait until you end up sitting through week after week of unfocused, disorganized, confusing meetings without clear recaps, minutes, actions or other useful output.<p>A pointless meeting is like being frozen to death, the inaction of it all slowly kills you by sapping your strength. A disorganized meeting generates lots and lots of heat and motion but kills you just as sure as getting lit on fire would. The result is the same, nothing gets accomplished, it's just a matter of how you wish to die.<p>I've had the displeasure of working for/with a few people, usually at smaller companies (50-200 people) for some reason (and usually run over a bad speakerphone as well), who run the most consistently disorganized meetings I've ever encountered: bouncing around the agenda, veering off down irrelevant rabbit holes, no collecting and summarizing of what just happened, no clear actions, things that sound like actions but aren't, no follow up on previous actions etc.<p>Fix this by:<p>- Make a loose agenda<p>- as you work through the agenda, stay on topic and don't veer, but be willing to adjust a little as needed<p>- if you end up veering a little, it's okay, but bring the ship back to center and recap quickly, or set the issue aside for an "offline conversation" or another, more focused meeting just for that topic (if it's big enough)<p>- recap each agenda item before moving to the next one, issue out actions immediately<p>- take meeting notes and send out a recap to all hands, the hour you spend typing it up will save dozens of hours trying to fix bad memory screw ups instead<p>- put the actions in the meeting notes!<p>- use the previous meeting's actions as the framework for this meeting's agenda. Open actions need to be brought up again, this time with a note that it's a repeat x number of times. The more times it repeats, the higher up in priority it goes. If it doesn't move up in priority, it's probably not real anyway and shouldn't have been an action to start with<p>- if you use some kind of work tracking system, file the open actions and assign them immediately after the meeting. Budget time to do this around the meeting.<p>- Running a meeting is a responsibility not a privilege.<p>c) Run a meeting like it's a military exercise.<p>Too many times, at all sizes of organizations, I've run into people who think it's a matter of life or death that meeting run precisely on schedule. I think this is a B-school technique because it always seems to be MBAs who do this. For example, Each agenda item shall take no more than 10 minutes of meeting time, or an hour meeting shall go no longer than one hour, no matter the issues brought up - reschedule the next meeting to take up the issues later. This is dangerous and stupid.<p>Sometimes during meetings, new critical issues pop up, those need to be triaged, actions to remedy need to be discussed and assigned then and there. I've even seen critical deadlines missed because the meeting was going overtime, the deadline was a couple days later, a critical issue popped up and the meeting was closed due to time till the next week. Stupid stupid stupid.<p>The problem still needs to be addressed, but now people are going to do it off-channel, uncoordinated and disorganized with unreliable outcome and no control over the situation, management of expectations, clear communication to stakeholders etc.<p>Worse yet, if the person running the meeting has an honest obligation that forces the meeting to close early, that's one thing, but if they're just closing it down because it's hit its 1 hour mark, people see this and view the meeting manager as disingenuous and weird and end up confused about priorities in the organization. It ends up undermining that person.<p>The best meetings I've seen basically follow a loose template as jacques indicates here <a href="https://news.ycombinator.com/item?id=5968926" rel="nofollow">https://news.ycombinator.com/item?id=5968926</a><p>I'd add that issues that look too big for the current meeting should be sidebarred into another meeting with just the key people involved. It usually is just a two person phone call in reality not a full blown meeting.<p>The meeting notes and rapidly assigned actions really are the critical bits, the "product" of a meeting. The notes inform and remind, follow ups can usually be solved with 10 minute ad-hoc face to face meetings.<p>In a different milieu, I've also liked the daily developer roundup in the morning over coffee. The meeting manager just goes around the table and asks each person what they're working on, what they've accomplished since yesterday and what they have in their queue. These are usually 15 minute informal get togethers, but help set the daily agenda. Other can pop in and offer help, or have help asked of them in this environment and the manager unit and reset daily priorities if they need to to ensure project coordination.<p>I think for small startups (under 15 people), this actually works really well in general, not just with the developers. It lets people understand cross department issues and helps them coordinate across developer/rest of the company boundaries very easily. It even works well with remote and distributed teams. I don't think these need to be dailies, but maybe once every week or two. I've seen startups completely turn around just by adding a weekly all-hands roundup. (it also hilights people who aren't pulling their weight really quickly since they'll have nothing/little to report)<p>Once the company grows a little bigger, you want to start dropping the all-hands aspect in favor of maybe just the department head and a deputy and maybe a senior. Over 20 people I've found these get unwieldy and boring as unrelated departments talk about their work past each other.