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?
You agreed with their timeline that is why you keep having these conversations.
Stand firm only your timeline and when they push back remind them that you are the engineer doing the work if the wait it done to their timeline then they should hire more people.
Brb, hiring more wifes so our baby takes less than nine months to come
Luckily software development is not pregnancy.
It’s a reference to The Mythical Man Month and (I believe) one of the parables told inside:
Yes, but not all time related problems are man power limited. Bottle necks come in many shapes and sizes
And manglement causes many of those.
Something that was difficult to capture in the post is the sheer level of sarcasm in my tone when I ‘agree’ to their timeline.
Me: Ok, it seems you have an answer to your question then (sarcastically).
Or
Me, sarcastically: Ok, it seems you have an answer to your question then.
Seems easy to me.
You may be correct but I’ve seen this work out before. You say you take x days, manager mentions " but that guy says he takes y days!!" in which makes you either slow in comparison or the other guy is a liar or makes stuff sloppy. Then you say " from my experience is x days" in which either the manager says you’re wrong or he goes to the other guy to do in y days, and when you look at the thing done in y days has a technical debt equivalent to the height of Niagara falls. And you know you will have to clean this later. At some point I walked away, sometimes managers just want a yes man, and I am straight up not that.
Mine was always this:
Manager: How long will this take?
Me: 14 days
Manager: So it will be done in 2 weeks?
Me: No, it will be done after I’ve had 14 days of time to work on it.
Manager: What’s the difference?
Me: Am I still going to have random support escalations and will we keep having random meetings in those 2 weeks?
Manager: Yes.
Me: All those interruptions are me NOT working on the task. So it will be done in 14 days plus all the interruptions.
Manager: But this is very important!
Me: Can you then ensure I’m left alone to focus on this?
Manager: No.
Me: …
Not to mention, 14 days is three weeks, not two. Unless they’re hiring someone to work your weekends for you.
My favorite place I worked, it was a 9-5 but really just get your work done and be in the office from 11 to 2 because that’s when all the clients call. We’d close our doors and turn off the phone one day a week just so we could get work done, because every week there’s at least one day we all spend manning phones and putting out fires all fucking day instead of doing the work we’re paid to do.
Nothing is more triggering to me than the question “how long will this take?”
It will take as long as it fucking takes, and you shouldn’t be reporting anything until it’s done. Measure progress by fully working, end-to-end features, not by a number of hours someone pulled out of their asses.
You need to allocate resources and prioritize tasks
If task A takes a day then it might be worth doing. But if it takes 2 weeks then maybe not
I used to hate this. I still hate it, but I used to hate it, too.
More seriously, something that has helped from my managers is getting a “product requirements doc” or PRD. Management and customer reps put together a requirements document that says what they need built. Then you can break it down into work units for yourself and estimate the size with milestones and deliverables. It helps a bunch, even if it’s extra overhead at the start.
I do this often. I make product roadmaps, define my epics, etc. but a lot of times, in my work as a SWE consultant, the requirements are a moving target.
Read Software Estimation by Steve McConnell and recommend it to your manager:
The person doing the work the one best suited to estimate it.
Also, start tracking estimated vs budgeted time in some searchable system.
Next time this comes up, look up how long it actually took to complete a similar task instead of thoughts and prayers.
If boss won’t track historical budget vs actual, track it yourself.
The person doing the work the one best suited to estimate it.
As a manager in found this to be partially false.
Most persons doing the work quote forget that shit happens. Except for the few reliable persons I supervised, I usually always asked the follow-up question: what “unforeseen crap” time did you include, and made sure to leave with 3 values: all goes well (which I kept to myself), usual estimate, what if bad shit happens. Then I’d just use the standard pert guesstimate for my official schedules, making sure to include normal dead time which employees often forget (e.g. 8 days work is really 2 full weeks when accounting for meetings).
Oh yeah. It takes experience and clear head to remember to account for all the inevitables that are going to happen besides actual dev-hours-to-create-this. A hard lesson I am still learning
The way we estimate on my team is to break tasks down into related subtasks that will take one day or less, then add up all the subtasks. It’s worked pretty well.
That pattern is also recommended in the book. Break down estimates into chunks of 5 hours or less.
With lots of smaller tasks, estimates tend to both be more accurate due to smaller scope, and some of the over/under inaccuracies will cancel out.
That’s a really good budgeting idea. My worst boss wanted the estimate accurate to within fifteen minutes. He churns through employees like popcorn.
I usually tell them that I need to do it to in order to estimate how long it will take next time. next time it will already be done, here it is.
me: suggests anything extra not on the critical path but useful
lead: grumble dont bother automating it, just do a manual minimal local fix!!
later same issues appears
repeat local fix * 1000
The good PMs usually make Y=2X or 3X. But we’ll still have that “it’s day Y…” conversation /shrug.
