Live data from Hacker News

How to keep engineers out of meeting hell

morethancoding.com

81–90 of 117 posts

Re: How to keep engineers out of meeting hell

#81
post #25

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…

There are some who believe that meetings never accomplish anything. If those people are in positions of power in an organization, there will be tension with people who use meetings effectively to coordinate, communicate and drive decision making with all stakeholders present.

> There are some who believe that meetings never accomplish anything.

No more than those that believe every last one is 100% useful.

Re: How to keep engineers out of meeting hell

#82

Earlier quoted context omitted.

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

> 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. That's really the bare minimum that a developer can say and still get awa…

If they're coasting then you have a 1-on-1 conversation and if needed fire them. A manager who needs some type of public shamming ritual to do that isn't a good manager. There's a manager fallacy of focusing on minimizing the bad versus maximizing the good. In my experience, it's better to focus on making your best employees more effective versus trying to make your worst employees slightly less ineffective.

Re: How to keep engineers out of meeting hell

#83
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.

This is good though.

I honestly hate meetings with a vague agenda and then when you get there, you have ~5 minutes to make up a plan to conquer Europe during German occupation, or else (in a threatening tone). I am starting to just abort and leave that kind of meetings.

Please tell me what you need, and then I can see if this is a simple e-mail / knowledge base issue I can link you to. Or I see this is a bigger thing, but then I can prepare options, ideas and workarounds how to approach your problem. And then we can send it around to all required people and then we can have an interesting discussion about our points in a meeting after everyone has had a bit of time to think and brainstorm.

Re: How to keep engineers out of meeting hell

#84
post #77
post #47

Earlier quoted context omitted.

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

Yeah, I like the idea of making meetings have some nominal cost - a lot of organizations won’t even blink at letting anyone schedule meetings which cost thousands of dollars per hour but will need three levels of sign-off for a $50 purchase. It feels like there could be a middle ground where you basically get reminded of the cost to the organization. I’ve seen some people who will fill the week up with Groundhog’s Da…

> three levels of sign-off for a $50 purchase.

Christ almighty it's so hard to get one-off software purchases approved, no matter how trivial. And so easy to get approved for hiring more people at the cost of hundreds of thousands of dollars a year.

The corporate world is crazy town sometimes.

Re: How to keep engineers out of meeting hell

#85
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 once worked at a team with two hour "standups", every day. I had to miss one to get a root canal. My teammates were envious.

Re: How to keep engineers out of meeting hell

#86
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…

> If the agenda makes it clear that this can be answered via email, I answer it and decline. You're one of the good ones. The retort to "This meeting could have been an E-mail" is "But, do you respond to your E-mail?" Sometimes we really do need an answer/decision/action, and not everyone has good E-mail hygiene. I have worked with a non-trivial number of people who don't read their E-mail and/or don't respond to it.…

This is exactly it. In most cases what I've seen is that "this meeting could have been an email" can be almost always be responded to with: "This meeting WAS an email. You didn't respond. Now it's a meeting."

Re: How to keep engineers out of meeting hell

#87
post #69

Earlier quoted context omitted.

If it takes corralling people into a meeting and interrupting their day to 'hash out' some aspect of a project, then it's a management failure where the importance of this particular thing wasn't communicated or emphasized before and how the individuals' inputs matter. If everyone understands how this project, regardless of the parties' full ownership or not, or whatever contributes to success because there was clear…

> then it's a management failure where the importance of this particular thing wasn't communicated or emphasized before and how the individuals' inputs matter. Yes. And you can't fix those as an IC, so you just have to work around them. This is like complaining about the direction of the company and advising to fix the root cause of whatever corporate drama - not wrong, just not helpful or practical advice. > why sho…

> Yes. And you can't fix those as an IC, so you just have to work around them.

Sure you can and no you don't have to, you can say so publically, which may give others the courage to do the same, at which point 'management' may see one of two things: there's a critical mass of people that disagree with how we are doing things and move to correct course, or the rabble-rousers are fired. I have personally taken the personal risk to raise issues like that, and have suffered the wrath of thin-skinned managers which placed me into the latter camp, so I'm not suggesting things to just suggest them.

The more I experience insanity like this the more I see that collective action in this manner is the only way developers and other non-managerial folk hope to regain some control and some semblance of normality.

> Fewer distractions

You sure? I sure can definitely zone out and I may do out of spite if we're convened for a meeting that could have been an email chain.

> More emotional investment in the discussion

Because it's now become a performance.

> More "skin in the game"

Again, because it's become a performance for the sake of performance, especially if 'senior leadership' are now involved.

Re: How to keep engineers out of meeting hell

#88
post #54

Paul Graham wrote an article about the difference between a Maker’s schedule vs a Manager’s schedule. [1] Powerful people are on a manager’s schedule. Meetings are a unit of work for a manager, and they freely schedule meetings because there’s very little cost to them. The advantage of this schedule is you can have speculative meetings that potentially open up new opportunities. This is very costly on a Maker’s sched…

personally as a senior engineer & tech-lead in many past jobs I am very bothered by fragmentation of my time. I NEED a block of time to get serious work done especially if its not fully defined yet (i.e.. not like go code this function but more like add a service component). I have not yet read PG's blog on that but its something similar to what I track as in devtime-fragmentation-index. I wish there was a calendar plugin that tracks something like this as there is one to report total meeting time already.

Problem is its hard to convince managers that there was minimal work done this week because I did 3 hours of meetings each day but it was all spread out. its worse with non-technically sound managers because they need constant Q&A.

There was a time when I was working super late because of all the meetings and slack discussions in day time then to do actual coding work I had to find time later in night and my sleep schedule was getting messed up. this persisted until I introduced some hard boundaries. all in all I recommend blocking off time in schedule but thats not a scalable solution unless whole team agrees to it. plus dont get me started on different timezones working together.

Re: How to keep engineers out of meeting hell

#89
post #85
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 once worked at a team with two hour "standups", every day. I had to miss one to get a root canal. My teammates were envious.

same, one I was part of a team that did 1.5 hr stand-up with devs & QA and some external folks everyday in morning. there was no discipline there, people will talk about status, issues they are having then branch out into possible solutions while everybody else is yawning on side. Problem is if you have this its likely a byproduct of some other dysfunction in team like the manager or leads not being technical and unable to communicate across teams.

Re: How to keep engineers out of meeting hell

#90

> Meetings are interruptions that cause context switches This. I find it very difficult to get into a "flow state". Simple meetings such a a standup are highly interruptive for me, especially when time zones push "morning" meetings mid day.

And someone in a "flow state", headed in the wrong direction, is even more wasted time than a meeting to coordinate efforts in the right direction.

a slack message can solve that
Post reply on HN