←back to thread

317 points alexzeitler | 1 comments | | HN request time: 0.21s | source
Show context
redleggedfrog ◴[] No.42188611[source]
I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.

So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good.

Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes.

Also, just made meetings a lot more fun.

replies(14): >>42189183 #>>42189189 #>>42189248 #>>42189402 #>>42189452 #>>42189674 #>>42189718 #>>42189736 #>>42190599 #>>42190818 #>>42191841 #>>42194204 #>>42194310 #>>42200625 #
Etheryte ◴[] No.42189452[source]
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.
replies(3): >>42189504 #>>42191900 #>>42192396 #
trashtester ◴[] No.42191900[source]
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.

replies(1): >>42193888 #
1. ignoramous ◴[] No.42193888[source]
> 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