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.<p>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.<p>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.<p>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.
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.<p>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.
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.<p>As an engineer it's important to feel comfortable <i>occasionally</i> 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.)<p>It's also critical to decline project kick-off meetings unless you've been <i>explicitly informed about the project by your manager</i>. 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.
“An engineer’s impact during a meeting is less tangible compared to coding”<p>The common <i>disdain</i> to meetings is that in many meetings <i>no one</i> 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 <i>your</i> meetings… only those organized by functionaries whose sole contribution is organizing open ended meetings with no impact.
Paul Graham wrote an article about the difference between a Maker’s schedule vs a Manager’s schedule. [1]<p>Powerful people are on a manager’s schedule.<p>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.<p>This is very costly on a Maker’s schedule.<p>PG suggests partitioning the day to AM being maker’s schedule and PM being manager’s schedule. (A form of office hours).<p>This works if you have power and can swing this. But I’d be curious to hear what ICs do.<p>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.<p>[1] <a href="https://paulgraham.com/makersschedule.html" rel="nofollow">https://paulgraham.com/makersschedule.html</a>
The concept of "decision meetings" is a really tricky one to master. I think:<p>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.<p>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...<p>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.
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.<p>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.<p>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:<p>* 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<p>* expected outcomes - e.g. Are we just discussing something, are we deciding something<p>If those two things aren't done, it's likely not to be an effective meeting.
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.
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.<p>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?
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.<p>Disclaimer: I am relaying what i learned working years in Apple engineering (as above) and Motorola Labs (above) versus ridiculous Amazon etc.
> Meetings are interruptions that cause context switches<p>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.
We tried variations of some of these concepts at a previous company that was stuck in meeting hell.<p>The result, sadly, was: More meetings and more process!<p>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.<p>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.<p>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.
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?”<p>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?
Counterpoint. Engineers created meeting hell.<p>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.<p>But you have to be present, involved and responsive to jump on a quick call.<p>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.<p>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.
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.
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…