4 ms·

> "Can you tell me how long X, Y and Z will take?" > "We're almost finished with X, so only days left there. Y will take a few weeks, but I cannot estimate Z.

• jefc1111 4y ago
  Meh ... give people what they want. "I cannot estimate Z" is a refusal and I would suggest an ego-driven one. I would just say "between 1 and 12 months", or something like that. If they were then not happy with that I would go into why that is the best I can manage given the circumstances. "failure by the manager to take the point on board" is not relevant really when you think of the manager's perspective. From their perspective they have a contractor refusing to do what they are asked.
  • mojzu 4y ago
    I've not found vague estimates to work very well at all in this scenario. Managers will just continually ask for something more specific, they want a particular date they can remember/write down/enter into some project management software.
    • creshal 4y ago
      Usually I'll just go with "by date X we can give a reasonable estimate", which tends to work well enough with their mental model that they leave us alone until X.
      • jefc1111 4y ago
        Yeah that's a good pragmatic approach. "I can't estimate that right now but if I spend half a day on it I can give you a figure".
    • deleted 4y ago
      [deleted]
  • zen_1 4y ago
    > "I cannot estimate Z" is a refusal and I would suggest an ego-driven one. This might come down to a cultural difference or difference in communication styles. As an IC, I'd consider it to be much more honest on my part to be upfront about unknown timelines instead of providing a (quite frankly, useless) estimate just because it's what my manager wants to hear. At the end of the day, the work will take as long as it takes (managerial interference aside), and I believe in underpromising and overdelivering, precisely to avoid situations where someone's on the hook for an estimate that didn't pan out. If I wanted my business to be making accurate projections, I'd have been a quant.
• willcipriano 4y ago
  Think it will potentially be months? Write that. Write the longest amount of time you think it could be. "Six months! How could it take that long?" "It's a low quality estimate as I explained, personally I wouldn't rely on it for anything, it isn't any better than a guess. I don't have any data to base it off of."
  • smcl 4y ago
    The thing is, when I'm in this situation it's not that I cannot possibly ever estimate it. Taking the original example of three projects X, Y and Z (and a couple of others to add context) the issue with estimating Z can be a combination of: - I am in the middle of developing X right now - I am also handling some bug requests related to unmentioned, previously delivered projects A and B - I am in the planning stage for project Y, and working with client and analysts to pull some requirements together - I'm vaguely aware of how project Z roughly works, but there are a few big unknowns with the project that need to be cleared up which could be the difference between re-using much of project W or writing everything from scratch. I can give a vague t-shirt sized estimate, or I can maybe say "4-8 weeks" but that doesn't satisfy the request because I'm actually being asked for a number that gets plugged into a field that accepts discrete time durations not fuzzy English descriptions or ranges. And I won't have time to investigate the unknowns in Z until I've mostly delivered X, it's nearing production release and I've resolved the bug reports for A and B. That doesn't happen often, but when it does it can be hard to convince someone even if you're saying very directly "I will need to take time and effort away from priority tasks to analyse the project, eliminate some unknowns so that I can provide an estimate other than the vague 4-8 weeks". If you're suggesting "just give the upper estimate" then fine ... now you're going to be asked to break down exactly why you think it's as high as 8 weeks, "wait, why isn't it about the same as project W which we already completed...?" and you're back at explaining that you to dedicate time to the task before providing a breakdown. Basically - if someone demands an estimate when you're not ready for it, in some environments it can be quite stressful. I actually believe the author was correct in going above the manager to establish whether a very vague finger-in-the-air estimate was sufficient, rather than throwing out a known-inaccurate number.
    • 4y ago
• deleted 4y ago
  [deleted]
• mojzu 4y ago
  Often followed in my experience by some kind of complaint later on that "we were promised Z by this time why is the estimate bad". It's something I've struggled to find any good solution for too, particularly if you're looking at work that might take weeks or months because then you're often estimating based off an 'aspirational' and ever-changing specification
  • rocketbop 4y ago
    An estimate for something with a lot of unknowns can be a range. In this case OP could have said 4-16 weeks since his manager was pushing for an estimate, and moved on. Instead he made it a hill to die on.
