The business case for fewer developers in meetings(blog.shimin.io)
blog.shimin.io
The business case for fewer developers in meetings
https://blog.shimin.io/the-business-case-for-fewer-developer-meetings/
26 comments
I used to hate meetings full stop, now I have a more nuanced take: my purpose at work is to create solutions, not code, and all other things being equal, the less code that needs to be written towards that solution, the better.
A good meeting with a clear agenda and outcomes can save hours, or even days or weeks of writing code. A bad meeting - poorly organized and led, clashing egos instead of reasonable arguments, and so on - is something nobody needs.
A good meeting with a clear agenda and outcomes can save hours, or even days or weeks of writing code. A bad meeting - poorly organized and led, clashing egos instead of reasonable arguments, and so on - is something nobody needs.
Meetings are very important. You just need to make sure you are having the right ones if they start to seem pointless.
Ad-hoc, developer initiated meetings are the happy path. I think it is also acceptable and healthy for developers to be required to check in on some weekly call too.
Daily standups are where things start to derail for me. At some level, we need more async written communication. Forcing everyone on the call every single day can feel dystopian depending on your current tasks.
Ad-hoc, developer initiated meetings are the happy path. I think it is also acceptable and healthy for developers to be required to check in on some weekly call too.
Daily standups are where things start to derail for me. At some level, we need more async written communication. Forcing everyone on the call every single day can feel dystopian depending on your current tasks.
Sometimes a daily standup can be a good tool to get a dysfunctional (poorly communicating) team or project into a place where they at least have to get into the habit of communicating with each other enough to convey basic information and tasks on a daily basis.
If the team is already working fine with async communication then it's just another empty ritual that can be safely dropped.
If the team is already working fine with async communication then it's just another empty ritual that can be safely dropped.
For a remote team IMO it's good if your timezone is almost the same. It's the most suitable place to ask others about yesterday's blockers, or when you found something that you want to ask after 4pm. It's also the best place to heads up "I need your help x, lets call after (some time).
Meetings can be very useful, especially when, as you say, they are well prepared, but only when they are not too frequent.
In my experience at many companies, from small startups to large multinational companies, weekly meetings are fine, but daily meetings always waste much more time than they can save.
In my experience at many companies, from small startups to large multinational companies, weekly meetings are fine, but daily meetings always waste much more time than they can save.
This is a great point - there's been a lot of times that I feel like I was able to save the dev team work by being in a meeting and advocating for a solution that would also work well with our existing architecture, rather than something that may sound better but be much more complicated to implement.
How do you manage to move 8 other people's schedules around such that you get these blocks of time? Usually the hardest people to schedule are the manager who wants to sit in on every meeting, and the PM who also wants to be in every meeting. They look at my time and see something easy to schedule, there is a big empty block right there and it fits the tiny sliver of time they have free in the day.
There is an impedance mismatch between professional meeting attenders, and the people the build, and the meeting attenders are in charge.
There is an impedance mismatch between professional meeting attenders, and the people the build, and the meeting attenders are in charge.
How do you manage to move 8 other people's schedules around such that you get these blocks of time?
The way I do it is to block out 4 hours in the afternoon in my calendar as "Focus Time" that people aren't allowed to touch, and let people schedule me into meetings any time other than that. If all the devs on a team do it then the meetings they're required in just naturally gravitate to being shorter ones in the morning with fewer gaps.
I'm quite fortunate in the sense that the company I work in operates as a 'sociocracy' (https://www.sociocracyforall.org/sociocracy/) so teams do actually get to define that this sort of thing is acceptable. In other companies it might be a harder sell, but most managers I've worked with do understand that there's other work to do besides meetings so they're usually open to talking about how to do better as a team. Especially if their bonus is related to performance.
Even if they're not open to talking about it, you can always raise it in every single retro for months until someone starts getting annoyed enough to fix it.
The way I do it is to block out 4 hours in the afternoon in my calendar as "Focus Time" that people aren't allowed to touch, and let people schedule me into meetings any time other than that. If all the devs on a team do it then the meetings they're required in just naturally gravitate to being shorter ones in the morning with fewer gaps.
I'm quite fortunate in the sense that the company I work in operates as a 'sociocracy' (https://www.sociocracyforall.org/sociocracy/) so teams do actually get to define that this sort of thing is acceptable. In other companies it might be a harder sell, but most managers I've worked with do understand that there's other work to do besides meetings so they're usually open to talking about how to do better as a team. Especially if their bonus is related to performance.
Even if they're not open to talking about it, you can always raise it in every single retro for months until someone starts getting annoyed enough to fix it.
Put meetings on your own calendar to block out chunks of time. People will see the conflict and look for a better time.
[deleted]
If your manager does that, they are not very good at their job.
This can be a difficult social problem. Do you need to ask everyone permission? What can you move? Will you make the situation much worse for someone else?
I work at a company trying to solve some of these problems: https://www.getclockwise.com
We let everyone describe their preferences and flexibility and then we optimize meeting placement accordingly. Sorry for the plug.
I work at a company trying to solve some of these problems: https://www.getclockwise.com
We let everyone describe their preferences and flexibility and then we optimize meeting placement accordingly. Sorry for the plug.
I used clockwise before, but the PMs that get slotted into the meetings were the problem. They have every minute blocked up with meetings so there is no flexibility.
> If you hate meetings because they require too much context switching away from code, and they stop you focusing, reorganise them so they don't do that.
If you have such agency, but in a significantly large organization, or even one that's just not empathetic to the issue, getting everyone's schedules to line up is why you end up with such fragmented meeting plans. Of course the meetings are not going to be organized around you specifically, when everyone is also in a half dozen sparodic meetings that they're trying to work around too.
So the solution is to stop requiring so many people in the first place, so that everyone is "across it". It's not just devs either. 95% of the time, I contribute nothing, gain nothing, and could have gotten the same value out of an email summary. I find meetings are often covering a deficit in the planning and documentation of the project. A well planned project, and a well documented technology environment/application, will not need constant meetings in order to transfer tidbits of information over the lossy conduit of verbal meetings.
If you have such agency, but in a significantly large organization, or even one that's just not empathetic to the issue, getting everyone's schedules to line up is why you end up with such fragmented meeting plans. Of course the meetings are not going to be organized around you specifically, when everyone is also in a half dozen sparodic meetings that they're trying to work around too.
So the solution is to stop requiring so many people in the first place, so that everyone is "across it". It's not just devs either. 95% of the time, I contribute nothing, gain nothing, and could have gotten the same value out of an email summary. I find meetings are often covering a deficit in the planning and documentation of the project. A well planned project, and a well documented technology environment/application, will not need constant meetings in order to transfer tidbits of information over the lossy conduit of verbal meetings.
I think this is a misconception that software developers tend to have; their comfort zone, their work passion and their perceived goal is to sit behind a screen and type the code. But that's just the programming part of the job, as a software engineer your responsibilities are much wider. Meetings can (I'm not saying they will) tweak what code needs to be written and how. Left on their own, developers may end up writing code that isn't needed or doesn't do what it's supposed to, which is wasted time, dead code or branches, or worse, sunk cost fallacy kicks in where it's kept anyway because someone wrote it.
I wouldn't have minded more meetings in my current job. I'm leaving in two weeks. Not because of a lack of meetings mind you, it's a combination of factors.
I wouldn't have minded more meetings in my current job. I'm leaving in two weeks. Not because of a lack of meetings mind you, it's a combination of factors.
You’d be surprised how little work can be done by builders, mechanics, farmers, accountants, or doctors in meetings. Experts and creators actually need time to actually work and time to focus on their work.
I'm not sure the article argued all meetings are bad.
I've worked in a lot of places where non-technical managers stick random crap in my calendar all day long. You know, the kind of place that if two devs actually try to discuss an issue it ends up with 1 hour locked in a room with the expectation some winner will emerge.
But that doesn't mean that a meeting about the context of some customer problem is a dud. It's a large part of the reason that product team exists. I rarely got those meetings.
More of them, less of the pointless ones please. :)
I've worked in a lot of places where non-technical managers stick random crap in my calendar all day long. You know, the kind of place that if two devs actually try to discuss an issue it ends up with 1 hour locked in a room with the expectation some winner will emerge.
But that doesn't mean that a meeting about the context of some customer problem is a dud. It's a large part of the reason that product team exists. I rarely got those meetings.
More of them, less of the pointless ones please. :)
step one is don't have 50 minute meetings. if your meeting was 20 minutes, you'd probably finish it in 30 and have had a much more productive meeting.
I absolutely agree that meetings should not be any longer than necessary. Declining any meeting that doesn't have a defined agenda and goal should be acceptable too.
> Meetings force us to context switch, kill our flow, and sap our job satisfaction long term.
That's what programmers say. Developing software is much more than programming, at least when you are developing something else than an information system.
That's what programmers say. Developing software is much more than programming, at least when you are developing something else than an information system.
I end up answering lots of random questions for my coworkers (knowledge transfer-type stuff that hasn't been documented because the company was small before 2020) and having a block of meetings sucks because then I may not get to reply to a question for a while.
And I can say from the other side, I hate waiting 1 or 2 hours for my managers or non-manager Schelling point people to get out of meetings so I can ask them a 5-minute question.
And I can say from the other side, I hate waiting 1 or 2 hours for my managers or non-manager Schelling point people to get out of meetings so I can ask them a 5-minute question.
> reorganise them so they don't do that
This is good advice if you have the power to do that. But often people just don't have that control. Meeting times are set by managers/team leads/etc and you are required to be at them. If you decline because it will 'hurt your flow', this will not be well received by most managers.
This is good advice if you have the power to do that. But often people just don't have that control. Meeting times are set by managers/team leads/etc and you are required to be at them. If you decline because it will 'hurt your flow', this will not be well received by most managers.
Yeah I'd agree with this. Some meetings are for sure necessary. I think the problems start arising when a team gets too big or has too many responsibilities, then suddenly the discussions have to be much bigger and as such must become kind of long and tedious.
That's why you have weekly or monthly updates, depending on the org.
One of the biggest issues is devs not giving feedback enough, a lot of it is based on personality. There's no point in having a meeting and forcing people to give feedback though.
One of the biggest issues is devs not giving feedback enough, a lot of it is based on personality. There's no point in having a meeting and forcing people to give feedback though.
>not having opportunities to be seen as an expert
Co-ordinated effort is much more valuable than raw engineer effort aimed scatter-gun at a project. There's so much more to meetings than the author covers in this. For example, in a meeting you're made aware that engineer X is working on Y, you have prior experience in Y. Immediate win. Does this happen 100% of the time? Of course not, but there's a probability it will. Hell it doesn't have to be experience, it could just be an interestin insight - what are we paying you guys for anyway.
Communication often is the most valuable thing you can foster as a manager, and this article just seems naive. Sure, there are bad meetings. But we don't measure the thousands of hours of wasted engienering hours that could've been saved by having 1 decent meeting.
Communication often is the most valuable thing you can foster as a manager, and this article just seems naive. Sure, there are bad meetings. But we don't measure the thousands of hours of wasted engienering hours that could've been saved by having 1 decent meeting.
Hi, author here -- kind of weird to see my post on hn. Yea, a good meeting can absolutely be worth all the developer time it costs!
I tried to carefully qualify all my calculations in terms of 'opportunity cost' and 'pointless meetings', but clearly it didn't work :).
The main idea behind the post is that the expected utility of a meeting with n developer, E[u(x_n)], should be greater than or equal to the opportunity cost of having that many developers in the meeting. Furthermore, through batching and async context transfer we can reduce the opportunity cost of having those developers in that meeting, which is pure upside for the business.
In a previous job I frequently got invited to meetings that were planned because the expected utility is > 0, which is imo really bad business.
I tried to carefully qualify all my calculations in terms of 'opportunity cost' and 'pointless meetings', but clearly it didn't work :).
The main idea behind the post is that the expected utility of a meeting with n developer, E[u(x_n)], should be greater than or equal to the opportunity cost of having that many developers in the meeting. Furthermore, through batching and async context transfer we can reduce the opportunity cost of having those developers in that meeting, which is pure upside for the business.
In a previous job I frequently got invited to meetings that were planned because the expected utility is > 0, which is imo really bad business.
>The main idea behind the post is that the expected utility of a meeting with n developer, E[u(x_n)], should be greater than or equal to the opportunity cost of having that many developers in the meeting
That is well and good in theory, but also insanely hard to measure. We know that building the right thing is more important to any company than building the thing right. Even if you could approximate how much work a dev does in the alloted time (whih is not a constant), the impact of a meeting might not be immediate. Modelling this lag across all developers and projects is not trivial and might even lead to trying to fit a model that will not be stable.
That is well and good in theory, but also insanely hard to measure. We know that building the right thing is more important to any company than building the thing right. Even if you could approximate how much work a dev does in the alloted time (whih is not a constant), the impact of a meeting might not be immediate. Modelling this lag across all developers and projects is not trivial and might even lead to trying to fit a model that will not be stable.
I think the reason I'm so critical of this is that you can do the same thing in other contexts and it often works out badly because very often the things that are easiest to measure are the least useful.
Consider this - communication on its own is worthless if no time is left to do productive work. If communication was so important then slack/hipchat/etc shitposters would be your most productive employees and they usually aint
I had a manager who measured how much time everyone spent using slack and actually boasted that he was the person most active on slack as if that was some measure of productivity.
And I guarantee you that 90% of his posts on slack were cat gifs and the like. Most of the other 270% of his messages were automated notifications for build, deployment, and test failures that everybody ignored.
And I guarantee you that 90% of his posts on slack were cat gifs and the like. Most of the other 270% of his messages were automated notifications for build, deployment, and test failures that everybody ignored.
> For example, in a meeting you're made aware that engineer X is working on Y, you have prior experience in Y. Immediate win. Does this happen 100% of the time? Of course not, but there's a probability it will.
How high does that probability have to be before it is a net gain?
Look at a realistic and common case: eight devs in a 30m standup.
That's four hours used up. Maybe once or twice a month one of those devs gets something out of the standup that they would not have gotten otherwise.
You're spending 80 hours of dev time per month for a payoff (at most) twice a month.
Is it worth it?
How high does that probability have to be before it is a net gain?
Look at a realistic and common case: eight devs in a 30m standup.
That's four hours used up. Maybe once or twice a month one of those devs gets something out of the standup that they would not have gotten otherwise.
You're spending 80 hours of dev time per month for a payoff (at most) twice a month.
Is it worth it?
OT related to standups, we now use https://www.dailybot.com/ and it has cut down on our meeting time across teams to quite an extent. The bot gives us daily checkins which records what we worked on the previous day, what we plan to work on today, what blockers we have. This has enabled us to identify blockers across teams and fix them as well as being productive and checking in whenever we feel like it. By EOD, everyone would have filled up the form/bot.
I'm not affiliated to the product.
I'm not affiliated to the product.
Not to take away from your point, but a standup with eight devs really shouldn't take 30 minutes.
> Not to take away from your point, but a standup with eight devs really shouldn't take 30 minutes.
I have never heard of a standup taking less than around 3m-4m per person. I'm sure it happens, I have just never heard of it happening.
My experience (and the experience of almost every developer I've ever interacted with) is around the 3m-4m per person mark.
I have never heard of a standup taking less than around 3m-4m per person. I'm sure it happens, I have just never heard of it happening.
My experience (and the experience of almost every developer I've ever interacted with) is around the 3m-4m per person mark.
Wow, that’s really unfortunate. At my current company, standup is around 20 seconds per employee. Literally, the PM pulls up the JIRA board sorted by employee, and each person says “I’m currently working on ticket X, it’s [going well/I’m having trouble with Y/etc.]” and then you move on. If someone’s stuck on something they’ll take a minute or two to explain it and someone else can jump in to help. The PM often has a couple minutes of questions at the end that are requests coming from other teams.
For a team of 6 people, we schedule 15 minutes and it usually ends in under 10.
For a team of 6 people, we schedule 15 minutes and it usually ends in under 10.
3-4 minutes per person is huge! What does an IC talk about for all that time? Thirty seconds per person is closer to the mark in my experience, and that’s as part of encouraging slightly longer stand ups as a fully remote team. The actual standup might usually be fifteen minutes or so overall as there’s often a couple of issues worth coordinating on.
Are your stand ups a way of identifying ways to move forward quickly, or just people feeling they need to justify their existence?
Are your stand ups a way of identifying ways to move forward quickly, or just people feeling they need to justify their existence?
Good luck finding places that practice standups for software developers and where it isn't completely broken so that 30 minutes is an underestimate, whatever the number of people on the team.
Those places certainly do exist, just as lottery winners exist too. You just won't find them.
Those places certainly do exist, just as lottery winners exist too. You just won't find them.
Most of these communication can be asynchronous. If I look at task board, I know who is working on what. I don't need a meeting for that. If I need help with something, I can ask it in Slack and people can respond. Don't need to drag the entire team for the meeting.
The only devs who need to be in a lot of meetings are architects who design the technical solution based in businesses requirements. All other devs need minimal meetings to get their work done.
The only devs who need to be in a lot of meetings are architects who design the technical solution based in businesses requirements. All other devs need minimal meetings to get their work done.
This works well when people:
* assign themselves to tasks
* keep status correct, eg move to correct column, resolve etc
* updates tasks with comments every now and then
So many times this is not the case, especially not all above at same time. Sadly.
A short question and answer in chat better than a 60 minutes meeting though!
So many times this is not the case, especially not all above at same time. Sadly.
A short question and answer in chat better than a 60 minutes meeting though!
The worst part is the non-linear growth in productivity of uninterrupted blocks of work. Not always, but very often a 4h block is much more valuable than 2 blocks of 2h with a meeting in between. This is not even about "flow", it's about getting your work environment sorted out, getting all the tools ready, doing a couple of experiments, actually thinking about the context of your solution, etc.
It's a very costly fallacy that developer productivity is simply linearly dependent on time spent on an issue.
In consequence, I strongly believe that there should be a minimum latency in software development that cannot be cut further. Say, it's two days. That would mean you should not attempt to have any meetings from Wednesday onwards and be able to deploy on Thursday evenings and collect and discuss results on Fridays. Monday's for retros, especially regarding Friday's findings and Tuesday is the day for planning. That's a very, very compact schedule and I doubt it's sustainable, to be honest. But it's already longer, and has stricter constraints, than most managers would accept, I bet.
It's a very costly fallacy that developer productivity is simply linearly dependent on time spent on an issue.
In consequence, I strongly believe that there should be a minimum latency in software development that cannot be cut further. Say, it's two days. That would mean you should not attempt to have any meetings from Wednesday onwards and be able to deploy on Thursday evenings and collect and discuss results on Fridays. Monday's for retros, especially regarding Friday's findings and Tuesday is the day for planning. That's a very, very compact schedule and I doubt it's sustainable, to be honest. But it's already longer, and has stricter constraints, than most managers would accept, I bet.
Yeah, this has been my problem since being in a role where I am more responsible for the work of others and reporting to upper management.
Theoretically I still have 50% of them for individual work I had before, but that's fragmented and prone to interruptions because some exec wants to know how the XYZ project is going in between weekly status updates, or some junior developer needs help understanding why the Foo system does what it does the way it does
Theoretically I still have 50% of them for individual work I had before, but that's fragmented and prone to interruptions because some exec wants to know how the XYZ project is going in between weekly status updates, or some junior developer needs help understanding why the Foo system does what it does the way it does
Which is frustrating since more and more senior level now are required to manage juniors while also having works yourself. In previous company I attended meeting more than I develop.
Thankfully my current company treat developers as developers.
Thankfully my current company treat developers as developers.
No meeting days are the way. I advocated for a no meeting day in one of my workplaces and our director agreed to try it out. We called them "Developer Days" and he'd block off the entire day on everyone's calendar and enforce to anyone outside the team we simply were not available those days. Worked so well we ended up adding a second Developer Day!
And meetings become more productive too since we batched those up into the other days and could focus on the meeting instead of context switching between talking with people and talking with a computer.
And meetings become more productive too since we batched those up into the other days and could focus on the meeting instead of context switching between talking with people and talking with a computer.
I've always seen that my job as a lead, among other things, is to act as a buffer in communication between my team and "the business". One big thing is my devs not having to attend most of the meetings - I go there for them, and then on the next daily I pass the relevant information. If we need to make an estimates or architectural decisions, we do that in our internal meetings and then I let the business know what they need to know. Keeping meetings highly scoped is IMHO big win-win for both sides, because in reality devs don't really care about the business side that much, nor business cares about all the technical details (or even can understand them) so keeping them isolated and me (together with PM) just "translating" the information from business to dev lingo and back, is actually saving everyones' time, avoiding misunderstandings, and keeping meetings shorter and more focused.
I used to work for a Japanese corporation.
You think you have it bad?
Japanese corporations say “Hold my Asahi.”
I’m talking around-the-clock meetings. Our Shinagawa headquarters was this huge building, with two floors dedicated to meeting rooms, and those rooms were constantly full.
It has to do with the consensus-based methodology they use. It requires regular feedback between stakeholders.
If you miss a meeting, you could find your team booted from the project, so managers often grab any poor random schlub from the engineering floor, and direct them to attend a meeting, where they have no clue, whatsoever, about the topic. They are only there to “stake a claim.”
I often saw people fast asleep, in meetings.
I have a general policy that regularly-scheduled meetings should always be avoided, but that never seems to happen, IRL.
You think you have it bad?
Japanese corporations say “Hold my Asahi.”
I’m talking around-the-clock meetings. Our Shinagawa headquarters was this huge building, with two floors dedicated to meeting rooms, and those rooms were constantly full.
It has to do with the consensus-based methodology they use. It requires regular feedback between stakeholders.
If you miss a meeting, you could find your team booted from the project, so managers often grab any poor random schlub from the engineering floor, and direct them to attend a meeting, where they have no clue, whatsoever, about the topic. They are only there to “stake a claim.”
I often saw people fast asleep, in meetings.
I have a general policy that regularly-scheduled meetings should always be avoided, but that never seems to happen, IRL.
When I was a developer, I hated meetings, and just wanted to work on my feature as much as I could. Tell me what you need to have built, and let me build it.
When I switched to product design, I tried to respect the engineers' time by not scheduling synchronous meetings very often.
I would write documents that nobody read (or at least did not comment on) and record video demos that I know for a fact only about 25% of people watched. What I said to them was: "here are the designs, and here's why I did it this way, and if that makes sense to you go for it, otherwise let's meet to answer questions".
A couple engineers would reach out to me, most would never say a word.
At retro, the feedback I got was "design is not communicating, we want to be involved earlier in the process". Okay, great! Maybe I went too far in trying to free up their time. So, I continued documenting my work, but also scheduled a 30 minute recurring meeting once per week, to synchronously update the engineers on where the design was headed: here's what we heard from customers, here's what I'm thinking we need, are there any constraints I should be aware of, and do you have any ideas on how we could approach this differently?
Keep in mind that I'm still doing IC work on the design itself, and I'm putting in a lot of time documenting things for the engineers, and I'm attending way more meetings than them (this is the nature of design).
I thought these design syncs were going great, but the feedback at a later retro was "gah! too many meetings, we don't need a recurring meeting with design every week".
Since documenting things and scheduling meetings on an ad hoc basis was not enough communication, and 30 minutes a week was too much of a burden, and most of the team would not voluntarily engage in asynchronous communication anyway, I was sort of at a loss about how to make them happy.
My conclusion was that every engineer is different, and there is no magic bullet that results in perfect communication but does not "break flow". And since they are being paid for their time, I'm not going to try to tiptoe around scheduling meetings when I need to, to do my part of the job.
When I switched to product design, I tried to respect the engineers' time by not scheduling synchronous meetings very often.
I would write documents that nobody read (or at least did not comment on) and record video demos that I know for a fact only about 25% of people watched. What I said to them was: "here are the designs, and here's why I did it this way, and if that makes sense to you go for it, otherwise let's meet to answer questions".
A couple engineers would reach out to me, most would never say a word.
At retro, the feedback I got was "design is not communicating, we want to be involved earlier in the process". Okay, great! Maybe I went too far in trying to free up their time. So, I continued documenting my work, but also scheduled a 30 minute recurring meeting once per week, to synchronously update the engineers on where the design was headed: here's what we heard from customers, here's what I'm thinking we need, are there any constraints I should be aware of, and do you have any ideas on how we could approach this differently?
Keep in mind that I'm still doing IC work on the design itself, and I'm putting in a lot of time documenting things for the engineers, and I'm attending way more meetings than them (this is the nature of design).
I thought these design syncs were going great, but the feedback at a later retro was "gah! too many meetings, we don't need a recurring meeting with design every week".
Since documenting things and scheduling meetings on an ad hoc basis was not enough communication, and 30 minutes a week was too much of a burden, and most of the team would not voluntarily engage in asynchronous communication anyway, I was sort of at a loss about how to make them happy.
My conclusion was that every engineer is different, and there is no magic bullet that results in perfect communication but does not "break flow". And since they are being paid for their time, I'm not going to try to tiptoe around scheduling meetings when I need to, to do my part of the job.
I'm like you; tell me what you need and I'll just do it. If I get a work-item that is decently written or at minimum has design mocks, I can immediately get to work and basically never have to communicate backwards with anyone. Like you said though, everyone is different. I work alongside many devs that need hand-holding through the entire process. That's totally fine, but what I ask is don't make my attendance to meetings mandatory. Don't force me to partake in the ceremonial BS. I get nothing out of it. If you make the attendees optional, then they can choose whether or not they need that meeting. I know - with strong confidence - that I don't need the meetings.
Yeah it’s really hard. I tend to want developers to be product engineers and really care about not just coding but solving problems for end users.
Reality gives us a bunch of people with different goals and different ways to make them happy, as you say. A lot of developers just want to get on and code without looking at the wider picture too hard - as long as they know their work is valued.
“Being involved earlier in the process” has tended to mean “knowing what kind of feature you might be working on and how sets of tickets are related” for a lot of engineers in my experience.
Reality gives us a bunch of people with different goals and different ways to make them happy, as you say. A lot of developers just want to get on and code without looking at the wider picture too hard - as long as they know their work is valued.
“Being involved earlier in the process” has tended to mean “knowing what kind of feature you might be working on and how sets of tickets are related” for a lot of engineers in my experience.
> The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle.
That's not what the Pareto principle says, is it? Am I missing something?
That's not what the Pareto principle says, is it? Am I missing something?
It’s generally held that Pareto applies to a lot of things you wouldn’t assume it does.
But in this case I think Sturgeon’s Law is better: 90% of everything is crap. This is a journeyman or lower understanding of development (how old is the author? Should they know better?). In fact I’ll assert that he has it exactly backward, and that 80% of code you write only provides 20% of your value.
Only code monkeys provide 80% of their value from flow state. And Code Monkeys always feel underpaid because they think writing code is their entire value., and which is a slippery slope to thinking more code is better.
But in this case I think Sturgeon’s Law is better: 90% of everything is crap. This is a journeyman or lower understanding of development (how old is the author? Should they know better?). In fact I’ll assert that he has it exactly backward, and that 80% of code you write only provides 20% of your value.
Only code monkeys provide 80% of their value from flow state. And Code Monkeys always feel underpaid because they think writing code is their entire value., and which is a slippery slope to thinking more code is better.
Not at all, the application of Pareto here would be something like "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state.
Edit: rereading, those are actually the same thing, though the quote is confusing because it refers to a different 20% than Pareto refers to.
Edit: rereading, those are actually the same thing, though the quote is confusing because it refers to a different 20% than Pareto refers to.
> "80% of a developer's value is contributed in 20% of their time", that 20% being the time spent in the flow state.
Hum, no. One does absolutely not follow from the other.
If the Pareto principle actually applies, it would say that 80% of the development value comes from 20% of the time the developer spends in flow. And the rest 80% of the flow time adds only to 20% of the value. The same would come from the value from meetings and the time spent on them.
But do keep in mind that, about the Pareto principle: you can never predict the value of anything - those are only post-fact measurements; and those proportions vary widely, it's never actually 80-20.
Hum, no. One does absolutely not follow from the other.
If the Pareto principle actually applies, it would say that 80% of the development value comes from 20% of the time the developer spends in flow. And the rest 80% of the flow time adds only to 20% of the value. The same would come from the value from meetings and the time spent on them.
But do keep in mind that, about the Pareto principle: you can never predict the value of anything - those are only post-fact measurements; and those proportions vary widely, it's never actually 80-20.
> I sat through a particularly useless meeting the other week with a meeting screen full of other devs – oddly, it was initiated by a tech lead on a different team.
This is a red flag. What type of org / culture would allow this to happen?
Fact: Wasteful pointless meetings don't only plague developers. They plague everyone, if not society itself.
- No agenda? Red flag.
- No clear takeaways / going forward expectations (i.e., "X with do ___. Y will do ___...")? Red flag.
- No decision / progress? Red flag.
- No minutes (read: something trusted that let's non-attendees catch up)? Red flag.
- Most are complicit & complacent with shite meetings? Red flag!
Consistently sloppy meetings are a nearly perfect proxy for:
1) lack of training (i.e., ultimately is a leadership issue)
2) lack of trust (i.e., the more need for CYA, the more ppl invited)
3) micromanaging (in the sense that managers don't allow their direct reports to show up and participate; instead the manager must be there).
--
Being a developer has nothing to do with this plague. Flow switching effects everyone. In fact, presenting it as a niche issue dilutes the argument for more productive meetings *for all*.
p.s. If I had $20 for every waste of my time meeting I'd have Bezo's money, perhaps even Musk money.
This is a red flag. What type of org / culture would allow this to happen?
Fact: Wasteful pointless meetings don't only plague developers. They plague everyone, if not society itself.
- No agenda? Red flag.
- No clear takeaways / going forward expectations (i.e., "X with do ___. Y will do ___...")? Red flag.
- No decision / progress? Red flag.
- No minutes (read: something trusted that let's non-attendees catch up)? Red flag.
- Most are complicit & complacent with shite meetings? Red flag!
Consistently sloppy meetings are a nearly perfect proxy for:
1) lack of training (i.e., ultimately is a leadership issue)
2) lack of trust (i.e., the more need for CYA, the more ppl invited)
3) micromanaging (in the sense that managers don't allow their direct reports to show up and participate; instead the manager must be there).
--
Being a developer has nothing to do with this plague. Flow switching effects everyone. In fact, presenting it as a niche issue dilutes the argument for more productive meetings *for all*.
p.s. If I had $20 for every waste of my time meeting I'd have Bezo's money, perhaps even Musk money.
Sort of an obvious point, but the opportunity cost analysis here has basically nothing to do with whether the meeting attendees are developers - it applies to anyone who has other things they could be doing with their time and has a cost from context switching.
On a separate point, missing from this is the potential opportunity cost arising from NOT having a meeting. It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs.
(That’s not often the case, mind you, but it does happen.)
Anyway, “High Output Management” by Andy Grove does a great job articulating the math of meetings and how to maximize their value.
On a separate point, missing from this is the potential opportunity cost arising from NOT having a meeting. It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs.
(That’s not often the case, mind you, but it does happen.)
Anyway, “High Output Management” by Andy Grove does a great job articulating the math of meetings and how to maximize their value.
Adding High Output Management to my to-read list, thanks!
> It’s a harsh reality, but sometimes the reason you’re sitting in that “pointless” meeting is that there’s a small chance you’ll need to be called upon, and if you aren’t present there is a person or people whose time is even MORE expensive than yours who will suffer a cost that more than offsets the cost of 2 or 5 or 10 developers sitting there twiddling their thumbs.
Why are we in this horrific situation where a person's knowledge can only be leveraged if they are "called on" in 30 seconds of an hour-long meeting?
My God, Slack me if you must.
Why are we in this horrific situation where a person's knowledge can only be leveraged if they are "called on" in 30 seconds of an hour-long meeting?
My God, Slack me if you must.
Some work is inherently synchronous. On those, if you are needed for 30 seconds but it takes 30 minutes for you to get there, the people doing it will have to stop until you come.
All work is not this way (even though some managers pretend it is), and very likely the majority of your work isn't like it (assuming you are a software developer). But some work is like it, and pretending it isn't as about as expensive as gathering people doing asynchronous work into meetings.
(The "what should we do" decisions normally require more synchronous work than "how should we do it", some professions do spend most of their time in the former.)
All work is not this way (even though some managers pretend it is), and very likely the majority of your work isn't like it (assuming you are a software developer). But some work is like it, and pretending it isn't as about as expensive as gathering people doing asynchronous work into meetings.
(The "what should we do" decisions normally require more synchronous work than "how should we do it", some professions do spend most of their time in the former.)
Or people could be slightly more imaginative and flexible. I could be "on call" while a meeting is going on without having to attend if 99% of it doesn't concern me.
Obviously some work is synchronous, but it's not an excuse for the norm today, where time wasting is the default.
Most managers are lazy and bad at their jobs, and there is no accountability for that. So they prefer to waste lots and lots of other people's time in exchange for slightly more convenience for themselves.
Obviously some work is synchronous, but it's not an excuse for the norm today, where time wasting is the default.
Most managers are lazy and bad at their jobs, and there is no accountability for that. So they prefer to waste lots and lots of other people's time in exchange for slightly more convenience for themselves.
What you say about most managers is true.
And yet, still the situation I described can arise for perfectly valid and rational reasons. Like if the context required for your 30 seconds of input is difficult to convey quickly - if you’re available on Slack but it takes you 15 minutes to get through all the questions everyone else has already addressed in your absence, then as long as there are 3 people you’re keeping waiting whose time is equal or greater in value to yours it isn’t at all inefficient for you to have been sitting there doing nothing but listening for an hour to get to that point.
Plus, the simple act of receiving information in a meeting is often valuable in itself, even if you as (one) recipient (of possibly many) don’t immediately perceive that value. Again I’ll plug High Output Management, which explains why far better than I can.
And yet, still the situation I described can arise for perfectly valid and rational reasons. Like if the context required for your 30 seconds of input is difficult to convey quickly - if you’re available on Slack but it takes you 15 minutes to get through all the questions everyone else has already addressed in your absence, then as long as there are 3 people you’re keeping waiting whose time is equal or greater in value to yours it isn’t at all inefficient for you to have been sitting there doing nothing but listening for an hour to get to that point.
Plus, the simple act of receiving information in a meeting is often valuable in itself, even if you as (one) recipient (of possibly many) don’t immediately perceive that value. Again I’ll plug High Output Management, which explains why far better than I can.
I agree with all that, but still object to a thoughtless blanket norm of meeting attendance imposed by lazy managers rather than thoughtful consideration of the situation.
I'm delighted someone is putting a cost to pointless meetings like those described (well, pointless from a devs perspective).
I worked in a utility company, where morale was in the basement, and management organized a full day (on-site) off-site meeting.
60 to 70 devs in a big room, whiteboards everywhere. Some corporate events enabler stands up and says everyone is to write on their whiteboard what the word "team" means to them, then discuss it.
I did the math, and after a couple of hours each group had to discuss what they found. I said it's just cost us 15k for this chitchat and at the end of it we'll be none the wiser and no actions will be taken.
Was called in to the bosses office the next day and chewed out for not being a team player. Week after that the boss was fired. shrugs
I worked in a utility company, where morale was in the basement, and management organized a full day (on-site) off-site meeting.
60 to 70 devs in a big room, whiteboards everywhere. Some corporate events enabler stands up and says everyone is to write on their whiteboard what the word "team" means to them, then discuss it.
I did the math, and after a couple of hours each group had to discuss what they found. I said it's just cost us 15k for this chitchat and at the end of it we'll be none the wiser and no actions will be taken.
Was called in to the bosses office the next day and chewed out for not being a team player. Week after that the boss was fired. shrugs
i've always thought it would be interesting to create a quarterly token system for meetings where meetings cost tokens depending on number of attendees (where ics are "expensive") and the ideal effect is that some level of consensus needs to be reached prior to calling the meeting in order to pool the tokens needed to pay for it.
the reason why there are too many meetings is because they are free.
the reason why there are too many meetings is because they are free.
I've heard of something like this being used to buy priority for a dev team to work, but expanding a similar system to scheduling meetings would be interesting. the biggest problem would probably be "meetings" become informal things to get around the rules rather than improve practices.
Ah ha! I like it. Mangers with a restricted budget for meetings. The more people they invite, the more rapidly their quota burns.
The inverse function: "what level of aggregated pay makes a meeting more than an MBP" is needed because MBP price and renumeration vary by economy and time.
I for one would welcome this service so I can ironically distain meetings on sound financial bases.
I for one would welcome this service so I can ironically distain meetings on sound financial bases.
I find meetings are often covering a deficit in the planning and documentation of the project and technology environment/project plan anyway. A great deal of the time, the information should have been documented somewhere already, and it would be much more valuable to the team long term if they just found the information, documented it properly, then circulated the document in an asynchronous way so that people can take their time to properly consider it and respond if needed and when they have time.
Do developers really spend that much of their time in meetings? When I have worked closely with dev teams, it seems like there are a few regular short coordination meetings that are over quickly. Then there are occasionally more substantial meetings where they are working out architectural questions.
As a program manager, I usually have 4-5 meetings a day because that kind of is my job to review and coordinate. Developers are only rarely in those meetings.
As a program manager, I usually have 4-5 meetings a day because that kind of is my job to review and coordinate. Developers are only rarely in those meetings.
Depends on the team.
Also, a single meeting is extremely expensive for a developer's productivity. I generally think the developer productivity cost is about twice the amount of time it actually takes. And it's even worse when they're staggered throughout the day. Two one hour meetings is more like requesting 4 hours (or more, depending on what time of the day they take place in).
Managers not realizing this is one of the major failings of modern day software development.
Also, a single meeting is extremely expensive for a developer's productivity. I generally think the developer productivity cost is about twice the amount of time it actually takes. And it's even worse when they're staggered throughout the day. Two one hour meetings is more like requesting 4 hours (or more, depending on what time of the day they take place in).
Managers not realizing this is one of the major failings of modern day software development.
When I was a lead before retiring last year, I went to all the meetings instead of my team, but always kept them in the loop via Slack as to what was important during the meeting. I also wrote as much code as they did so was always understanding how the meeting decisions might relate to our codebase and future efforts. Of course it added a lot of extra hours to my workweek doing both, but I never had much issue over my career multitasking.
It's not easy or fun sitting in too many meetings though as I always asked a lot of questions to ensure product/design/execs could adequately explain what they were asking for; asking enough questions like this made sure we didn't waste too much time doing things that were likely to change. Meetings can be useful if you participation helps the workload; but it can drag down you and your team's productivity if it does nothing but waste time. Often people whose entire life is going to meetings don't understand how they can affect success simply by sucking up huge hours every day.
It's not easy or fun sitting in too many meetings though as I always asked a lot of questions to ensure product/design/execs could adequately explain what they were asking for; asking enough questions like this made sure we didn't waste too much time doing things that were likely to change. Meetings can be useful if you participation helps the workload; but it can drag down you and your team's productivity if it does nothing but waste time. Often people whose entire life is going to meetings don't understand how they can affect success simply by sucking up huge hours every day.
It varies by org.
I’ve been on teams where the only recurring meeting was a 30min weekly.
On the other hand I’ve been on teams with 25+ devs on 6+ hours/week of recurring meetings together.. plus any ad-hocs, project or task specific meetings, etc. Some were 2 full hours long and could run over to 3 hours. Was insane.
On the other hand I’ve been on teams with 25+ devs on 6+ hours/week of recurring meetings together.. plus any ad-hocs, project or task specific meetings, etc. Some were 2 full hours long and could run over to 3 hours. Was insane.
Yes but the function isn't workinghours - meetinglength > timeneededforwork
The function is workinghours modulo meetingtimes > timeneededfordiscreteworkingblocks
A task that requires four hours of concentration cannot get done in a day with a five-minute mid-morning coordination meeting and a five-minute mid-afternoon admin huddle.
The function is workinghours modulo meetingtimes > timeneededfordiscreteworkingblocks
A task that requires four hours of concentration cannot get done in a day with a five-minute mid-morning coordination meeting and a five-minute mid-afternoon admin huddle.
> As a program manager
Imagine what teams are like when this role does not exist.
Imagine what teams are like when this role does not exist.
They tend to have trouble working well with other teams. Business owners constantly pestering them for updates and just one more change. Other groups refusing to engage.
Program Managers are a little like defensive backs within an organization.
Program Managers are a little like defensive backs within an organization.
Meeting means coming to the same place. But not all meetings are the same.
Here are some reasons for meeting:
1. Working together 2. Sharing information 3. Reaching a consensus 4. Social gathering
Most meetings do not qualify for any of these reasons. And if they do, you probably don’t call them meetings. They’re discussions, collaborations, announcements, or parties; and are usually self-organizing, asynchronous,optional attendance, and flexible scheduling.
But meetings usually have a purpose like:
5. Satisfy the ego of the person organizing the meeting 6. Make sure everyone is in attendance 7. Get the status of everyone’s work 8. Occupy time
You can see that none of these are valuable or meaningful and generally don’t benefit most of the meeting attendees. If there is any purpose or benefit to the group, it can be done asynchronously and individually.
Here are some reasons for meeting:
1. Working together 2. Sharing information 3. Reaching a consensus 4. Social gathering
Most meetings do not qualify for any of these reasons. And if they do, you probably don’t call them meetings. They’re discussions, collaborations, announcements, or parties; and are usually self-organizing, asynchronous,optional attendance, and flexible scheduling.
But meetings usually have a purpose like:
5. Satisfy the ego of the person organizing the meeting 6. Make sure everyone is in attendance 7. Get the status of everyone’s work 8. Occupy time
You can see that none of these are valuable or meaningful and generally don’t benefit most of the meeting attendees. If there is any purpose or benefit to the group, it can be done asynchronously and individually.
The business value-added per developer is 80% from flow state and 20% from non-flow state following the Pareto principle.
Can someone explain to me why this is true? It seems like the author just used the numbers 80 and 20 and concluded "the Pareto principle works here".
Can someone explain to me why this is true? It seems like the author just used the numbers 80 and 20 and concluded "the Pareto principle works here".
Hmm. I think the author got confused.
“A business case for fewer meetings.”
That’s better. I can help develop it if they want.
“A business case for fewer meetings.”
That’s better. I can help develop it if they want.
The developers are the only ones who actually know how to do the actual work needed to teach machines what businesses do, which is why we see all the bull shit happening. Execs and managers are neigh useless in the modern world because they can't fake it anymore. Cut the middle men out!
Good luck. I fear Pournelle’s iron law of bureaucracy will ever prevail. Sadly.
I've got about three meetings in me on an average day before my batteries are exhausted and I am effectively done for the day.
When agile-ish processes use up on of those lives every day, that leaves very little slack before recurring customer statusing, actual troubleshooting, or an honest-to-god productive planning meeting wipes the counter out.
I suspect you could waste a lot less time if meetings required agendas distributed beforehand and minutes distributed afterwards, but absolutely no one does that, or would read such material if it was produced.
When agile-ish processes use up on of those lives every day, that leaves very little slack before recurring customer statusing, actual troubleshooting, or an honest-to-god productive planning meeting wipes the counter out.
I suspect you could waste a lot less time if meetings required agendas distributed beforehand and minutes distributed afterwards, but absolutely no one does that, or would read such material if it was produced.
One of the main causes of too many meetings is number of priorities org has. Lots of Parallel initiatives are a big problem. This causes inefficient meetings, not all stakeholders come.
Doing things in parallel contributes to this problem a lot.
Daily standups, plus a meeting or two per week seems doable. But if you work on two or three things in parallel, and you need to multiply the number of meetings by two or three, suddenly it feels like you spend more time on meetings than being able to focus on your work.
Daily standups, plus a meeting or two per week seems doable. But if you work on two or three things in parallel, and you need to multiply the number of meetings by two or three, suddenly it feels like you spend more time on meetings than being able to focus on your work.
This is just the cost of a meeting. The opportunity cost is a different factor, it's the cost of not doing what the dev would otherwise be doing.
Given that your not hiring devs to make up hours lost to meetings, the opportunity cost is the cost of not shipping earlier or with more features.
The caveat is that this all assumes you know what to build, if you don't attend meetings.
Given that your not hiring devs to make up hours lost to meetings, the opportunity cost is the cost of not shipping earlier or with more features.
The caveat is that this all assumes you know what to build, if you don't attend meetings.
2 weeks PTO is average? That's nuts!
Shut your laptops and go outside!
Shut your laptops and go outside!
[deleted]
$200K comp and 2 weeks of PTO. I don’t know how people handle only having 2 weeks off per year. American working culture is bizarre.
I’m a “Software Engineer” in Boston at a large company. Base time off is 24 days flexible time off (sick and personal) plus 8 fixed holidays.
Lots of jobs are just shitty.
Lots of jobs are just shitty.
At Meta we get 21 PTO days + 2 choice days + 5 "Meta days" + 10 government holidays. That's a total of almost 7 weeks off...
Not sure if it's still the case but when I worked at Reddit we had "unlimited" PTO and I saw quite a few people taking over 6 weeks off per year.
If you want to see an extreme work culture maybe look at China or Japan, but as far as tech goes the US ain't bad these days.
Not sure if it's still the case but when I worked at Reddit we had "unlimited" PTO and I saw quite a few people taking over 6 weeks off per year.
If you want to see an extreme work culture maybe look at China or Japan, but as far as tech goes the US ain't bad these days.
I think most european countries have 4 weeks counted as weeks not days and american ones usually only count work days so 15 days is actually 3 weeks. At google I had 25 days in my last year = 5 weeks which is not too bad. Amazon is traditionally a shit show with only 2 weeks your first year and 3w thereafter
The UK has 28 days minimum, that includes "bank holidays" (USA: Public holidays?) which are days decided by the government as holidays for everyone - like Christmas. So it's more like 5.6 weeks total in the UK, and the UK aren't particularly generous - your final year in Google, an exceptional comapany, barely meets the statutory minimum in the UK.
That might be the difference, nobody (that I've met) in the US would count a public holiday in PTO time.
Google's not super exceptional in this matter (that's mostly their pay/on-site experience). I have 4 weeks (20 days) at the moment, and have for a few years, along with 8 paid holidays (28 days total). Next year I get a fifth week (33 days with holidays). I don't work at a FAANG/MANGA company, but just some random company in the Mid-West.
But I've also worked service jobs before with 0 paid days. Holidays were mandatory work days because everyone who did have decent jobs were off and wanted to eat at a restaurant. The talk about the bottom in the US being below elsewhere isn't a myth. The US doesn't like putting floors on matters this side of the 60s.
Google's not super exceptional in this matter (that's mostly their pay/on-site experience). I have 4 weeks (20 days) at the moment, and have for a few years, along with 8 paid holidays (28 days total). Next year I get a fifth week (33 days with holidays). I don't work at a FAANG/MANGA company, but just some random company in the Mid-West.
But I've also worked service jobs before with 0 paid days. Holidays were mandatory work days because everyone who did have decent jobs were off and wanted to eat at a restaurant. The talk about the bottom in the US being below elsewhere isn't a myth. The US doesn't like putting floors on matters this side of the 60s.
Google also had around 14 holidays so no it far exceeds uk min requirement. Most us companies dont count holidays in their pto numbers and most have around 10 holidays
Is it still common in the UK/EU to only grant "holiday pay" (i.e. you get paid a fraction of your normal salary) during PTO? In the U.S. it has always been standard practice to get paid your full salary on PTO and national holidays. Even if that is so, I still think I prefer the European system.
[deleted]
4 or 5 weeks, usually (although this might vary by country) counted in days where 5 days = 1 week for a full time worker.
And sick days aren't limited, you can't control how long you're going to be sick.
PTO is measured in addition to standard holidays, which is 8-11 days depending on the company. So 2 weeks of PTO would mean 3.5-4 weeks of time off total at most professional jobs.
I haven’t seen a job posting or working at a company with only 2 weeks of PTO since I was a junior, but they’re out there.
I haven’t seen a job posting or working at a company with only 2 weeks of PTO since I was a junior, but they’re out there.
The thing that frustrates me about people who insist on meetings is that they're lazy. We all know we can communicate asynchronously. We all know that giving people more time to come to conclusions and do research leads to better decisions. And we all know that waiting for everyone to have free time in their schedule in order to make a decision is actively wasteful of current time. But many people continue to use meetings as the only method of group communication.
People are creatures of habit. We need a formal change of culture within tech to stop using meetings by default to solve all our problems. We need a manifesto that says exactly when you should use a meeting, and when to use other methods. Take the guesswork out of it so it's second nature.
People are creatures of habit. We need a formal change of culture within tech to stop using meetings by default to solve all our problems. We need a manifesto that says exactly when you should use a meeting, and when to use other methods. Take the guesswork out of it so it's second nature.
Especially considering hybrid remote/office and flexible working hours are becoming common. Asynchronous communication is such an advancement in productivity, documentation and clarity. Since it's all written down by default, and everyone can contribute even if they were away that day or otherwise engaged by work.
I think software agencies are inherently better at this, since they don't have to estimate an opportunity cost, the opportunity cost is billable hours that developer is currently not doing because they are in a meeting. I find working at agencies a bit more simple, with a lot less of the Org BS, because their is a level of pragmatism you need to have in order to operate profitably. Even more true if your agency is mostly contractors, because your boss is probably watching money tick away inside their head during sprint planning.
I think software agencies are inherently better at this, since they don't have to estimate an opportunity cost, the opportunity cost is billable hours that developer is currently not doing because they are in a meeting. I find working at agencies a bit more simple, with a lot less of the Org BS, because their is a level of pragmatism you need to have in order to operate profitably. Even more true if your agency is mostly contractors, because your boss is probably watching money tick away inside their head during sprint planning.
Gitlab does this in their employee handbook. As a guideline they say if you go back and forth 3 times asynchronously, consider a meeting. I don't work there so I don't know how much people adhere to this in practice.
https://about.gitlab.com/handbook/communication/#video-calls
https://about.gitlab.com/company/culture/all-remote/asynchro...
https://about.gitlab.com/handbook/communication/#video-calls
https://about.gitlab.com/company/culture/all-remote/asynchro...
Although this my be specific to my org, meetings are an excuse for PMs and non tech to just "talk things out". No requirement comes in written form and no meetings are recorded in written form. This gives them a safe passage to modify the requirements as and when they see fit.
Apart from this, for meetings which are not recorded, they can/do always say that they didn't say something when they actually did and when caught red handed they get defensive and live in denial.
IMO, written communication helps people articulate it better and hold them accountable as well.
Apart from this, for meetings which are not recorded, they can/do always say that they didn't say something when they actually did and when caught red handed they get defensive and live in denial.
IMO, written communication helps people articulate it better and hold them accountable as well.
Formal meetings should only be used for either parties or emergencies, and parties are always emergencies, so they take precedence.
Ideally!
Ideally!
Check out the "Death By Meeting" by Patrick Lencioni for his take in a non-tech scenario.
I found meetings much more objectionable when I worked onsite. Working at home, meetings don't bother me as much because nobody expects me to have my camera on and we're expected to keep our mikes muted unless we have something to say. So I can just listen while doing other things, like squats, pushups, crunches, etc., because most meetings are (like onion2k said) organizational and their substance is generally condensed into an email I can skim at my convenience on the off-chance that I missed something.
That's what developers say, but I suspect that it's not actually true. Something that leads to a far worse reduction in job satisfaction is not knowing what's going on, being surprised with complex features that the product people have assumed will be simple, and not having opportunities to be seen as an expert. Those things generally require developers to be in meetings. If devs don't have those things they get grumpy and quit.
The problem with most meetings is organisational. If your day is fragmented by lots of one hour meetings with one hour gaps between them then you can't get much else done. That's the frustrating part - you have lots of meetings and lots of 'dead space' between them. If you change things so meetings are 50 minutes long, and only have ten minutes between them, and that 'defrags' all the 'dead space' to a single block where you can focus, then meetings suddenly stop being so much of a problem.
If you hate meetings because they require too much context switching away from code, and they stop you focusing, reorganise them so they don't do that. If your first reaction to this suggestion is "But I can't because I don't control when meetings are", then the problem isn't meetings, it's your colleagues not giving a shit about your working environment. That's a very bad sign.