4 ms·

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 th

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.

dilyevsky 4y ago
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
- fijiaarone 4y ago
  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.
recurrence 4y ago
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.
- rgavuliak 4y ago
  >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.
- Traster 4y ago
  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.
wanderingmind 4y ago
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.
- tommymanstrom 4y ago
  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!
lelanthran 4y ago
> 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?
- planede 4y ago
  Not to take away from your point, but a standup with eight devs really shouldn't take 30 minutes.
  - lelanthran 4y ago
    > 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.
    - gbear605 4y ago
      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.
    - mjfisher 4y ago
      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?

dilyevsky 4y ago

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

fijiaarone 4y ago
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.

recurrence 4y ago

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.

rgavuliak 4y ago
>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.
Traster 4y ago
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.

wanderingmind 4y ago

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.

tommymanstrom 4y ago
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!

lelanthran 4y ago

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

planede 4y ago
Not to take away from your point, but a standup with eight devs really shouldn't take 30 minutes.
- lelanthran 4y ago
  > 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.
  - gbear605 4y ago
    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.
  - mjfisher 4y ago
    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?