• yardstick 4y ago
  The contractor was a senior engineer who had been working on and off with Spotify for years. Overall they've been in the field since 2009. That's quite a while. They must have some gut instinct on timelines by now. I've had my fair share of curve ball estimates over the years, if push came to shove I'd just give a ballpark estimate. Example: 3-6 months. If pushed for a specific time I'd go with the longer one - 6 months. If the manager wanted a shorter timeframe then just tell them what they want to hear. End of the day a bad estimate shouldn't get you in trouble with the company - if it does then that's not the sort of company I'd want to work with.
  • Aeolun 4y ago
    > End of the day a bad estimate shouldn't get you in trouble with the company I don’t know what companies you have worked for, but I’ve never worked for any where the ‘vague estimate that we are absolutely not going to hold you to’, is not seen as the word of god. It’s not that you get fired if you fail to live up to it, but the constant “why isn’t this done yet” gets fairly annoying really quickly.
    • gedy 4y ago
      Yeah flat out some companies insist on "estimates" from engineers to get them to commit to date and will hold them to it. The other fun one is "that's too long an estimate, let's break it down" then you are forced to try and design and analyze some vague feature in long meetings with project managers while you are busy with other work.
    • yardstick 4y ago
      Yes that can happen, I wouldn’t want to work somewhere like that either. “Why isn’t this done yet?” Answer: It was a ballpark estimate. Now we know more information we can revise the schedule. That’s all you can do as a non-manager. If the company culture makes your employment unenjoyable I would start looking for a better workplace, or find a coping mechanism to deal with the resulting poor management.
  • eptcyka 4y ago
    >If the manager wanted a shorter timeframe then just tell them what they want to hear. What's the point of giving an estimate in the first place then?
• donkeyd 4y ago
  Same. This ended causing me to quit my start-up. I was the tech lead and kept getting asked to estimate features that were completely new to us. I had a completely junior team due to budget constraints. After playing this game time and time again I threw in the towel.
• Aeolun 4y ago
  The correct answer from the manager’s perspective here is: Ok, how much exploration time do you need? Can you give me a reasonable estimate after an hour, a day, a week?
  • smcl 4y ago
    Right! It's not that the contractor was incapable of estimating it, but they needed to allocate some of their time to analysing the project. And given that there are many tasks a developer might have to complete, there'd have to be a priority call over whether analysis on Z was more important than development on X and Y. And when the contractor had the meeting where the product owner was present, it sounds like they implicitly understood this and were happy with the more general estimate.
  • Szpadel 4y ago
    In one project that i worked to we constantly got on planning what we can estimate and what not and if that's the second, we could mark something as dependent on some other task, or create "analysis" version of this task and estimate how much time we need to spend to be able to break down it do manageable chunks and investigate all the unknowns and then we planned it as any other task. we had some vague plannings, but those where in tshirt sizes or we just assigned numbers relative to other unknown tasks, so in long run management could roughly estimate project in months and manage risks
• DarkWiiPlayer 4y ago
  At that point I'd just point out how coming up with an estimate would first require putting in a lot of exploration and research, so it would take X amount of times and obviously delay other work in the meantime. Then ask again if, that being the case, the manager still wants their estimate. Now it's on them to do their job and evaluate priorities instead of sneakily offloading this to the developer.
• yosito 4y ago
  > "I need the time anyway. Provide it in a spreadsheet by end of day." I'd offer a time that's 4-5x as long as a reasonable ballpark. If they take that time, it gives you some slack. If they balk at it, you can explain that the estimate takes into account all of the unknown variables, and that if they'd like to shorten the time, they'll need to invest a little bit of time into discovery to get a breakdown of the timeline. Once managers start being faced with the real costs of their decisions, they start to be reasonable. But you have to do this in a calm and reasonable manner, not passive aggressively. If you do it just to get back at a manager, it will backfire on you.
• effingwewt 4y ago
  Hahaha this [1] video os the best thing ever that anyone who has done any contracting/consulting should see. You can only really get it if you've been in the room, but if you have you will not be disappointed! [1] https://youtube.com/watch?v=BKorP55Aqvg https://youtube.com/watch?v=BKorP55Aqvg