The business case for fewer developers in meetings
blog.shimin.io
blog.shimin.io
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.
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.
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.
If the team is already working fine with async communication then it's just another empty ritual that can be safely dropped.
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.
There is an impedance mismatch between professional meeting attenders, and the people the build, and the meeting attenders are in charge.
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.
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.
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 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'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. :)
That's what programmers say. Developing software is much more than programming, at least when you are developing something else than an information system.
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.
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.
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.
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.
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.
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.
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.
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?
I'm not affiliated to the product.
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.
For a team of 6 people, we schedule 15 minutes and it usually ends in under 10.
Are your stand ups a way of identifying ways to move forward quickly, or just people feeling they need to justify their existence?
Those places certainly do exist, just as lottery winners exist too. You just won't find them.
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.
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!
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.
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
Thankfully my current company treat developers as developers.
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.
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 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.
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.
That's not what the Pareto principle says, is it? Am I missing something?
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.
Edit: rereading, those are actually the same thing, though the quote is confusing because it refers to a different 20% than Pareto refers to.
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.
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.
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.
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.
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.)
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.
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 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
the reason why there are too many meetings is because they are free.
I for one would welcome this service so I can ironically distain meetings on sound financial bases.
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.
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.
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.
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.
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.
Imagine what teams are like when this role does not exist.
Program Managers are a little like defensive backs within an organization.
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.
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".
“A business case for fewer meetings.”
That’s better. I can help develop it if they want.
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.
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.
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.
Shut your laptops and go outside!
Lots of jobs are just shitty.
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.
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.
Parental leave is usually not. Parental leaves start rather high (100% or 90%) and then go slowly down (to 60% or 50%)
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.
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.
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.
https://about.gitlab.com/handbook/communication/#video-calls
https://about.gitlab.com/company/culture/all-remote/asynchro...
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.
Ideally!