Why do we have so many meetings?
nber.org
nber.org
I work with people that...
* When faced with some well-written, succinct email/text explaining both a problem and supposed solution, will "respond" with "let's discuss this" instead of an intelligent response, taking action as proposed, or even mentioning any particular concerns to be discussed / researched ahead of the meeting. They just need it to be spoon fed to them, and need to be "heard", before anything can happen.
* Will ignore requests to review PRs, or look into problems, for weeks on end. When I ask "what would be a good day next week to block off time to review this?", they'll suddenly spring into action, or say that a meeting is not necessary, but prove that in fact it is by refusing to do anything before the prospect of a meeting is raised.
Companies in industries where you can print money (for a while...) usually haven't actually been put under any duress, so any fool can manage them and look like a genius. It's in hard times that you discover whether you're a good manager or not, when the decisions made in good times come home to roost.
Granted, that kind of situation is unlikely to continue indefinitely, but it certainly can happen.
But in my opinion the worship of money and reduction of everything to being solely a dollar maximizer is one of the biggest problems that humanity has at the moment - it is a reduction in purpose by the blind and greedy.
My definition of a well run company is one that is still profitable, but has happy employees who are maximizing their potential and growth. Who is a good tax paying entity so that it contributes back to the society that is supporting it. Is making a healthy return for its shareholders despite all of this, and is not doing anything evil like producing toxic chemicals, harming vulnerable people or polluting the environment.
Is it idealistic? Yes of course it is. Our collective description of greatness should be to aim at perfection so that even falling short of it is still excellent.
Saying it must be well run because its profitable makes me sick, because that line of thinking feeds unrestrained greed, and is exactly the reason our state of capitalism is so unbalanced and full of greed right now.
And then seperatly, we are talking about the definition of "well run companies" and I was putting forward my definition of one, which is what we are talking about in this thread.
I've had projects presented to me over email that sounded great and seemed like they would have good traction, but then fizzled out once I asked if we could discuss it further in person. Blocking off face-to-face time is a signal that the work is important enough to get done.
Therefore, I now no longer rush at all responding to emails unless its actually urgent and concrete. If someone sends vague requests, I just don't ansewr. If they don't come back, I can infer it probably wasn't that important or they found some resolution on their own.
I also never respond to meeting invites just in case I can avoid the meeting. I think I've probably dodged 100 unnecessary meetings over the last couple of years by literally just never responding or showing up. I of course don't do this with 1-1 meetings, but meetings with: multiple people where I'm not needed, there is no listed agenda, and my involvement is not clear; F that.
I also frequently just say "no, I can't", which I didn't for most of my carreer, and just suddenly realized I could do largely without consequences or repercussions. It's fascinating.
This.
I'd also add that not bothering to book a meeting means that people treat you like a low-value work queue that they use to dump low-visibility and low-accountability work. They invoke you to handle silly tasks that no one but you accept.
By requiring a meeting, you're increasing the threshold of effort that your requester is willing to invest in getting it done. If they can't be bothered doing a meeting, you shouldn't bother doing the work for them.
but also, you arent really blcoked on anyones review. just open a fork of their service and run a copy on your own team
The most functional workplaces understand and respect these differences and make room for everyone's communication style.
As far as I'm concerned, responding to some well-prepared prose with "lets discuss this", is just a non-response, and a refusal to engage. If one wanted to have a useful discussion, but preferred something verbal, actually picking up the phone, or responding with something like "I'm curuous about X/Y/Z. Let's discuss this at 2pm, I'll send you an invitation", or "please find some time in my calendar for us to look at this."
That would keep the matter progressing, and provide the opportunity to prepare for a useful discussion. "lets discuss this" is just saying "I need you to spoon-feed this to me, but I'm not going to make arrangements for that, so you'll need to figure out how to deal with that.".
But it took me a long time to realize there can be a sort of “double empathy” problem across communication styles that makes it difficult for people to accurately infer each other’s intent. They might even be operating from two slightly etiquette norms, such that the same behavior is considered polite by one person and dismissive or hostile by the other. Not saying that’s your particular situation, just talking generalities since that’s all I reasonably can speak to on a pseudonymous forum like this.
Personally, I don’t do this; instead I deal with the stress of the fire hose by grinding my teeth to stubs at night. And for the messages I don’t get to, instead of “let’s discuss”, the sender gets nothing at all.
Also GP is presuming the person on the other end should automatically care about request being sent to them. They don't.
Its a very lazy way of filtering.
"It couldn't have been that important" is their logic.
I realize that this looked to the people requesting my attention like deliberate stonewalling. That’s because it was. And it wasn’t cool. But, “This quarter I didn’t ship any software because I was too busy answering email,” would not have earned me a satisfactory performance review. And I certainly was not going to openly admit to anyone but my immediate manager that I was using persistence as a prioritization signal. I saw what happened to the poor schmuck who made that mistake.
scheduling a meeting is telling somebody that you consider this to be a priority and therefore they should too
The current situation I have is that I have 5 people demanding that I have their stuff as a priority, and they will schedule meetings to tell me such.
If I'm in 5 hours of status update and demo meetings every day how much actual work is going to get completed?
Therefore, everyone starts demanding meetings from you, because they have nothing to gain by not doing so -- you wouldn't use the extra time to work on their projects, but on the projects of those who insisted on meetings.
If you have so many meetings that you can't get actual work done, that sucks for everyone, but again, they have nothing to gain by canceling their meeting, unless everyone else does the same thing. But the others won't do the same thing, because now you have time to work on some projects, and they prefer those to be their projects.
The solution is pretty simple: just fire the manager.
But that's very different than when an engineer stays up all night investigating a very serious issue, writing it up completely, and offering multiple solutions in a wall of text that can't be brushed off in Slack. The engineer makes multiple attempts across multiple weeks and communication platforms to get their attention, and it's ignored. Not "we're busy but will get back to you when we can." Just completely ignored.
A high performer (and really anyone) should not have to resign themselves to office politics to workaround this kind of dysfunction. It's imperative to fire such managers so that you don't lose the trust of the people doing the work.
First off, you have to have an agenda. And the agenda has to point to a document that lays out all the things you’re going to talk about. Depending on the nature of the meeting and what you are there to discuss, that might be a simple “one pager” or a more in-depth “two pager”, or a very in-depth “six pager”. But the expectation is that everyone will sit there at the beginning of the meeting and read through the document. If you want to read it in advance, you can do that. But the expectation is that everyone will read it for the first time at the meeting.
Once you’ve all read the document, then you can discuss it.
This method addresses both ends of the “this could have been an e-mail” spectrum. But it requires a lot of rigor, and you have to get good at writing proper documents. Otherwise, you’re going to get destroyed at every meeting where you are the person writing the document. Fortunately, they have a lot of examples you can crib from, so you can get good at this quickly.
They also delegate a lot of responsibility for making decisions to the edge. You can ask around to see if a meeting needs to be held on certain subjects, and the answer is usually “no”. You can make the decision yourself and justify it, and document that justification. Then you move on.
If you’re having a disagreement with someone on a topic, you really need to work hard to come to a consensus or agreement with the other person on that subject. You don’t want to have to write a document and have a meeting with a senior person, and then have them ask “why the fuck didn’t you two guys settle this yourselves instead of bringing this problem to me?” Bring solutions, not problems.
Or, if you have a problem that really is insurmountable, then at least bring along a couple of potential solutions or paths towards potential solutions, and then the meeting becomes a discussion of which path to which solution will be chosen and why.
Not the person you're responding to but just needed to vent that. It's been happening a lot lately in my world
You need to figure out which people are which type. You seem to be a “this could have been an e-mail” type of person. So am I. But my wife is a talker.
For some of those talkers, they actually need to see your face and not just hear your voice. Otherwise, they feel like they’re not getting any information from you.
And for some of those people, it has to be in-person, a video call won’t do — they can’t see your entire environment around you and all the things you can see which they cannot.
To be fair, over 90% of all human communication is not verbalized — it’s in the expression on their face, the way they look around the room, what they’re looking at while they’re talking to you, your body language, the faces you’re making when they are the one talking, etc….
Of the remainder, over 90% is not the actual text of the words being spoken, it’s in the delivery of the words, your tone of voice, are you speaking quickly or slowly, etc….
So, those of us who are on the “this could have been an e-mail” spectrum, we are depending solely on the text in front of us, which is about 1% of the total information that could have been conveyed through non-textual and non-audio parts of the process.
If you’re okay with that, then that’s great! But that only works with other people who are on that end of the spectrum.
So, to get back to my earlier point — you need to know what type of person you are, and you need to know what type of person the other person/people is/are. And you need to adapt your communication style to suit them. Or, make sure that they understand where your limits are and how far you can adapt, and then it’s up to them to try to adapt the rest of that distance.
My wife and I are about to celebrate our 27th anniversary. We are still very much a “work in process” on this topic. I am no expert, but I do have decades of experience with hard lessons that I’ve learned over the years.
"What would be a good day next week to block off time to review this?"
"We don't need a meeting for this, I can get to it <whenever>"
"That's an excellent point, and I tend to agree. Nevertheless, this has been hanging out there for several weeks now. We can schedule the meeting now, and if it ends up getting done before then, it can be canceled.".
The first problem is e-mail fatigue. Many groups have ridiculous amounts of automated e-mails that amount to line noise. The information in them is rarely actionable and certainly never so critical it needs to be read by everyone immediately. "Everything is OK" alarms are fucking infuriating. It's very easy to miss the super highly critical e-mail from a manager that's just a lazily forwarded e-mail from the automated systems. The "Have you seen this?" with the entire contents of the line noise e-mail from the automated system.
Second is people, especially middle management, that for some reason assume e-mail is a real-time communication medium. They send an e-mail and expect the recipients to drop everything to respond to it. Simultaneously the people actually doing work are actually working and not checking their e-mail every nanosecond to see if they need to drop their actual work to explain their actual work to management. So then the middle management sends a cascade of instant messages and schedules meetings to get the people doing actual work to drop everything to explain their actual work. These meetings will inevitably contain complaints about not getting work done.
It's now even worse with AI in the middle. Instead of using LLMs to write easy to scan and digest bullet point e-mails they're used to expand bullet points into useless novellas.
My solutions to these problems are thus:
1. RSS - Automated systems should just emit RSS feeds with their normal status with separate feeds for exceptional conditions. Only in those actual "machine on fire" conditions are e-mails sent by such systems. Parties interested in constant updates just watch their feed reader and everyone has a single source of truth for event logs from the automated systems.
2. Automated systems should just file tickets automatically so everyone involved has a single source of truth and can all collaborate in one place. Even better if the ticket/bug tracker supports RSS because it becomes dead simple for anyone to follow feeds they're interested in and even set up system notifications for new issues.
3. Company/group wide e-mail policies that constantly remind everyone it's not a real-time medium and that filling everyone's inbox with noise is not effective communication. This can be enforced with automated delivery delays guaranteeing e-mail won't be immediately delivered as a safeguard against people using it instead of actual real-time channels.
4. Verbose e-mails are also rarely effective communication and shared LLM prompts that make e-mails shorter and clearer would also help.
Removing most of the noise from e-mail makes it more effective and can make it an actual communication medium. If e-mail becomes effective communication far less of everyone's limited lives needs to be spent zoning out in meetings where their only purpose is to "give a status update".
Back in the days of paper memos the literal cost and effort required to send them required the sender to really think about what they were trying to communicate and how to say it best. Because e-mail is essentially free it is widely abused since so little thought needs to go into its composition and delivery.
You hit the nail on this, a lot coming from middle managers too who still think that a busy calendar of these meetings it means they are very productive. I remember a manager I worked with, he was so keen on having meetings, a discussion between me and a colleague and he overheard it? Meeting to discuss “the conflict”!! It was soul crushing experience thankfully i left quickly, only to know later he started having meetings for meetings, so in those meetings they discuss what they will discuss on the other meetings!
Also, there are some other sinister reasons, an email is an artifact that can be traced and searched, a meeting usually is just verbal communication and even meeting minutes get challenged later.
The solution? Blast the PR into your shared slack noting that it isn't being reviewed on time because maybe XYZ person is busy.
Watch how fast they are suddenly free to review when their name is attached to something in public.
The real solution is to simply fire these people. There is no good excuse for ignoring requests repeatedly besides laziness or self importance.
I used to run build call and this was the bane of my existence. People who just never engage (but pretend they are to get you to go away).
e.g. A new release candidate is built and tested from a commit. Some tests fail and each test failure is blocking unless the product area owner (or test owner) attests that the issue is not a blocker (test flakiness, test environment specific issue, extremely low priority bug, etc). The build can release only when all test blockers are closed out.
Most build call processes I’ve seen burn more time investigating flaky tests than real issues and the person running build call (often the “release driver”) typically wastes significant time flogging people to close out the same flaky bugs from the last build. I strongly recommend not building one if you can avoid it.
I don't think that firing people is an intelligent solution to a problem that boils down to your personal inconvenience.
If you posted a PR and it's awaiting review, it is no longer your problem. You are literally blocked by others. Who knows what they are dealing with? Perhaps they have higher priority items than reviewing your work? I mean, would you stop making this complain after they review your 3rd or 30th PR? Everyone around you also has work to do.
If PR reviews are slow, escalate the issue with your manager.
And in most companies I've worked at you are the one being held responsible for a PR/feature not being merged or finished on time - at least in my experience. You're often working on a different team from the people doing reviews, so in a large enough company they are just a faceless/nameless person from the perspective of your PM.
You are responsible for delivering tasks, but if you are blocked by the process then it's not you who is preventing the task from being delivered. Whether it's the scrum master or sdm or project manager, someone else is responsible for keeping the tasks moving. Once you mark a task as pending review, you are blocked. From that point onward all you have to do is raise awareness of reviewers to the task pending review, and raise visibility with stakeholders that your deliverable is being blocked by the review. As long as you don't slack in raising awareness, it's not your problem anymore.
why are you working on teams where you are always touching somebody else's code without also making friends with them?
This is absolutely not true. If I can’t check in a fix or a feature because someone else isn’t doing the review, it’s definitely still my problem.
It isn't. It's your scrum master's/Manager's problem, because the ticket is blocked in review.
In the meantime you moved on to another task. Because the review is not your problem.
Offloading responsibility for getting code through review to a manager or scrum master sounds at least as dysfunctional as people avoiding doing the reviews.
If that's how you interact with your team members, no wonder they refuse working with you.
What any competent developer does is a) update ticket to move it to review, b) call out the PR in whatever system you guys use, c) after a reasonable amount or time inform your scrum master/manager that your task is code-complete and is blocked by the review, d) update ticket with a notice that PR is still pending review. Go back to step b) and repeat until the PR is merged.
Done.
Updating the ticket and making a best effort to get the ticket moving is all that's expected from you. By design. That's how things are supposed to work. If your manager doesn't care, it's nothing they want to push anyway, as proven by the ticket history.
Weird and abrasive assumption you make.
> Updating the ticket and making a best effort to get the ticket moving is all that's expected from you.
I have never worked somewhere that ran things as you describe. But then everywhere I’ve ever worked has expected a high level of personal responsibility, not “best effort” that consists of a one time Slack message and tagging work as blocked.
Dude, you're the one talking about talking down to people telling them they are not doing their job. Relax.
> I have never worked somewhere that ran things as you describe.
What do you think a PR reviews process is? It is literally "I will be prevented from merging my work so that all of you may have a say on what I'm doing".
This is precisely how and why it is designed to work.
In basic scrum, you know that part where the scrum master asks in daily meeting whether people are blocked? What do you think it is used for?
Pray tell, what do you think a PR is used for, and how does the process work?
What are you talking about? Are you confusing different commenters or are you intentionally trying to put words in my mouth?
And don’t tell people to relax when you are being actively rude.
> What do you think a PR reviews process is?
It is not possible that you suddenly think our disagreement is about what a PR is rather who has responsibility it is to shepherd code through the process.
At this point I doubt your good faith so I’m out. Take care.
This process works so well in a team that are all pushing together.
Moving the ticket along and a slack to the effect of "this one is quick and easy" Vs "this one's a bit gnarly, happy to jump on it with someone" generally sees PRs reviewed very quickly.
A pleading cat gif is usually enough as a reminder.
A well oiled team is working to deliver customer value (internal or external). I've been lucky enough to have had a few teams of incredibly good engineers over the years. So much gets done.
I can see it not working so well in a team of "individuals" focused on their own performance and "personal responsibility" solely for their bit.
The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
This is very likely a big part of the difference. Most of my career has been spent at very large companies. Smaller teams that can manage to be more inwardly focused with fewer cross, team dependencies, can doubtless operate differently.
> The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
That’s not really what I described. I ran the process, not the fundamental go/no go decision, which was a distributed responsibility. That was the exact friction, and it’s very similar to the code review friction in large organizations. A PR author has a responsibility for their PR but it may require sign off from numerous other teams.
Some of this is necessary complexity that arises from large teams building large products. Some of it is certainly dysfunction.
In a gigantic org, you can message them on Teams, but everyone keeps getting messages on Teams constantly so they are probably going to ignore you for an hour.
I've worked at places that operate the way you're describing.
The place I currently work at operates quite differently. We also ship more software, faster, and it's of higher quality.
Make of that what you will.
If your place of work had no one responsible for setting work priorities of managing task delivery and then find yourself blocked by mundane things like a PR then it seems you are developing novel ways of being dysfunctional. Perhaps you PR process is indeed not the problem but a symptom.
TBH I think micromanaging inter-team communication by turning it into a process that requires a responsible individual to run is far more dysfunctional.
Your PR is not the importantest thing being worked on.
What I said is it’s not my manager’s job to wrangle people to do code reviews for me. It’s absurd that the immediate response to friction is to offload it to someone else. Certainly if there is a cultural problem, or misaligned priorities, discuss the general issue with your manager. But “I set the ticket to blocked so I’m done” is not an acceptable process anywhere I’ve ever worked.
Much of the time the person I’m waiting on doesn’t report to my manager anyway. My manager can’t change their priorities any more than I can.
But there exists a manager who is the nearest common ancestor of your and their manager.
This doesn’t change much though. If there is a general problem, it’s likely appropriate to pull in management to figure out the issue. But it’s probably not a management problem that my specific PR needs a review.
Management decides the process, management decides who to hire, management assigns the roles and management decides how urgent the work is.
If the constellation is so that reviews are required, but the reviewer is not under the control by the manager and reviews do not happen, then some manager somewhere made a mistake.
Why? Because PRs are expected to be reviewed. Any process in which that does not work automatically is dysfunctional and needs to be fixed until PRs are being reviewed properly again.
If everything is working as intended, but it's the manager who created a false sense of urgency and pushed all of the responsibility onto the person who cannot do anything about that, then the only person who can fix the problem is the manager and the thing he has to do is something very easy: be more patient.
Edit: It might not be obvious, but all the things you claim that strengthen your position are already table stakes and assumed to happen regardless. The question is, who is responsible for making the invisible and automatic happen? And you're saying the manager can shirk his responsibility onto the blocked employee, which is hilarious because it means your entire operational strategy for fixing a broken process relies purely on being lucky.
Another thing that might not be obvious but if you write a bad pull request and the reviewer tells you it is bad and can't be merged that's on you as well, no shit Sherlock.
Also, management decides whom to blame. :)
I'm sorry to say, but it is. Is your manager responsible for managing workloads, task assignments, and priorities?
> It’s absurd that the immediate response to friction is to offload it to someone else.
That doesn't sound right. A PR review literally requires you to dump your workload onto someone else. Often times a PR requires significant amounts of time to review. Your team members need to set aside significant amounts of time out of their schedule to look at your work.
You cannot frame a problem that fundamentally revolves around dumping work onto someone else as being absurd to dump your work onto someone else. I mean, what do you think happens when you ask someone to review your work? Do you expect your team members to blindly sign off?
It's obviously about offloading work. And it's the Manager's job ro set those priorities.
If you think it is your responsibility to get a reviewer on the other side to prioritise reviewing your work then you basically made yourself responsible for hiring and firing people or reassigning their project responsibilities.
By the time you managed to have your review get through you might not even be a developer anymore.
That’s fair. No one I work with is “just a dev”. Everyone has responsibilities well beyond “take next item off backlog and implement”.
Not necessarily, there are also plenty of cases where a person's KPIs don't match their responsibilities or the actual needs of the team. This is frequently a management problem where resources haven't been properly assigned and the employee will always prioritize what they are evaluated on to minimize friction. Far too often managers collect responsibilities for their team (or are told to take on something), yet have zero plans other than "it will work itself out" and they don't bother to formalize how the requests will be dealt with.
There are certainly a lot of people out there that refuse to do their jobs, but it is common enough that there is something else wrong that a discussion with the manager about where the process is failing is the first step.
It could be more productive than being angry. Or not, but worth a try.
You ask three people what we should do about a problem. They float ideas. You think the discussion is converging on a solution, and then one of them (who hasn't been heard from for the last three days) suddenly protests where the group is going, saying that they don't agree at all, that they have several concerns, that nobody talked to this other group that needs to be consulted, and so on. Then for that other group, nobody responds for a week because they're busy on something else.
A meeting can force people to say what they have to say, now, or be ignored. That forcing function has value.
And it's not (just) that "people refuse to do anything". It's that multiple people, doing things asynchronously, on different time rhythms, sometimes means that the group consensus advances v e r y s l o w l y, if at all.
So they force everything to "let's set up a chat about this".
You know how popular grammarly and 2023-24 era chatgpt were? The prospect of writing an email actually makes most people quite anxious. They are not in the comments of hacker news, as a rule - they're watching YouTube and TV and don't read blogs. Just the way most people prefer to live.
I will ask a relatively simple question via email, and then he will call me back an hour later and leave a voicemail just saying "Sorry I missed you, call me back" instead of even answering my simple question. I'm almost never at my desk, always running around out on the production floor (manufacturing engineer). I'll get his voicemail, call him back and leave HIM a voicemail re-iterating my question, and then I will also send an email again re-iterating my question.
We will go back and forth like this until EVENTUALLY we catch each other at the right time, then it's a quick 2-minute call. It takes days and days, sometimes over a week, to get one single answer that takes 2 minutes to talk over.
He is an external consultant I am working with, so I can't even just walk over to his desk. Absolutely infuriating. As soon as this project is done I am never asking him another question again, I'll find someone else. (I inherited the project and don't have the resources to find another consultant right now)
Called, no answer, left voicemail
Billed 15 minutes
ETA: This is over 20 years ago, btw. I hear it's gotten materially worse. That terrifies me.
"The enemy must not know where I intend to give battle; for if he does not know where I intend to give battle, he must be prepared in a great many places. And when he prepares in a great many places, those I have to fight in any one-given place will be but few."
So, if like most people, your working to live instead living to work - your employer is doing a terrible job incentivizing you to do more than the bare minimum.
We all know you are far better off doing almost nothing and then all your time trying to get promoted for it, than trying to get promoted by actually doing a good job and thinking you'll get promoted based on merit.
It's like watching someone who's expecting a knife fight walk in with a concealed handgun only to be immediately confronted with a tank.
The email is usually an attempt to not waste time in the meeting and get shit done. Leadership always favors those who can make it so. Anyone who stalls for time or hides information will always look bad. I don't get why people so desperately try anyway.
Most of these strange gambits in office politics are a losing game for the inept and inexperienced. One can only wonder why we keep pretending like there even is such a "game" of office politics.
id place the reason that its more work to identify and raise those concerns ahead of time, since if they are correct, you did all that work coming up with the happy path and the issues ahead of time, vs if the issues come up later, you can focus on and fix them as they come up.
i dont think the meeting is in focus at all
Make sure to actually say “autopsy”.
“Inquisition”, “colonoscopy” or “employment review” all work well too.
If you have two Bob’s definitely get them involved.
Then have a practice of letting such meetings be cancelled if the work is done and went well.
This can be done as a consistent and transparent inside joke. Humor often generates the social permission to communicate hard truths, by also providing psychological stress dispertion.
I cannot vouch for any of this, but please share your experiences.
they agree to the thing, but making a meeting moves the priority from low to high because you are signalling through making a meeting that it is high priority
Your “well-written” problem statement will create thankless work for me that nobody will see or appreciate. I know this because “you” usually send me your “urgent” non-issues and (asinine) “solutions” but, being the diplomatic guy that I am and actually understanding the game that I am forced to play, in contrast to you, I will deny, deflect and if cornered, will call a meeting in what can only be described as some form of malicious corporate compliance. This is all because I am too polite and too political to just say “get lost”. I would if I could, but I can’t. “You” usually have some leverage because you are good with networks or the details of FreeBSD or whatever.
Note: THIS IS JUST FOR FUN, because I needed an economic policy thinktank for my agents to query. I had to do the same for CEPR
What bothers me most about meetings is their duration. There's no need to schedule hour-long meetings.
If an email presents some new plan or policy as a "done deal" then what is the point of spending time replying to it?
I suspect office work defaulted to 30 minute calls because of TV/Radio broadcasts in the early 20th century, but I haven't researched this theory further.
So finish them.
"What else is on the agenda?"
"Have we covered off everything?"
"Let's schedule a separate session for that."
"I think we're aligned. Let's wrap up early."
Etc.
The problem, of course, is when an important person is not available so a decision is not made and then when something comes up mid-week, we need to wait another week to have another meeting.
Give people guiderails, let them try (and fail sometimes) and watch them flourish. On the other hand, tell them that they need permissions from X, Y and Z and watch them do the minimum amount possible.
ah, this, so much this
People endlessly defer because they don't want to be the person to "take the blame" for a decision. Making decisions when you don't connect them to an actual goal/plan/vision becomes a liability. The solution is endless meetings where liability is distributed to...everyone in the meeting. It's successful, in a way, but also exhausting and makes you feel like your job involves just tilting at windmills (imaginary crises).
Buried in the pdf in different sections
> Managers attend meetings far more frequently and spend substantially more time in them than non-managerial employees.
> Separately, interactions with senior colleagues are associated with stronger wage growth
A meeting is called to coordinate or communicate. Wadge's law of meetings tell you which one is which.
But not all coordination is top down, sometimes you need your manager to go negotiate a point with another division.
And neither is all communication, most often you can impress on others the potential of a new approach or the problems with the existing one.
The only trouble for the neurodivergent among us is that "appearing to pay attention" is also communication, same goes for eye-contact or not stuttering.
Corolllary is that skip meetings at your own risk, decisions will be made and you won't be in the room where it happens. And don't be the person who is not welcome in meetings, that too eventually makes your pay suffer.
"Wadge’s Law (of Meetings).
Before every formal meeting there’s a smaller, more exclusive, less formal meeting where all the important decisions are made.
This is based on decades of experience in academia and friends’ experience in industry and government. Sometimes there’s an even smaller, more exclusive, less formal pre pre meeting where all the decisions of the pre meeting are made. Maybe even a pre pre pre meeting … until you reach some guy deciding everything in the shower."
https://billwadge.com/2015/10/28/wadges-laws/
(pretty fun read, thanks)
That can take many forms, but communication before a big meeting is common because if you're announcing a new idea, you want people to support it, and springing it on everyone for the first time in a big meeting is just gambling.
Because this is a base intuition and inclination, we employ this clumsily even in cases where it's not really the right tool for the job.
I know many engineers would prefer to just focus on engineering, but creating something meaningful for people means working with and through people. Even the most hands-off, self-service SaaS products depend on this.
Take an extreme case like Minecraft, where a single person behind a computer created a billion-dollar company. I'd argue that even here a significant part of that success came from Notch's very active involvement in the community.
> a significant part of that success came from Notch's very active involvement in the community
I've never heard it argued otherwise, although it probably doesn't get emphasized enough. It was very interesting at the time to watch how closely he interacted with the community, asking opinions and listening, while also making them feel involved by being open about the details of what he was doing. It was a massively refreshing counter to the way the big game studios were coming across so arrogantly at the time, being certain they knew better than their users about what the users wanted. Notch's attitude created that community feel around the game, and made you feel unusually close to the development and even the decision-making processes. That in turn led to word-of-mouth advertising that resulted in Minecraft becoming one of the biggest selling games of all time.
End result: someone was appointed to send an email with the update.
It's the laziest and easiest way to get alignment.
Plus, Not everyone hates it.
It's nice to finally ask Mr A why they said Mr B should be working on login v2 instead of fixing bug b.
Management feels empowered and feels like they know what's going on if everyone meets.
They help people with email jobs to feel important and show everyone else that they're doing something, while simultaneously reducing time available to the people with real work to do, which can then be used by the former group to apply pressure on them.
Not meetings about deadline, or meetings about estimation, but the shared experience of having timed events associated with stakeholders and involved parties.
It's like an invisible cue system the brain adapts to and starts reacting/responding to in the form of scheduling and resource allocation. (Which can be a double edged sword for some people: e.g. when they wait until the meeting to ask a question)
They also drive me crazy since we tend to have many of them with relatively little actionable output, but as others have said what tends to happen in the wake of these is the technical people backchannel our own conversations about what needs doing and the sequencing of what we should build to meet the evolving product vision.
What frustrates me is when I complain about there being many meetings on my calendar I'm told to just decline them, but then I'm effectively ceding authority since the time to voice opposition to a particular plan or task is in whatever meeting I'm declining.
Perhaps all of the above is more prevalent in product-led orgs rather than engineering-led orgs, I'm curious if people on the other side of the spectrum have different anecdotes.
All of this can be avoided in my experience by creating a culture of task assignment. Often I've seen the bug/issue tracking system used to facilitate this but you can use other applications. In this scenario Person A would open a bug detailing what they want done, and either assign it, or put it in the triage queue so Person B get assigned next. Person B reviews, makes any notes, then assigns to Person C. That's it. No meeting.
Meetings that could have been an email, in some ways, are replacing hallway and water cooler conversations. Are they a good replacement for that? Not really.
If you don't like broccoli, it just means you're preparing it wrong. Don't steam it, boil it, or microwave it. Here's how I prep frozen broccoli.
Preheat your oven to 400ºF/200ºC.
As soon as the oven has preheated, put the frozen broccoli into a mixing bowl and drizzle 2tbsp / 30ml of olive oil over it, and toss with your fingers.
Spread the broccoli over a baking sheet, sprinkle a small amount of salt over it, and bake for 20 minutes.
Also, this feels like a great time to reshare that Brussel sprouts really were disgusting 30 years ago, and they are so much better today. https://www.allrecipes.com/science-why-brussels-sprouts-tast...
It’s redundant.
Managers don’t care about the actual work. They just care about the “going to do A Thing” and “Finished A Thing” comms.
So those two slices of bread at the end become two meetings.
Often that’s enough to cause the meeting not to happen.
(We are remote most dayssome have one unstructured morning meeting called “watercooler discussion. Not a standup!!”)
Perhaps the visible actions and text I write are all holographic-principle-like sufficient encoding of my invisible prior thought given sufficient information. Curious to see!
Simple commands, maybe some voluntary muscle control. But nothing as complex as 'What are the pros and cons of these two business approaches?'
- why do meetings make attendees feel important?
- why do everyone pretend to dislike meeting, yet obviously very few actualy do
Isn't someone already working on a system were every employee has an AI companion that would represent them during meetings? The employee chat about the meeting's topic with her avatar beforehand until they are on the same page, then for all the avatars hold a meeting at the speed of light and come back with the overall decision that was reached. No more politics, and perfectly asynchronous. I'd love it.
As responsibilities become increasingly important (more financial import), their work is divided into specialized slices for optimization, redundancy, and bus factor. The number of combinations of people that might be necessary to answer questions or provide guidance in decisioning expands exponentially (small slope, correlating to recruitment). If something in a meeting is considered missed, unsaid, or backtracked, the event is memorialized and pushes for more meeting with a larger audience. The people in large meetings self-select into smaller meetings around their specific vertical interests, in order to align with the interpreted decisions of the larger meetings.
Meeting bloat is the result of a conflux of human behavior, lossy communication, optimized behavior and competing interests. If it was a simple single reason, humans would have solved it long ago.
Now just a click and summon people.
It's like measuring how fast the wheels are spinning rather than how far the car is actually moving.
Getting work done will require combination of biological and silicon agents working together.
Will our silicon counterparts also want as many meetings as biological equivalent to get the same work done?
I could talk about how deal with some of that, but, no.
We have essentially two kinds of meetings:
- daily meetings, scheduled, 30 minutes, with a timer, overruns happen, but rarely, and not by a lot.
- unscheduled meetings, often more than 1 hour, sometime massive overruns
The latter are by far the more useful ones, and because they are infrequent, take less time overall.
The problem with the daily meetings is that they degenerate into everyone taking turns saying what they are doing, who cares except for the manager? And we have Jira, everything is there. Sometime there is something interesting: maybe someone found something to save everyone's time, maybe a strange bug that need some collective mind to figure out, or a breaking change people need to be aware of. But these report are often cut off by "let's move on, we will talk about it later (maybe)", which mean either another meeting, or people missing information.
The unscheduled meeting however usually have a clear goal, and a solution has to come out of it. Cutting the meeting short without a solution loses the entire point, so overruns are common, but in the end, we have something meaningful.
- Talking is confused with doing
- Design / Decision by committee alone is the path of progress, including attempts to improve itself.
I doubt their data would have supported this, but I do wish they had distinguished hybrid from fully distributed. Anecdotally, the one time I worked at a 100% distributed organization the meetings were efficient and the meeting load was low. Not quite as low as the fully in-office companies, but I think some of that was that we deliberately padded meetings with some social time as a stand-in for the water cooler.
Soon no more jobs. Then also no more meetings. Happy happy permanent unemployment