6 ms·

In my work I have the opposite experience, that latency is favoured to throughput: People write messages and expect an immediate answer, for things that are not

In my work I have the opposite experience, that latency is favoured to throughput: People write messages and expect an immediate answer, for things that are not time-pressing. A lot of things are destroying both though: Starting several things at once, so you can't concentrate on either. We spend a lot of time planning sprints, when half of the work is not planned for but arises spontaneously. I think the problem is that nobody really thinks about what they need and how they can achieve it. If you need latency are you ready to give up throughput? If you need a high throughput, do you manage to shield the team from distractions?

marcosdumay 5y ago
As the article said: > How much does delay cost? Hum, nothing. Those people expect a quick answer just because they want it. If it had real costs, you wouldn't be complaining. > How likely are we to learn something that will change our approach? If you learned something useful about the thing you are working on from the interaction, you wouldn't be complaining. > How likely are external forces to change our approach? If the conversation changed the entire thing you were working on (aka: we are canceling your project, you are supposed to do some Y now), you wouldn't be complaining. If those messages didn't fail all the tests for when latency is important, you wouldn't be complaining about them. That validates the article, instead of detracting form it.