3 ms·

Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to d

Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? I do not think I want to work with people like that. Things can not always be done instantly to fit the whims of developers. The customer may need to get together a few people and discuss what they want, which may take a few days to schedule. People may be doing other important things and not instantly free to drop everything to get you what you need. You may need to realise that you are not the center of the universe.

regularfry 3y ago
> Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? It depends on context, but I won't write it off. Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%. If you actually don't care about WIP, sure, pick up the work. > Things can not always be done instantly to fit the whims of developers. It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do. > I do not think I want to work with people like that. That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.

regularfry 3y ago

> Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do? It depends on context, but I won't write it off. Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%. If you actually don't care about WIP, sure, pick up the work. > Things can not always be done instantly to fit the whims of developers. It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do. > I do not think I want to work with people like that. That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.