Re:The business case for fewer developers in meetings
by rgavuliak on Friday May 13, 2022 @03:45AM
(#31364540)
>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.
Re:The business case for fewer developers in meetings
by Traster on Friday May 13, 2022 @01:51PM
(#31370567)
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.
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.