Ask HN: How do you deal with managers/customers questioning your estimates?
Whenever we tell them, for example, the team has estimated it'll take X weeks to do something, we continuously get pushback of: "Why would it possibly take so long? All you have to do is A, B and C!" (often providing incorrect solutions, increasing the burden of having to explain all possible implementation strategies to them and the risks involved with each step)
I've also experienced this in previous companies where managers, who used to be technical, do the same thing.
To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
Has anyone found a healthy, emotionally mature response to this line of questioning? Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
In an ideal world I'd much prefer to not have to give estimates in the first place, and rather involve our customers more frequently in our development process to help them see the progress. It's hard, however, to convince them of the value in this approach.
106 comments
[ 2.8 ms ] story [ 173 ms ] threadA lot of bosses do that I think. They accept your estimates but internally they expect you to always be under the estimate. Accusations of laziness fly eventually if you are over estimate, or even meet your estimates consistently.
It had a helpful effect of abstracting the development team and helped shift the conversation away from button clicking towards a ‘product increment’ and all the extras it entails, but also from the customers perspective it helped engage them on a more meaningful level - prioritization of features vs the technical steps the dev team would be performing.
Then we avoided justifying timeline in favour of ‘if you wanted it for next release, we’d need to drop a/b/c or add resources x/y/z’ beyond a cursory ‘it adds some complexity with the other module’ etc.
In my own experience it's a two-fold process:
- one is the ability of the engineering manager and the product manager to work towards a phased approach (smaller iterations means better chances at hitting the deadlines/estimations -if any)
- the other one, by working closely with your stakeholders, so they have a good understanding of what's going on and the status of the team, effectively building a trust relationship.
Rule 2 - When questioned on estimates, say "The business needs XXX level of reliability and we have built our software and release practice up to the level we can deliver on that. The estimate takes into account this process, qa, defect cycles, and release constraints." and do not deviate from it.
Unless Rule 3 - Deviate the heck out of it if your estimates plainly suck. :)
To be fair, people asking you to justify your estimates aren't disrespectful. Realistically, you should be able to provide justification otherwise, your estimation is most likely flawed. And people wanting to have a better understanding of what is going on isn't necessarily a bad thing. Just like you would ask your joiner why it's going to cost X and take Y days, you want to have a good understanding of what is happening and to be informed.
In my experience, people are only _pretending_ to ask you to justify estimates. In reality, they are just angling for a discount and/or rush job. It's just a technique for increasing anxiety.
I recommend not default-reacting to "why does it take so long? Isn't it just A, B, and C?" as an expression of pushback, but rather just as an expression of honest confusion.
And I do agree with OP: every company does this. They want to squeeze every bit of work out of you, and this comes in other forms, not just through 'agile estimates'. Communications across teams that emphasize 'work-hard play-hard' also fall under this, and the 'play-hard' never actually comes. It's just new time-crunched work that gets dumped onto you. Or 'move-fast teams', or 'OKRs', etc.
The entire corporate infrastructure and communications is designed around pressuring workers to work more and more. Sure, there might be some great managers that can push back, but how many of them have you encountered across all the jobs you've been at? Most of my experiences have been what OP has said, most teams are terrible.
It's not a coincidence that the Tech Burnout Index is almost 43% across all of tech. Which means any job you jump to will have a good chance to burn you out some way or another. Which means all the crap that developers experience that burns them out is nearly ubiquitous, including being constantly grilled on estimates.
Burnout Index: https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...
If that conversation is happening with senior management, it can also identify some consistent mismatch between their perception and reality. (Didn't your team get 5 new hires last year? Yes but two are on leave and we also took over responsibility for customer-facing documentation from marketing). Or reveal new priorities when consistent themes come up -- maybe the testing process is being slowed down by a growing matrix of product configurations, and management had no idea how much work that creates.
When the language shifts to something like "regardless of your estimate, we need it done by the end of Q3, so make it happen", then I treat it as pushback.
This has been how I handled issues, yet I'm getting more convinced that it is not productive.
People don't learn through only repeated exposure. In the second time something happens, they should be reminded of the first time. And in the third time, they should be outright denied any explanation with a reminder of the first two incidents. Otherwise, they'll keep doing the same thing, probably because it's very low-cost to them, and I'll keep spending my precious resources.
In my experience, they definitely don't know. But no amount of explanation is going to do it for them; any explanation is going to be met with stuff like "well, there must be a simpler way", which is a hell of a statement when it comes from someone who has no idea what they're talking about.
And oftentimes, at the point where you're making the estimate, you don't know how long "A, B, and C" are going to take. You might know how long they will take if the system underpinning "A, B, and C" do their jobs, but they inevitably won't do their jobs, and the extra time is usually working around the failings in systems that you have no choice but to use.
The software is being written for the customer and/or management, and they're paying for it. They have a legitimate right to know why the estimate is what it is, and to understand what work is going to be done. If they want to exclude parts of it because they don't see the value, then that's up to them because they get what they pay for.
If you can't explain why it's a bad idea to cut certain parts out, or why certain things take the time that they do, then it's a failure on your part as the engineer, and not theirs.
That's what expertise is sometimes like: an accurate gut feeling, impossible to articulate clearly.
You don't have to articulate it clearly, you don't have to know why you are making the estimate you are making. It's ok for management to push, in fact it is their job.
I suggest this book. https://www.amazon.com/dp/B004IK8Q22
If nothing else, management will be more trusting in those situations if you give good and accurate estimates the rest of the time and are able to justify them.
The presumption in their attitude and approach is that our team doesn’t know what they’re doing and they could do it better, even though they haven’t put in the effort to do the scoping.
I think it's more than you're being questioned and you don't like that and feel like your word should be enough.
"Your estimate assumes the absolute best case scenario, and also assumes that we'll be working on nothing but your request. Our original estimate stands."
A long time ago I read about some research that showed that the original implementation makes up about 1/6 of the total time spent on the task. This has been roughly the case in my experience too -- so now I budget for at least 6× estimated implementation cost, more if it's a tricky problem.
How else can I keep my reputation as a miracle worker?
At the end of the day, Ford doesn't care about its IT environment - they care about building and selling cars, trucks, etc
The NASDAQ doesn't care about the OSes on their servers, they care that transactions complete properly
Learn to speak to the business case, and the tech takes care of itself (more-or-less)
The team is probably underperforming relative to the expectations. This is what it feels like to be questioned and put under pressure. It is technically disrespect.
To what standard should the team perform, and how can it be determined if it is?
Maybe make some sort of benchmarks visible that establish the competence and prestige of the team.
From my experience, 90% of the time these mismatches come from a lack of or a flawed communication. The solution is to sit down with your customers, ask questions to understand why they feel what they feel and specifically address that. I think that in general people working in software rarely spend enough time talking with their clients.
It’s the same with managers actually. If there is a persistent mismatch between what you think you should be doing and what your manager thinks you should be doing you are not talking with your manager enough.
It's important to think about how the communication is failing.
The customer/manager might be comparing your performance with others who are faster or cheaper.
Some might have more technical experience than you; and are in effect asking you to explain and justify your solutions.
Or, they might not understand or care, while still being convinced that you are underperforming ("being incompetent").
I'm not sure if this applies to more seasoned engineer-customers though. The more experienced engineer-customers (people who've been working for 10+ years) tend to be far more understanding here.
It’s therefore the role of the salesperson/whoever is in charge of the client at this point to set clear boundaries. It doesn’t have to be extremely adversarial. You have to understand why your customers is trying to push there in case there is something to address - for example if they think you are underdelivering that needs to be worked on - then explain what can move to find a solution - typically reducing scope or raising the budget to go faster - and stand firm on what can’t.
If you can’t emotionally deal with this process which is a job in and of itself you need to put someone who can in between you and your customer.
That to me seems like a far more reasonable negotiation strategy.
To tell someone how they should be doing their job, I find, is disrespectful.
But I agree, putting someone more emotionally capable between the team and the customer is probably the best way forward there.
You are taking things too personally here. As a consultant I have been working fairly regularly in the past few years on large software projects for some of my customers. That has involved being in charge of formally setting business requirements and negotiating price and schedule for scope modifications with their providers.
I will systematically challenge any provider planning for a few reasons:
- If they fold straight away, it’s a free win for me and I have children to feed.
- I will myself pad a planning when I am in the reverse position to give me leeway in negotiation and I don’t want to leave all of that on the table.
- Keeping a moderate amount of pressure on my providers will help me in futur negotiations. I want them to leave the table feeling I made some concessions.
- Having my providers be late is extremely advantageous for me. On large projects it’s a quasi-certainty that at some point they are going to complain about scope creeps or delays in writing the specs and ask for money. If they delivered late, I have something to push back with especially if penalties are involved.
- I am also systematically negotiating hard with companies which did themselves do it. If finding a price with your company was a pain, I am likely to retaliate on scope and schedule.
If you are strictly working on the technical side, you are probably not privy to most that. A significant part of what’s happening might not even be related to you or the quality of your estimation at all.
In a product those typically are not so much negotiable with respect to the architecture. In a project they may lead the customer to change their architecture priorities completely.
Never let someone tell you your estimate is too much. If it,s too much let them do it themselves.
- Supply confidence intervals. (“50% likely it’ll be done by date X, 90% likely by date Y.”) Estigator.com is great for helping construct and illustrate these.
- Demonstrate understanding of client/customer/manager priorities, frustrations, and necessary tradeoffs: show compassion and supply suggestions for where scope can be narrowed if needed.
Can you explain why? At least for predicting expected task finish times, I feel like people use them interchangeably.
"Forecast" is an expected date that may change due to circumstances.
"Estimate" is how long something will take, regardless of circumstances.
If you say "I estimate 2 weeks", then the word "estimate" is often taken to mean "2 weeks, plus or minus 10%" (or some other fixed bound), when what you probably actually mean is "between 1 week and 6 months, but probably around 2 weeks".
There may be better tools out there, and I'd be happy to hear about them; this is the one I recommend only because I don't know of simple alternatives.
I made my own text-based tool for this at one point, but I lost it when I switched jobs.
I would like to recreate it except more generally useful. I would also like to make it compatible with the SIPMath standard (which are an open standard for conveying empirical distributions, e.g. as business-relevant inputs to estimations, or the outcomes of them.)
I think this is huge. I've found that if you ask if they need to cut things from the scope to hit a deadline, and tell them you'll work with them to get a scope that is reasonable by the time they selected, it works wonders. Sometimes it turns out they really need a small thing to get their next project out, but they are asking for far too much.
IOW ... it's all ROI - you have to be able to speak to everyone in the room at "their level" about the costs/benefits of the whole operation (see https://antipaucity.com/2015/05/05/what-level-of-abstraction...)
Expected release dates should be broad, next month, next quarter, etc.
Estimated release dates take into discussion what is also being worked by development team.
You get better at it with time. You'll get better at arguing your case. You'll get better at justifying certain work.
It is worthwhile to clarify to everyone that it is an estimate and not a promise. If someone tells you they can do it in half the time, then a friendly "feel free to help contribute to the project" can shut up people quickly.
If possible, try to get away from this practice and to more agile practices. That way you would be able to just talk about when you start and cease certain work or give wild ass guesses instead of wasting too much time estimating.
If you get this pushback from most of your customers, that means your team is widely perceived as underperforming. If you're the manager or a leader on the team, you should do something about this.
First, you have to be honest with yourself. Maybe your team is underperforming because of the people on the team. Maybe some of the engineers on the team are underperforming, because they aren't able to meet the standards of your organization, and they should be managed out.
There are a couple other possibilities. Your team could be underperforming because it lacks some underlying infrastructure. For example, minor changes might take too long because the test infrastructure is too slow. You might be dependent on some other team which is too slow. You might really need to invest some effort in improving underlying automation. The right course of action depends on the underlying facts, but basically, maybe there is some medium-term plan that can improve this, and you should figure out how to do it.
The final possibility is that there's nothing you can do except communicate better that people should lower their expectations of your team. Just mentally prepare yourself to have a lot of this sort of conversation forever.
A big problem can be that the customer wants you to treat some tasks as worthless or free (or your problem as overhead), because they might be treated that way internally. You will not have a good time with that, so might as well stick to your guns.
The other problem is that often the customer is doing this because it has worked in the past. You can say that while others have salespeople that treat estimates as haggling - leaving others to do the work, you prefer to offer estimates based on project success not bonus money.
In both cases you are going to want to get comfortable defending your practices. You can ask satisfied customers what they liked about working with you and might get your talking points!
* Effort vs duration
* Best case vs worst case
* Levels of certainty
* Risks and how you account for them in estimate / plan to mitigate them
Etc
> Has anyone found a healthy, emotionally mature response to this line of questioning? Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
TBH, I don't see what the big deal is. Give them the data and explain the thought process that went into making the estimate. And if you don't have any of that to give them, then I think they're justified in questioning the estimate.
If you don't like it, switch to regular releases, and tell them the feature will be in the next quarterly release.
If they want details I tell them I need to bill for the time and file it under project planning. Amazingly they are happy to pay for it and we are happy to do the paperwork they require.
If they say no they won’t pay then you make a judgment call on how important that client is to you. What I have found is if they nickel and dime you then your not providing value in their eyes. Move on to a higher value client.