Most active commenters

    ←back to thread

    318 points alexzeitler | 13 comments | | HN request time: 1.477s | source | bottom
    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 #
    1. 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 #
    2. jimmydddd ◴[] No.42189504[source]
    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.
    replies(2): >>42189561 #>>42192402 #
    3. xedrac ◴[] No.42189561[source]
    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?
    replies(1): >>42189638 #
    4. mewpmewp2 ◴[] No.42189638{3}[source]
    How can you tell what is worth doing if you don't know how long it might take?
    replies(2): >>42189709 #>>42191949 #
    5. zelphirkalt ◴[] No.42189709{4}[source]
    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.

    replies(1): >>42189758 #
    6. mewpmewp2 ◴[] No.42189758{5}[source]
    What is the difference between a projection and an estimate?
    replies(2): >>42190035 #>>42193335 #
    7. Tostino ◴[] No.42190035{6}[source]
    Who is doing it IMO.
    8. 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 #
    9. tchalla ◴[] No.42191949{4}[source]
    You work backwards. You decide how much time you’re willing to spend to get the worth. Then, take steps towards it with checkpoints.
    10. veunes ◴[] No.42192396[source]
    The irony is that managers who demand certainty often undermine the very trust and collaboration they need to get reliable insights
    11. veunes ◴[] No.42192402[source]
    Managers are often caught in the middle
    12. zelphirkalt ◴[] No.42193335{6}[source]
    For more info see: https://www.youtube.com/watch?v=QVBlnCTu9Ms
    13. 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