Hacker News Reader

Comment by stkni | Hacker News Reader

Think I'm with Larry on this one. Someone should chair the meeting and there should be some expected outcome (decision) from it within the alotted time. If we're 45 mins in and no closer to an answer it's time to assign some investigative actions and regroup? Malicious compliance in this context is good, because it creates an environment where meetings end and everyone gets to pee?

View on HN

You're going to have to pick a word which means "a specific group of people get together for a specific period in order to do something which does not result in a specific decision", and be able to allocate time and space for those things, too.

Some examples:

- a class

- a briefing

- a classic "all-hands meeting"

- standup (if you haven't had a standup which ended in 45 seconds because everyone reported "no obstacles, no requests", your standups have too many people in them or your organization is under too much stress)

- lunch-and-learn

Long ago when I was a newb fresh out of college, I worked at a company that religiously enforced the standup rule “If it’s not relevant to EVERYONE in the standup, don’t discuss it in standup.” Then an exec walked in and started taking over the meeting and for some idiotic reason I chimed in with “this isn’t relevant to me, can you bring that up outside standup?” Things got super awkward and later I overheard my boss apologizing to the exec.

My point is, there can be rules about what is and isn’t allowed in a meeting, but the people at the top can always change those rules on a moment’s notice…and those of us who are less socially adept won’t catch on.

Yeah, IMO meetings without a discernible outcome are mostly pointless. It may not be a specific decision, but it should be "tangible". "students learned tech X" is tangible.

Two out of ten attendees talked for 30 minutes and didn't write anything down, really isn't.

For some reason, I'm seeing a lot more hesitance to record or document, and I don't think it is a good thing at all.

Not all meetings have decisions to be made. Some are just discussions of a topic; generally to make sure everyone is on the same page.

If we're being totally honest, a good percentage of meetings in many workplaces are work surrogates. Lots of people happily meeting and accomplishing nothing for the purposes of having the accomplishment that they attended a variety of meetings.

> generally to make sure everyone is on the same page

If everyone is on the same page then there should be a 'page' resulting from the meeting; something to look back at to represent what everyone agreed on. Those are the 'decisions' being made.

The worst meetings are ones where people share ideas, nod their head in agreement, then write nothing down. Inevitably this leads to an identical meeting later down the road, after people have forgotten key details and the game of telephone has distorted others. Then later it leads to upset people when they find, often close to delivery time, that their understanding conflicts with others on the team.

If there's no desire to have updated plans or documentation after the meeting has concluded, then I question the true intent of the meeting. Was it because the person calling the meeting felt out of the loop? Why was that allowed to happen in the first place? Why were the requirements and the team's progress not easy to observe at a glance?

"The worst meetings are ones where people share ideas, nod their head in agreement, then write nothing down".

In companies where presenteeism is valued, this can be a welcome break from pretending to work.

That's valid. I wonder if those who love scheduling meetings partly do so for this reason? Because they aren't kept busy at the desk?

I love meetings that are get togethers to share ideas. Certainly not enough to impact other timelines; but getting together with a broader team of people to discuss what everyone has been dealing with is very valuable. Sometimes you wind up with an action task (like to create documentation on something that multiple people have had issues with), but oftentimes you don't.

I like to say that part of becoming a good software developer is experience. And hearing about other people's experiences helps with that; experience by proxy. It's also why I read (and write) blog posts where people working through issues. Because seeing how the person found, analyzed, and solved the issue can make _me_ a better developer.

It's kind of sad that basic human needs like bathroom breaks require policy intervention

Reply on news.ycombinator.com