4 ms·
I agree with 'bad_user' here, to some extent. That is enough to give a manager a pause, but not to immediately dismiss it as a bad idea. Most professionals wil
by ralmeida 9y ago
I agree with 'bad_user' here, to some extent. That is enough to give a manager a pause, but not to immediately dismiss it as a bad idea.
Most professionals will agree that it's unrealistic to believe that developer-typing-code-time has 100% efficiency. The time spent 'decompressing', which can sometimes manifest itself as spending time reading/doing unrelated stuff, does sometimes produce a solution faster than just banging away coding.
Management work is different from coding in that everything is hard and noisy to measure, so to some extent heuristics are relied upon, simply because it's the state of the art in this area.
So, even if half an hour meeting with 8 developers takes 4 developer-hours (which is a rather large number), it does not mean those hours are wasted. If one of those meetings a day stops someone spending one week chasing a dead-end known to others at least once in a while, on average the team moves faster, not slower.
BTW, I actually agree that 8 developers is too much, and that half an hour is too long for a daily. Just going off a tangent here.
- vidarh 9y agoThe point is not that it is actually bad. Even 8 developers for half an hour could be justified. The point is that it should give a manager sufficient pause to actually think through whether or not that cost is justified by what that meeting provides. Surprisingly few teams account for the cost of the way they spend their time, and one outcome is that it's very easy for time sinks like meetings to go unchallenged because people don't think about how the costs multiply with the number of people involved. It's "only 30 minutes". Costs which would require budget approval if it was scheduled as a project suddenly become ok because no single person spends much time on it per meeting and the time spent never gets recorded and reported on anywhere.