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.

>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.

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.

> 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?

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.

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.

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.

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?

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.

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.

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!