How to keep engineers out of meeting hell
morethancoding.com
morethancoding.com
If I'm in a meeting that seemed reasonable for me to attend, but I'm not adding/receiving value, or the meeting is straying from the agenda topics, I'll ask what input is needed from me or leave a message in the chat that I'm dropping and to ping me when needed.
I also decline meeting requests outside of my working hours (unless it's with someone too many time zones away for our workdays to overlap). My favorite was when someone set up a meeting with me on Friday after I went home for the weekend and when I didn't attend, they added me to a meeting on Monday morning before my work day started. They were angry at me for not attending either meeting. Of course, I never even saw the invites.
I think most people get is, but the point it, we have to set these boundaries for ourselves, and I'm sure it's not just engineers who want to avoid meeting hell.
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. And when you don't respond, I have no idea whether you even read it, so I have to assume you didn't. When I need someone to do/say something, I will reach for E-mail as a first try, but if you don't respond, I have to put on my Disappointed Face and schedule a meeting :(
This is so true at my workplace, thinking back. The folks with unreplied emails cluttering their inboxes are exactly who get pulled into meetings. It's basically an emergency handholding step to get them to actually do some work. The folks who clearly reach inbox zero once or twice a day, I honestly barely remember their faces because folks don't dare waste their time with meetings.
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.
It's a lot like phone calls: 90% of incoming calls I get are spam. I no longer answer calls that aren't in my contacts list, I add businesses I interact with to my contact list if I want to get their calls. Everything else goes to voicemail, and my voicemail is "Due to a high volume of automated calls, all numbers not on my contacts list are voicemail only. Please leave a message." Filtered! But also makes the phone pretty useless for initial immediate interaction.
Also if there are the occasional emails that actually do need an answer/decision/action Right This Second or whatever and people aren't, then the expectation that people reply isn't being sufficiently set and carried out. Add that to the cornucopia of BS that is management mismanagement.
That said the high bandwidth meeting often accomplishes in 30 minutes what would take 10 email turns to clarify.
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.
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 meetings. Have people write memos explaining new proposals. Some meetings will survive the crusade, and that’s ok. All meetings aren’t actually bad, but that should be the default.
Also, the more your meeting goes beyong half an hour, the less fruitful it becomes. Half-hour meetings are the most productive, one-hour meetings are understandable, multi-hour meetings are dreadful.
No there aren't. If you are consistently getting push backs on meetings within your org it's not that the teams or IC's believe that meetings are useless (what a silly thing to say) it's a sign that they don't have faith in the organization structure to concretely do anything with the information or provide valuable input.
If you try to setup a meeting and get push back you should _immediately_ ask yourself why the other person feels that way about the people involved or even yourself.
Reading other comments in this thread will reveal a lot of them. :)
I've worked remote and across time zones for a while. I've encountered a few too many engineers who think any form of meeting or even communication is an unnecessary burden. They just want a queue of perfectly defined tickets to pull from and nobody to bother them until it's done at whatever pace they feel like working that week.
Strangely, being in a low-meeting company seems to make it worse, because meetings are so few and far between that some people get unreasonably upset when their week goes from 1 meeting to 2 meetings because we dared double their meeting load this week.
I suspect some people have a conditioned pathological response to meetings - µPTSD.
Watch a bit of the GitLab Meeting Similator video and who could retain their sanity if they must participate: https://m.youtube.com/watch?v=rOqgRiNMVqg Watch the lady in the bottom panel struggle to look appropriately interested (or am I just projecting?).
No more than those that believe every last one is 100% useful.
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.
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.
That's really the bare minimum that a developer can say and still get away with when you have a lenient manager. HN tends to take the most adversarial take on managers possible, but it's not always necessary.
But, when you've worn both hats (manager and managed), sometimes employees simply don't want to do much work. Again, you can say "that's a management problem", but some people are bad actors and are very good at hiding it in "corporate speak". The internet is full of stories of coasting --- I can even attest to doing it many times and easily getting away with it. Getting someone in a room, or on camera, and actually running through their work can cut through a lot of bullshit and bullshitters. Some developers think "coding" takes precedence over the business -- but some of their "coding" time is completely useless to the business perspective. It seems crazy to insist that managers have no stake in trying to figure out if that's the case.
Sometimes you also need to have a meeting because in an async setting some people have no idea what they're doing. Even with clear goals and deliverables, stuff can easily fall through the cracks.
A coasting employee may be a problem of the employee's making, but it is still a failure of management. If an employee isn't doing anything then you fire them. But it's still a failure of management because that wasn't fixed right away. And again, if someone doesn't know what they are doing (if that's truly the case why did you hire them, but that's another conversation), even async, a keen manager should be able to pick up on that and provide coaching, connections, or other resources--you know, actually 'manage' this person. Failing all that, then cut them loose. But it's still the manager's problem.
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.
I see it like this: people are going back and forth over email and waffling then it's probably not that important, why should it be any different in person aside from the fact they're performing for management.
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 should it be any different in person aside from the fact they're performing for management.
There's many reasons why in-person is more effective:
- Fewer distractions
- More emotional investment in the discussion (the same dynamic where people are more polite in person, but less so on internet forums)
- More "skin in the game" by making more of an effort to show up
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.
Being accountable is arguably a performance.
Job performance.
> You sure?
Yes.
I suspect the population for whom this holds isn’t much smaller than the famously-a-majority “bad at math” set, and the difference in visibility of the issue is because the “bad at literacy” folks don’t volunteer their status as readily as the bad-at-math folks.
I’ve seen some people who will fill the week up with Groundhog’s Day-style repeat meetings, and even the basic expectation that they have an agenda, goals, and need to summarize what was decided afterwards increases the cost to them personally enough to make better use of everyone’s time.
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.
Meetings are work. Not practical work, but management work, which is very valuable to coordinate and unify efforts.
I agree, though, that there are people who like meetings for meetings's sake, and those waste eveyone's time. In my experience, they're usually executives with little practical background. They use meetings primarily for politics/socialization, and have the power to summon as many meetings as they wish.
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.
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 also critical to decline project kick-off meetings unless you've been explicitly informed about the project by your manager. Sometimes people play power games or bypass roadmaps. Other times your manager forgets to tell you you're on a project. Either way, it again makes the meeting organizer look bad if you aren't there.
The people that do this are the same people that send the same request to several different people in hopes that one of them will do it, resulting in duplicate effort.
I didn't cancel, I declined meetings. There is a very important difference.
> i'll add that there you can avoid making people mad at you by communicating why
I usually gave a reason, but when there was a large invite list, or no notice, I did not.
The one time I "got into trouble" was when I gave a reason: "I am declining this meeting because there is no agenda." My manager told me to just have him intervene instead of declining the meeting.
My solution was to not accept meetings and have a PM go grab me if they really needed me, that was enough friction to allow me time to get work done. As in your case, this created a bunch of mystique as I was now that guy that showed up in the middle of a meeting, said a bunch of smart things (hopefully!) and then left.
One of the difference about the new Zoom-centric world is that it's zero effort to add an somebody to a meeting "just in case". I push my leads to decline meetings where there is no clear agenda and/or clear idea of the value they can provide. It's ok that your default isn't to hit "accept", it's the meeting organizer's job to convince you that it's worth attending over other priorities.
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.
The common disdain to meetings is that in many meetings no one has a tangible impact while an engineer can create tangible value in their “regular” stated mission. If reading this makes you feel offended then don’t worry, it’s surely not your meetings… only those organized by functionaries whose sole contribution is organizing open ended meetings with no impact.
Start by sharing an agenda. List the very few things you need to discuss and decide up front. Provide review materials for those who actually prep. During the meeting, record notes on the conversation, record decisions made, and record action items, and publish these records.
If you're not prepared to do this, you aren't prepared to meet. You're just having a chat. That can be done ad-hoc. Call it a chat. Have it over Slack or one-on-one. More than one person requires an agenda, and should result, at a minimum, in a document that adds to the organization's knowledge (even if only of decisions or disagreements).
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 schedule.
PG suggests partitioning the day to AM being maker’s schedule and PM being manager’s schedule. (A form of office hours).
This works if you have power and can swing this. But I’d be curious to hear what ICs do.
I personally just block off my calendar and decline meetings (with reasons given, always politely). I also entertain speculative meetings — I never want to shut myself off to new ideas. Most of my career has been built on serendipitous meetings by people who want to share a crazy idea.
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.
Wants daily 20-30 minute stand-up/tag-up
Constantly bombards DMs since understanding is weak/research skills are poor
Pull engineers into fringe meetings "Just in case" (can't multi-task since full attention is needed to prevent any harm being done)
Good: Put a meeting on a calendar in the future in order to force all discussion and investigation to happen before that meeting and keep things moving.
Bad: Adding a "decision meeting" doesn't make a decision any easier or harder than before, and doesn't make the research and investigation take any less time than before, and often we don't know what we don't know, so beginning research leads to more research...
I think it is really useful for making decisions that people just don't care that much about and aren't that invested in, since it motivates a timeline for those decisions. Otherwise, it just creates an arbitrary deadline. Why are you working late on a Friday night? Oh, well, my manager created this deadline on Monday morning to make this decision.
The purpose of gathering people together is for handling the situations where you don't know a priori what is needed. For example someone suggests a course of action and someone who knows better can chime in and say "no, we're not doing that for reasons X, Y and Z" which both the person making the suggestion and the person organizing the meeting may have been completely unaware of. Or similarly someone might describe a problem they're having which others might have experience with handling. In the extreme you obviously have situations like brainstorming. Yes, these are interruptions that cut into peoples' productivity, but they're the price you pay for having a team that is more than the sum of its parts. If you're not willing to spend burn a lot of time with a meeting, it's probably not something you should be having a meeting on at all.
The problem is middle managers trying to use meetings to do all of their work for them. Stand up meetings stop being about making sure everyone has situational awareness and instead become a substitute for progress reports. Decision meetings stop being about making sure leaders have all the information they need and become a means for managers to offload responsibility for a decision (and often the blame for any negative consequences)_to the group. Instead of reviewing people's performance and giving useful feedback, managers rely on employees to self regulate based on perceived peer performance norms. Who needs a schedule with strategic goals when you have the action items from last week's minutes? Management is not supposed to be a cushy reward for employees who put in a lot of time and effort, it's a vital part of an efficient team which should have a lot of work to do, and that work should not be done in meetings.
* 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.
* 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.
Why is this industry filled with children? If you are sure you don't need to be in a meeting, decline. Why do these children need blog posts to be a bare minimum adult?
Disclaimer: I am relaying what i learned working years in Apple engineering (as above) and Motorola Labs (above) versus ridiculous Amazon etc.
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 poorly and not as-needed, it’s a living hell (but then, many business-things are when done poorly)
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
“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.
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.
The result, sadly, was: More meetings and more process!
The people responsible for all of the meetings kind of understood the problem, but they only had one tool in their toolbox: Meetings! So they started putting together meetings to discuss the issue Meetings to come up with solutions. Meetings to present new frameworks for meetings. Meetings to look at metrics for meeting time. Meetings to discuss the new system we were using to poll engineers about their feelings about meetings so we could quantify the progress we were making on meetings.
The underlying problem was one of incentives. These people were engaged in a battle of visibility, and their way to staying visible was to call more meetings and generate more activity. The more activity they generated, the more visible they were, and the more important executives thought they looked.
I think the suggestions in the article are great for companies with a mild case of meeting excess, but if a company is so deep in meeting hell that managers don't know how to accomplish anything without calling a lot of big meetings then there's a deeper incentives problem that needs to be addressed.
We just got through a ridiculous slog of PI planning meetings, for which the plans have already been wrecked. This was the one vital question that didn't appear in the retro, instead it was all sickly positive questions like "what went well? what can we do better? what was missing?" and at no point was the floor open to say "this was a big fucking waste of time".
That seems insane to me.
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.
This does not compute to me, do you have 8 managers? What's the content of these meetings?
The entire company has extensive amounts of 1:1s. Were in the mid 40’s of employee count.
Some weeks there might be more, some weeks I just have the team meeting. When there are more I try to get them to fall on the same days, so I still have some empty days left.
We tried using a daily standup but didn't find it productive, so we stopped.
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 and how the business context of their work is irrelevant "just put it in a ticket". So now we have micromanagement up the wazoo with execrable Scrum type meetings.
I love meetings and feel a lot of anger to the type of engineer who thinks it's beneath them. Equally I detest all 'ceremonies', absolute time wasting dregs.
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.