Live data from Hacker News

How to keep engineers out of meeting hell

morethancoding.com

101–110 of 117 posts

Re: How to keep engineers out of meeting hell

#101

Earlier quoted context omitted.

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)

where does your "as-needed" idea come from? again, it's lost productivity and energy-draining when done poorly. it seems like you haven't experienced a team doing pair programming well, meaning full buy-in and pairing-trained. some of the most productive teams i've been on worked 5 hours of pairing 4 days/week

> where does your "as-needed" idea come from?

“Could we pair on this? I think you may have some insight on this I don’t.”

“I’m taking two weeks of vacation starting in a couple weeks—let’s pair on a story or two so you’re familiar with the state of this code, CI, and deployment system and can step in if needed”

“I could really use a living rubber duck for this—have you got an hour or so later today?”

[edit]

> again, it's lost productivity and energy-draining when done poorly

Done well but frequently, it definitely tends this way. Doubling the people working on the same code (not in close collaboration on different code—that can be crazy-productive) needs to have a pretty huge benefit to justify that immense cost.

I have seen junior-senior pairing sessions increase the junior’s productivity by more than 2x… but not the total productivity of the pair, on a sheer getting-things-done basis. Happily the benefits carry over into non-pairing time, such that it may end up being a good investment.

Re: How to keep engineers out of meeting hell

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

Weirdly, being remote with a VERY geographically distributed team makes this easier. Meetings mostly need to fall into a fairly narrow range of time slots to be reasonable for everyone. That means almost all meetings land in a 2 hr time slot each day and the number than can be scheduled are limited so if it doesn't have to be a meeting, it isn't.

Or someone gets the short end, like me a European, who has to be on meetings with the US in the late afternoon. I do have the mornings free of meetings, so that's nice at least.

Re: How to keep engineers out of meeting hell

#103

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.

Also:

* a moderator, a role that can be held by literally anyone. The goal of the moderator is to keep everyone to the agenda, manage time and handle Q&A.

Re: How to keep engineers out of meeting hell

#104

Counterpoint. Engineers created meeting hell. You know what's a bad meeting? Any Scrum meeting or status 'sync'. Meetings are invaluable. Get together frequently to talk about what you're actually trying to build with the stakeholders and you don't need process, you barely even need tickets. But you have to be present, involved and responsive to jump on a quick call. Instead engineers whine about context switching an…

Yes. We didn't used to have all this ceremonial crap. I remember having good planning sessions, we'd talk about what were actually going to do, then we'd do it (with some conversations in between as needed), then meet up in a week to see where we were. None of this micromanagement BS.

Re: How to keep engineers out of meeting hell

#105

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…

It isn't that meetings are or aren't work: it's that asynchronous communication takes more time in total as well as more calendar time.

If I need a series of five if-then questions to put together a proposal, and each round trip takes half a day, then we have both already wasted a half hour over what would have taken ten minutes to resolve.

Re: How to keep engineers out of meeting hell

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

The tension is the desired outcome. I know meetings are useful and necessary, but if I start with the extreme position of “all meetings are worthless productivity leeches” it changes the conversation from justifying changing meetings to meetings having to justify their existence. Meetings should have to fight for their lives, not the other way around.

Re: How to keep engineers out of meeting hell

#107

Earlier quoted context omitted.

I remember hauling someone into a meeting because they wouldn't answer a question over E-mail, and after the question was answered, we went on to another topic where he had to present something by sharing his screen. Looked down at the MacOS dock and his E-mail client had one of those red bubbles that shows how many unread E-mails he had, and it was six digits. 241,995 unread E-mails or some ridiculous shit. Like, du…

A big reason for people having tons of unread emails is a poor signal-to-noise ratio of incoming email. When there are multiple useless mailing lists, notifications sent in email, emails where all the important information is in the subject line, etc, and a tiny fraction of actually important emails that require a response, it's much easier to lose track of what's going on. It's even easier to lose track if there are…

>When there are multiple useless mailing lists, notifications sent in email

Never understood why people don't use filters to move these email into their own folders (or label them) and get them out of the inbox. It's really not that hard.

Sure, it's a bit of pain to set up (initially), but not handling it at all is just a sign you're part of the problem.

Re: How to keep engineers out of meeting hell

#108

Counterpoint. Engineers created meeting hell. You know what's a bad meeting? Any Scrum meeting or status 'sync'. Meetings are invaluable. Get together frequently to talk about what you're actually trying to build with the stakeholders and you don't need process, you barely even need tickets. But you have to be present, involved and responsive to jump on a quick call. Instead engineers whine about context switching an…

Well those scrum meetings (back before people capitalized scrum) were owned by self-organizing teams whose agile (which used to also be lower-case) methods were to fit those meetings and all other structure to their needs, adding or discarding freely.

Then came the consultants selling books and then training. And then the Scrum Masters with their certificates. And somehow the whole thing morphed from self-managing teams into externally micromanaged teams.

Hint: the engineers were not consultants nor were they Scrum Masters because they already had plenty of work to do.

Re: How to keep engineers out of meeting hell

#109
post #97
post #84

Earlier quoted context omitted.

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

Conferences can be interesting, too. I know people who got screwed over trying to get $100 for an unrecognized local open source conference while the PMs were all going to Aruba for Agile training because that had a certification so it was obviously a legit educational experience.

Yep, a lot of places allow for 80hrs/2wks of "training". Crazy how popular those Agile/SAFE/AWS/Azure/etc. conferences are in a destination location, meanwhile engineers asking to have time prorated for some graduate coursework is unfathomable.

Re: How to keep engineers out of meeting hell

#110
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 use meeting invites as insurance against my emails going unanswered
Post reply on HN