Live data from Hacker News

How to keep engineers out of meeting hell

morethancoding.com

41–50 of 117 posts

Re: How to keep engineers out of meeting hell

#41
post #21

I'm curious about what everyone considers to be a high frequency of meetings. Two 1-hour team meetings per week, along with a daily 15-minute stand-up meeting. Do you think this frequency is high?

I have two daily stand-ups (30 minutes) with different teams I’m a part of

A weekly status meeting (1 hr)

Three weekly status meeting update planning meetings (1 hr each)

Sprint planning every other week (2 hr)

Demo and retros every other week (2 hr)

Eight 1:1 weekly meetings (4 hrs)

That’s 12.5 hours per week so far without even counting any real project meeting where we solve anything. I’m generally around 16 hours a week in meetings and I’m not even a lead or anything. Just a standard coder at a small company.

And our velocity shows it. We’re slow at getting stuff done cause we just don’t have windows of time to focus. When meetings are only an hour apart, I rarely get to do anything productive between them. So two hour meetings can eat three hours+ of productivity.

Re: How to keep engineers out of meeting hell

#42

Earlier quoted context omitted.

have you tried pair programming? because no..

If it’s regularly-scheduled rather than need-driven: then yes.

done right it's terrible, done properly in the right team it's amazing.

it's just 1 work technique. but i've never been in a team where it felt like a meeting. you're literally writing code together, i've never done that in a meeting

Re: How to keep engineers out of meeting hell

#43

There are some who believe that meetings are work. If those people are in charge of an organization, there will be tension with people who have real tasks and deliverables. My preferred approach is not to modify the meetings to make them more efficient, but to go on an extremist crusade against all meetings. Insist on asynchronous communication. Create dashboards with whatever metrics are discussed at status update m…

Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output? To be clear, this doesn't mean 100% sync. But a 10 minute daily sync can ensure the team is focused on producing something of business value. Maximal autonomy withi…

> Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output?

A good leader then talks to the team as the professional adults they are to understand why there isn't communication at the cadence that was agreed upon and discusses why such communication is important.

Re: How to keep engineers out of meeting hell

#44
post #9

I actively fight against meeting hell. If I get a meeting request without a specific agenda (I don't split hairs with the definition of "agenda" or "outcome" like the article though), I ask for one and don't accept it otherwise. If the agenda makes it clear that this can be answered via email, I answer it and decline. If I'm in a meeting that seemed reasonable for me to attend, but I'm not adding/receiving value, or…

I’m the meeting sender, but I usually send a few emails before where I say something like “if you’d prefer we can discuss in a meeting”. I try to give people an out of a meeting. You’d be surprised at how many engineers take the meeting rather than spend 15 minutes on the email.

That said the high bandwidth meeting often accomplishes in 30 minutes what would take 10 email turns to clarify.

Re: How to keep engineers out of meeting hell

#45
post #11

As a lead I used to tick a few people off by occasionally declining meetings. The result is that I developed a mystique, and when I needed to get peoples' attention, I could get it. As an engineer it's important to feel comfortable occasionally declining BS meetings: it reflects more poorly on the person who can't get people to come to their meetings than on you. (Even though people might appear mad at you.) It's als…

Yes! Decline meetings that you have nothing to contribute to and nothing to learn from! Don't be bashful about it. Maybe I'm extremely lucky, but I've never worked at a place where there was this weird taboo against declining meetings. We're all grown-ups and presumably were hired partially because we know how to manage our time, so manage yours!

I'm double- or triple-booked for most hours of the day. I casually decline meetings all the time and don't sweat it even in the slightest. I don't recall the last time someone asked me, "Hey, you were supposed to show your face at Meeting X, why weren't you there???" This happens in crappy companies.

Re: How to keep engineers out of meeting hell

#47

There are some who believe that meetings are work. If those people are in charge of an organization, there will be tension with people who have real tasks and deliverables. My preferred approach is not to modify the meetings to make them more efficient, but to go on an extremist crusade against all meetings. Insist on asynchronous communication. Create dashboards with whatever metrics are discussed at status update m…

> Insist on asynchronous communication.

Not disagreeing, but you've also got to be mindful of scenarios where there is something which needs to be hashed out and neither party fully owns the thing.

If you don't nip it in the bud by getting those people together on a call or in the room together, you can end up with a lot of unnecessary back and forth.

Getting people in the room together is particularly effective for such cases.

Re: How to keep engineers out of meeting hell

#48

There are some who believe that meetings are work. If those people are in charge of an organization, there will be tension with people who have real tasks and deliverables. My preferred approach is not to modify the meetings to make them more efficient, but to go on an extremist crusade against all meetings. Insist on asynchronous communication. Create dashboards with whatever metrics are discussed at status update m…

Leaders have a responsibility to ensure their teams deliver. When the teams agree to async communication --and the channels remain silent-- where is the accountability when there is no deliverable and no visibility into the scenario that led to no output? To be clear, this doesn't mean 100% sync. But a 10 minute daily sync can ensure the team is focused on producing something of business value. Maximal autonomy withi…

If there's no deliverable and no visibility, that's a failure of management, either to define the deliverable to a more granular extent where an update could cover the progress, even if async, which would also fix not having visibility. A developer piping up async and saying 'no updates, still working' is still an update and gives visibility.

If they (managers) want to lord over the process and do work for work's sake, then they should write out requirements that say "thou shalt commit one line of code by X date". It just comes down to the individuals doing the 'management' being lazy if they're in this position expecting their 'reports' to drop everything and context switch to a meeting when they can't be arsed to do the managing.

Re: How to keep engineers out of meeting hell

#49

Earlier quoted context omitted.

If it’s regularly-scheduled rather than need-driven: then yes.

done right it's terrible, done properly in the right team it's amazing. it's just 1 work technique. but i've never been in a team where it felt like a meeting. you're literally writing code together, i've never done that in a meeting

Done well but not on an as-needed basis, it bears a lost-productivity and energy-draining similarity to meetings.

Done poorly and not as-needed, it’s a living hell (but then, many business-things are when done poorly)

Re: How to keep engineers out of meeting hell

#50

Every meeting should have: * an agenda, so people know what is going to be discussed and the right people can be in the meeting, and how long it might take * expected outcomes - e.g. Are we just discussing something, are we deciding something If those two things aren't done, it's likely not to be an effective meeting.

Let me add: A notetaker and published minutes, so everything discussed and decided can be referenced later.

Indeed, and actions assigned to accountable individuals etc. How to run an effective meeting is another topic entirely :-)
Post reply on HN