story
If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.
But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.
The only thing an intelligent software developer can do is play along, learn to read subtle cues as to what they want you to say, say that, and get on with the actually messy business of delivering working software.
And this is the real problem. People who know how to build & design products should be able to explain the goals of what they're asking for. If they don't then either you need to move or you need to get them moved.
One of the first things I tell new engineering managers is that an easy hack to is to always be asking yourself "what am I trying to accomplish?" Whether it's an emotional conversation or writing a document, if you can't answer that question then you probably shouldn't be moving forward with whatever you're about to do. And if you're writing a document, make the very first section "The goal of this document is..." because as you write you can constantly ask yourself "is what I'm writing accomplishing my stated goal?"
Communicating your goal also helps your team - if they know the goal then they don't act as automatons following directions, they can make actual decisions on their own.
If you know the business goal of what you're building then you have a better shot at getting the requirements and tasks correct, which gives you a better shot at giving a good estimate. I've worked with a number of product managers who had no real goal behind what they were asking for. I refuse to have the team start building things until someone can explain why we're doing it and what we're trying to achieve.
I definitely agree that the people asking don't actually know what the goals are. They usually have a very fuzzy picture there.
But I've always found the estimation and planning process to be hugely valuable for revealing the questions that reveal to THEM that they don't know all those requirements yet. And then we have a discussion about them, and we get better specs as a result, and then go on from there... which is way better than when we don't discover those gaps until we are writing the code for it!
Still it’s the only way that works.
They pay for someone who types code, but need someone who understands their business.. oh wait, isn’t that a consultant?
Consultants get a bad name because they usually don’t understand either the business or the tech. But they have good verbal skills
It’s probably easier to get a younger dev who’ll go into crunch mode bc they made estimates based on incomplete specs and lack of experience, but who feel the responsibility to deliver. They’re more easily pressured into working more, when the PM should step in and get more resources or do damage control for the mess they created.
