How to keep engineers out of meeting hell
morethancoding.comI 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 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.
> 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. 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 :(
>not everyone has good E-mail hygiene
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.
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, dude, do you realize how much of a huge problem you are?
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 other commonly-used communication mechanisms for important things (e.g. Slack or meetings). That's not to say that 200k unread emails is acceptable, it's well worth periodically deleting all the crap, but the "red bubble" notification count is useless if too much of email is noise.
>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.
I have filters set up. But that's treating the symptom; it requires constant maintenance of the filters because people keep adding more lists, or some manager decides to change the name of the list because they re-branded some internal team name, or whatever. It's just noise. It's work to deal with it. Reducing the noise at the source is better than trying to filter it, and filtering it is better than ignoring the entire system, but the end result when it gets bad is that many users ignore the entire system.
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.
I think you're overblowing the difficulty of creating filters. It's one of those tasks that pays power-law dividends forever. Sure, I initially sat there for 3 hours making the filter list, and every week or two I have to spend 37 seconds adding a filter, but my inbox has zero emails, and the vast majority that hit my inbox are non-noise things I actually want to read or respond to. It certainly beats the daily sense of defeat a 100,000 unread bubble must instill daily. Inbox zero is luxurious and relaxing lifestyle - a plane of existence a lot of us have reached. Imagine no more stress. Join us. PS - I haven't gotten a spam call or text in ~6 months. There are filters for that too (3-layer Google Voice spam filter + Verizon spam filter + Samsung spam filter = nearly perfect filtering, with no false positives in a decade that I've been aware of)
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."
If people aren't responding to emails that are supposedly important, then the incentive structures aren't aligned so that they do respond. I wouldn't say that not having a meeting is an incentive to reply, the incentive is having your opinion heard and considered in future discussions.
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.
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.
We are 100% on the same page. All of these send a message and are professional
I use meeting invites as insurance against my emails going unanswered
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 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.
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 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.
> No there aren't.
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.
> unreasonably upset
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?).
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.
I've seen this argument often but I'd guess 50-75% of the meetings in my organization could've been handled in an email. Often times the only reason we have a meeting in the first place instead of an email is because of the politics around things, which to me is a sign of inefficiency in the 1st place.
I've seen that different teams have different priorities, and while emails do help avoid many meetings, there's nothing like an in-person meeting to coordinate efforts.
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.
> There are some who believe that meetings never accomplish anything.
No more than those that believe every last one is 100% useful.
> 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.
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 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.
> 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.
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 communication to that fact then people might be more inclined to resolve the issue sooner, even if comms are async.
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.
> 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 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
> 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.
> Because it's now become a performance.
Being accountable is arguably a performance.
Job performance.
> You sure?
Yes.
Under-appreciated factor here: a hell of a lot of people—even in the corporate world, even (somehow!) college graduates—are shockingly bad at reading comprehension (which is simply being bad at reading) and at writing clearly (or, simply bad at writing).
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.
Absolutely this. The key to making those meetings effective is starting with an agenda and leaving with either a decision or action items that will lead to a decision.
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 within some guardrails keeps the ICs and management at their best.
> 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.
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.
> 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 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.
I personally take an adversarial view on management because the large majority of the 'managers' I have had in the past were useless to the point of providing negative value, to both the technical and to the business side, so my views are colored by that fact. Not all of them of course, and they were the good ones. But most were just managers in name only.
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.
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.
> There are some who believe that meetings are work.
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.
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.
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 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.
In a previous role I was responsible for developing architecture that supported a bunch of different teams, so I started being pulled into a lot of meetings as the easy option for them was asking me. I ended up having 6-8 hours of meetings a day on top of my actual workload.
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.
> Sometimes people play power games or bypass roadmaps.
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.
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.
i'll add that there you can avoid making people mad at you by communicating why you’re cancelling. you don't need to be mean, just explain that your contribution wont be valuable and the task your working on has higher priority etc.
> cancelling
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.
“An engineer’s impact during a meeting is less tangible compared to coding”
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.
This is not because of the nature of meetings, but because people seem to have lost the skills to have effective meetings.
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).
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 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.
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.
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.
> they need constant Q&A
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)
The concept of "decision meetings" is a really tricky one to master. I think:
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 article doesn't mention the problem of people not preparing for a meeting. It's possible to follow all the author's suggestions about meetings and still end up wasting time because people show up unprepared. Someone doesn't read the agenda or doesn't know or understand the desired outcome or decision to be made. If that is a pattern for someone, they not only are under-performing, they are hurting the performance of everyone involved.
People complain about meandering discussion meetings and how to avoid them, but those are the only things that actually should be meetings. If you know what information you need to get out of people, just ask them to send that info in an email. If you know what decisions you need made, send the decision makers the information and ask them to make a call. If you know what people need to be informed about, again you just send it out. All of this should be done asynchronously.
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.
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 :-)
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.
One of the first things I do as an IC when joining a team is establish whether law of two feet applies. That is, if you're in a meeting which you can't contribute anything to you get up and leave. Even better is to have this conversation at a time when everyone's present so there's no ambiguity. When the answer's not yes it's almost always a signal of bad things over the horizon.
Have weekdays where booked meetings are not allowed. This gives you a ground truth to compare meeting heavy days against.
We had "no meeting Fridays", which were always my most meeting-heavy days, because that's when everyone has a clear schedule!
If they were the most productive meetings of the week… sounds not bad at all ^_^
At some point during the pandemic, it feels like Friday became that at a lot of places. I hesitate about even sending chats or emails at this point.
“How do we know when we’re finished” is the most important question maybe ever.
A meeting without an agenda isn't a meeting. I can give you a status report via email so don't need a meeting for that. I might not give you a status report because I don't want to. Any meeting an hour long is a waste of time. If it can't be said in 30 mins max then you're wasting my time. I don't need 10 mins of meet and greet. Get into the topic. Make decisions and move on. Don't invite people to meetings who are not key stakeholders in decision making. Meetings are not there for observers and you only get invited in you contribute and have value.
Stop equating engineers with web developers. Some engineers go to meetings because coordinating complex projects is hard. I really didn't like 6 hour meetings, but when you have a expensive engine project, you have to.
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?
I'm guessing you're in in automotive or aerospace based off the engine piece. I agree, but I would presume a day long meeting leading up to a wind-tunnel test for example would have a full agenda of presentations based off simulations performed, set-up/teardown overview, scheme of testing to be performed, facility status, emergencies, data acquisition, etc. For this all the relevant teams would expect to have significant engagement and contributions. I think this is different from what people complain about. I work in satellite ops and we suffer from those types of issues (unnecessary stand-ups, status reports that could be an email etc.) despite the need to sober up and have runs where it's a lot closer to the former than the latter.
You know how you do this? You keep the org not as flat as possible, but flatter. People find one another dynamically to share understanding. Would be middle managers join your competitors, to your org's competitive advantage.
Disclaimer: I am relaying what i learned working years in Apple engineering (as above) and Motorola Labs (above) versus ridiculous Amazon etc.
Isn't pair programming just one, endless meeting?
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
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.
> 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.
If you are experiencing this frequently, your team may have general communication and planning issues.
a slack message can solve that
We tried variations of some of these concepts at a previous company that was stuck in meeting hell.
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.
The most productive meetings I have are never the ones scheduled, they’re impromptu between myself and another engineer just chatting. Sometimes, one of us mentions a problem and the other offers an idea that pushes toward the solution. Every other meeting I have is pointless and the “leader” should have just sent an email.
Most successful org I was involved with was a tiny startup that had daily 15 minute max face to face stand up meetings right after lunch with 3 items on the agenda: Wins, Blockers, Next Steps. Detailed status was done with a weekly email that got archived in a visible project history.
Meetings are the only way to grow your career unfortunately. Nobody really cares how shiny your code is.
Depends on the meeting. A demo for clients or higher ups? Sure. A stategy meeting that you don't have anything to contribute to? No. A meeting going over an email, that itself should've just been an email? Definitely not.
This is hilariously incorrect. There are plenty of organizations where delivery is the ultimate indicator of value.
Being an anti-meeting crusader is great, but if you don't step up to monitor and properly respond in all async channels, then know that your behaviour in the eyes of a lot of people who matter is straight up career-limiting. Do not do that.
> run a super fast retro with a couple of questions like these: “Was this meeting needed?”
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".
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.
> Eight 1:1 weekly meetings (4 hrs) > I’m not even a lead or anything
This does not compute to me, do you have 8 managers? What's the content of these meetings?
We prioritize relationships a ton here and so I meet 1:1 with each of my peers in both teams (3) and each manager of both teams, so that’s 8 people per week.
The entire company has extensive amounts of 1:1s. Were in the mid 40’s of employee count.
I do. At a previous company, we had 1 meeting per week max. Your manager was a more senior engineer. There were no standups, no 1:1's or other extra bull. If you had a question or concern, you just walked into their office and discussed it like an adult. Most of my early career was like this actually. It wasn't until we hit 2010 or so that agile/scrum took over.
I don't think the frequency or duration of meetings is the (biggest) problem - it is the undefined scope, undefined outcome, unnecessary attendants and dragging along for much longer than needed that actually block some people achieving their goals and doing their work, which may or may not overlap with the organizer or other participants.
We got a 1-2 hour weekly team meeting, and then just project-specific ones, usually with clients or other internal teams. So depending on how many projects are going on at once, that'll be 1-3 meetings per week typically, and they'll often be 15-30min, 1 hr tops.
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.
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.
It depends on the meeting, I had serious issues at a previous company where the non-engineers were “planning ahead” and wanting discussion, details and estimates for work we were not thinking of or looking at. I’m big on: when in doubt, prototype, investigate, etc. This was very disruptive to our current work trying to do this in parallel.
If everyone is meeting daily, why would you also need to meet twice a week?
That seems insane to me.
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 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.
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.
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.
Or you know, the impact of context switching on you and on most other engineers is not the same. But no, that's not possible, everyone is exactly just like you, they're all just whiners.
I think meetings are almost always unnecessary. They are something that project managers and managers like to have because it gives them work to appear to be doing. They can say they have done meetings to justify themselves. There is another reason to have meetings which is basically to spy on employees. To me a stand up meeting feels more like management attempting to assess the workforce's compliance more so than trying to learn what is going on. A slack message could have done it all for less.
So.. uhh, I’m just.. D-Do we need a meeting for this? Do we want something weekly or?
My favorite is "I hate to add another meeting to our calendars, but..."
Title says “engineer” but article is solely about computer programmers? Isn’t that computer science? I don’t remember there being a coding engineer at my college…
"Software Engineer" is a pretty commonly used title for programmers
It is, especially in the US, but the title "engineer" is protected by law in some jurisdictions.
You're trolling, aren't you