Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
Usually I like to flip this question around and get a measure of importance and urgency before trying to discuss how long something might take, and even then I tend to favor not giving time estimates but instead focusing on prioritization.
Because in truth, for anything we're asked to do, there can be a 1000x difference in the total time cost (and more importantly, the time-to-ship) depending on scope, access to the supporting people + resources we need, budget, and "All the other work-in-progress / planning work."
There's a good two minute video about cost of delay that may be helpful in thinking about and communicating about these issues, may be worth checking out:
Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
Carving out slack time in the schedule is the most helpful tool in avoiding the feeling of being excessively rigid about prioritization.
This isn't intuitive so it's easy to get wrong, and what is particularly unintuitive is to what extend on-demand planning and analysis actually eats away at the available time to get stuff done.
(This is by contrast to prescheduled and explicitly accounted for planning time, which is a generally a good thing)
A while back I wrote an article on overproduction which aims to help make this issue more understandable... but when in a crunch, it's hard to change minds for sure.
Looking out on longer and longer time scales seems to help. It can be easier to free up slack with decisions that will kick in beyond the current overcommitted cycle than it is to convince people to take immediate action on the spot.
But it's indeed an infinite game, not something that can be solved once and then promptly forgotten about. 😀
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Absolutely.
Usually I like to flip this question around and get a measure of importance and urgency before trying to discuss how long something might take, and even then I tend to favor not giving time estimates but instead focusing on prioritization.
Because in truth, for anything we're asked to do, there can be a 1000x difference in the total time cost (and more importantly, the time-to-ship) depending on scope, access to the supporting people + resources we need, budget, and "All the other work-in-progress / planning work."
There's a good two minute video about cost of delay that may be helpful in thinking about and communicating about these issues, may be worth checking out:
vimeo.com/101506552
If you tell me more specific details about your situation, I may be able to offer some other ideas as well.
Carving out slack time in the schedule is the most helpful tool in avoiding the feeling of being excessively rigid about prioritization.
This isn't intuitive so it's easy to get wrong, and what is particularly unintuitive is to what extend on-demand planning and analysis actually eats away at the available time to get stuff done.
(This is by contrast to prescheduled and explicitly accounted for planning time, which is a generally a good thing)
A while back I wrote an article on overproduction which aims to help make this issue more understandable... but when in a crunch, it's hard to change minds for sure.
Looking out on longer and longer time scales seems to help. It can be easier to free up slack with decisions that will kick in beyond the current overcommitted cycle than it is to convince people to take immediate action on the spot.
But it's indeed an infinite game, not something that can be solved once and then promptly forgotten about. 😀