Hacker News Reader

Comment by smcl | Hacker News Reader

> "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. It's something we have never done before and without exploration time I don't even know the scope of the work."

> "I need the time anyway. Provide it in a spreadsheet by end of day."

I feel your pain man, that's one I've had a few times before. Just a complete failure by the manager to take the point on board, followed by a demand to just do it. That's a total morale and productivity killer.

View on HN

> "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.

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."

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.

The parts of the job you can't estimate are actually your managers job to estimate. To illustrate that:

> I am in the middle of developing X right now

That one you can estimate likely. It is a task that you can complete on your own without the rest of the organization. As a individual contributor you should be able to give a time frame for a task like this.

> I am also handling some bug requests related to unmentioned, previously delivered projects A and B

Software is going to have bugs, but I've never worked at a org that labeled bugs correctly. In my experience about half the time a so called bug is a specification miss or a feature request (a management problem), the other half need to be prioritized (again, management problem). If they want you to work on a bug over a project, deadlines are going to slip, and that is a management problem to solve. Your estimate of two weeks doesn't include washing the CEO's car or whatever other random task they want to pull you off to do, two weeks is two weeks and they gave you less than two weeks so of course it isn't done.

> I am in the planning stage for project Y, and working with client and analysts to pull some requirements together

So far you have been responsible for resource management to a large degree. You have to know in advance how many defects your software is going to have, how long it's going to take for a pull request to get reviewed, when the other team is going to get you what you need to complete the work, how often you will get pulled off to work on other tasks, etc. Now you are writing the requirements? What exactly is the management team doing if it isn't managing the product or the people building the product?

What I was trying to say was that there are very valid reasons that mean I cannot and should not turn my attention to a distant project while I have my hands full right now. It doesn't mean I'll never do it, but it does mean that "I don't know right now, I need to complete some work before I can turn my attention to this properly" is not only a reasonable response but ultimately the correct one, rather than throwing out a number that I'll possibly be held to at a future date.

"It's going to take me a couple days to put together a project plan, given that the project itself has yet to be fully defined. Shall I put project X on hold until I get that done?"

Resourcing isn't a individual contributors problem, if it will take you a couple days to get a estimate, and they choose to prioritize that. Fine. If they don't want to give you the time, refuse to speculate, if they keep pushing, tell them it will take a year or some other large number that you could do it 2 - 3 times over in. If they say it won't take that long, ask them how they know since the project isn't defined.

Ah yeah those are some good strategies and they're usually how I approach this when it comes up so I think we are on the same page :) It's just tiresome to have to do, and I feel like in doing so despite being polite and calm I think I'm being thought of as obstinate or a troublemaker. Which is a shame because in fact I'm trying to reduce the uncertainty and chaos and make everyone's lives a bit nicer :) Oh well, like I said it doesn't come up often enough to cause me great stress and I'm experienced enough to sort of handle myself when it does. Just ... I wish it didn't :D

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.

> 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.

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.

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.

>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?

Somewhere between "Let's ignore it for now" (i.e. zero which is a very exact number as a professor of mine used to say), a few days, and "I'm not even sure we can do what's being asked for here" are a whole lot of other numbers which may be useful even if they're off by a factor of two or more.

I've absolutely had management insist on putting overly optimistic stretch goals into schedules but, at the end of the day, they haven't been totally outside the envelope of reality.

Exactly. Well put.

Once you've established that you've given a best-effort answer, and you're being pressed for a different hallucination of a bright future, what is the point? What is the point of giving any answer if the manager can just pull the handle and roll for a better one? If the manager in question wanted to prioritize a specific thing, there can be a discussion about that. Pressing the same button hoping for a different answer just strikes me as a behavior that necessitates record levels of cynicism (which in my experience disqualifies people from managerial positions) or room temperature levels of cognition.

If management is like that, then time to move on. I’m guessing they also expect you to frequently work more than a standard working day (~8 hours).

It’s not the normal behaviour I’ve seen with most managers I’ve dealt with.

That's my whole point, yet people come here to talk about what kind of strategy they use to deal with such nonesense without acknowledging the Sisyphean task of appeasing such managers, which in turn implies validation of such practices.

The other alternative is you start dropping requirements/features to meet their timeline, ideally leaning towards those they probably consider less important, creating the altered project for them. I’ve found doing so to be crucial especially for non-technical communications and when you jump a level (talking to a boss 2+ levels superior)

Otherwise if they won’t budge on time and features and resources, all you can do is put it in writing that you expect x-y time, and optimistically z might be possible.

Ultimately half the manager’s job is to account for that uncertainty with buffers, and they’ll probably double it anyways before presenting it upwards/outwards. If they don’t add their own buffer… they’ll probably run into trouble anyways

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.

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

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.

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.

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.

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.

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".

> "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.

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?

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.

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

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.

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

Reply on news.ycombinator.com