How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned.
At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.
When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details.
If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assuming those restrictions.
What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.
If for example, I say 3-7 days and he wants a single number because customer wants a date, he'll ask me "ok, so if I say to the customer they'll get the change in 10 days, we should be able to deliver?"
Then I say yes, under the assumption of X, Y and Z that sounds realistic to me.
Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.
We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
You write that you don't want to manage engineers?
But from what you write you cannot manage budgets and deadlines.
Managing budget and deadlines is not about setting some "ideal world" and then whipping these lazy engineers to deliver exactly that.
Managing budget and deadlines is about - well we delivered X/Y at that date it already was $yyy in terms of money. If it went well maybe you can increase work load, maybe look at things again and stop gold-plating to move further. If it went wrong cut the scope - check what went wrong, lower the risk of not delivering by simplifying tasks. Check if maybe you miss some specialistic knowledge to hire someone to help and account that risk against budget or tell customer that you need something specific that they have to deliver.
> If you can't deliver then maybe you're not a good enough for the job.
I've seen more than once projects with ill-equipped team members. I've been one myself, too.
Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation.
Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct.
PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.
They are asking because they have been asked themselves. To me it seems like a chain of incompetence from top to bottom, from bottom to top. Everyone is stretched beyond their abilities. The whole company is a house of cards. But yet it keeps on working and often it delivers results that keep everything else up and running. I don't understand why it works this way but it does.
The question is often 'how long does it take to implement'. Engineers know if it is more or less clear what the functional requirements.
In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc.
An experienced PM knows this and should not use implementation time as project duration.
> Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
> Many weak characters break that way. The trick is to make them choose their own deadline and fail.
I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit.
Clear communication is a very important managerial skill, by the way.
>The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.
Manipulative, psychopathic behavior, and you are a bad manager.
Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced.
Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.