Manager: We (meaning you) need to do task A. How long will it take?
Me: Task A will take X days to do.
Manager: That seems awful long.
Me: How long do you think it should take?
Manager: It surely could not take any longer than Y days.
Me: Ok, it seems you have an answer to your question then.
Later:
Manager: It’s been Y days, why isn’t task A done yet?
Regardless of how effective it is at managing expectations, my reality is:
Mgt: We need A within Y days.
Stf: A will take X (>>Y) days, A/2 can be ready in Y days.
Mgt: O.K., give us A/2 in Y days.
Y/2 days elapses.
Mgt: In addition to A/2, please add B, C and D to the deliverable.
Stf: You realize, that’s going to take an extra 2X days to deliver.
Mgt: yes, but we absolutely need B. C and D, whatever it takes, as soon as possible, don’t waste time releasing A/2, bundle them all together for efficiency.
Stf: Coming up.
3X/2 days elapse.
Mgt: you know B, C, and D that we asked for? Actually, what we need are D, E and F.
Stf: well, we’ve finished A/2, B and half of C. When do you need D, E and F.
Mgt: ASAP, put C on the shelf.
X more days elapse.
Stf: here’s A/2, B and D, how do they look?
Mgt: You know, the full A would be better… but E and G are our absolute top priorities…
In programming, you ideally have a queue / FIFO of work tasks. Or, if things are more dynamic, a priority queue.
If interrupts are necessary, you get a stack of tasks. It is much slower because context switches eat time.
I had a job with a data structure I called a compost heap. One started with the thing on the top. While one was at it, another thing would be thrown on the top, and one had to start working on it. One never could really finish anything, and the things deeper down the heap started to rot. After a few years, the stack depth would be like 40 or 50 items. I made an appointment with my new manager to talk about prioritising things and the result was he put a new, urgent task on the stack.
They got angry when I handed in my notice.