[Etheryte]

The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.

[jimmydddd]

But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.

[xedrac]

And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?

[mewpmewp2]

How can you tell what is worth doing if you don't know how long it might take?

[zelphirkalt]

You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences.

You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.

[mewpmewp2]

What is the difference between a projection and an estimate?

[zelphirkalt]

For more info see: https://www.youtube.com/watch?v=QVBlnCTu9Ms

[Tostino]

Who is doing it IMO.

[tchalla]

You work backwards. You decide how much time you’re willing to spend to get the worth. Then, take steps towards it with checkpoints.

[veunes]

Managers are often caught in the middle

[trashtester]

Here is an approach for estimation that works pretty well (from the point of view of a manager).

1. Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic".

2. On top of that, add another x2 (which can be recalibrated as you learn how accurate this tech team is over time with estimates). Don't tell the developers about this, but make sure your higher-ups understand that this is what they need to be prepared for in terms of budgeting and time limits.

The reason you don't ask the developers to multiply by 4 directly, is to keep them motivated to aim for the x2, and avoid slacking or over engineering while feeling overly comfortable early on.

But by having the extra x2 in reserve, your back is covered, and you can afford to be cheritable with the dev team as they (as usually happens) go a bit over the x2 estimate.

This buys some early goodwill that can later be traded back in if you need them to up their game later on.

The alternative to the above is to exclusively find managers (at all levels) that can combine manager skills with high level engineering skills. Such managers often have the ability to expose unneccery delays directly, which includes the ability to tell apart delays caused by devs slacking from incompetence, scope creep or unexpected but valid causes.

Such people are really hard to find, though, for most companies. But companies that manage to build such high level top to bottom tech lead cultures may certainly be able to go from the 4x back down to 2x or even 1x compared to companies with non-technical managers.

[ignoramous]

> Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic". On top of that, add another x2 ...

Reminds me of: Always Multiply Your Estimates by π (2021), https://news.ycombinator.com/item?id=28667174

> ... scope creep ...

  If you want to know what Tesla does right and most of us do wrong, it's this: they ship something small, as fast as they can. Then they listen. Then they make a decision. Then they stick to it. And repeat.

  They don't make decisions any better than we do. That's key. It's not the quality of the decisions that matters. Well, I mean, all else being equal, higher quality decisions are better. But even if your decisions aren't optimal, sticking to them, unless you're completely wrong, usually works better than changing them.

An epic treatise on scheduling, bug tracking, and triage (2017), https://apenwarr.ca/log/20171213

[fastasucan]

>Ask the dev team to provide an optimistic estimate

Why? They are developers not project managers or staticians.

[veunes]

The irony is that managers who demand certainty often undermine the very trust and collaboration they need to get reliable insights