by mactavish88 on 7/11/22, 2:55 PM with 101 comments
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.
by Arubis on 7/11/22, 4:49 PM
- 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.
by pavel_lishin on 7/11/22, 4:22 PM
"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."
by that_guy_iain on 7/11/22, 4:21 PM
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.
by WastingMyTime89 on 7/11/22, 4:28 PM
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.
by corrral on 7/11/22, 5:45 PM
https://ih1.redbubble.net/image.875440864.2771/raf,750x1000,...
Signs like this are so common at mechanics' shops that they're practically a cliché.
Text:
$100 / hr minimum
$150 / hr if you watch
$175 / hr if you help
$200 / hr if you worked on it first
$250 / hr if you tell me how to do my job
by jlarocco on 7/11/22, 5:18 PM
> 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.
by firefoxd on 7/11/22, 6:19 PM
On the first recording, I rambled for 15 minutes why I think it will take n weeks and cost x dollars. Rewatching it was painful. But it gives you a good idea what to take out.
After the 10th recording, 2 minutes was enough to give the estimate and give a rough description of the work that needs to get done.
Also, you'll have to make 10 wrong estimates before you build up the skin you need to say you stand by your decision. Just because your clients are engineers, it doesn't mean they know what it takes for another team to do the work.
by uptime on 7/11/22, 5:14 PM
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!
by lacker on 7/11/22, 5:13 PM
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.
by Galxeagle on 7/11/22, 4:03 PM
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.
by kqr on 7/11/22, 5:33 PM
Perhaps more usefully, it also means that if you say "there's a 90 % chance it is done before this day" then 18 times out of 20 will it be done by that day, and only around two times will it be late.
I have calibrated my estimation skill, so whenever someone challenges my estimation, I urge them to keep score and find out that I'm right just as often as I claim to be.
(If I'm particularly bold, I suggest a bet. I'm confident enough to make money on it in the long run.)
However, usually it doesn't get that far. Once I start explaining that it's a probabilistic measure of high certainty customers and managers back off.
----
Some people want to be reassured that I don't plan on taking as long as my 90 % estimation suggests, so then I give them something like a 10 %--90 % span and say, "it's unlikely to be done before this day, but also unlikely to be later than this. This interval is wide today because there are many uncertainties for me. As I learn more about the problem, this interval will narrow."
by cargregter on 7/24/22, 11:41 PM
by IlPeach on 7/11/22, 4:07 PM
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.
by kgermino on 7/11/22, 5:30 PM
1. A quick (few paragraph) run through of where I see the complexity that led to the estimate. This often reassures people, sometimes helps us discover a disconnect on the requirements (where I imagined something more complex than they needed), and is sometimes a waste of breath.
2. When (1) doesn't change anything "I don't litigate estimates. Based on our discussion this is my best guess at when I will be able to finish this for you, not a fixed bid. If I'm done early you'll get it early."
by d23 on 7/11/22, 5:22 PM
For example: "if you want it done in 2 weeks instead of 2 months, we can get to X functionality while sacrificing Y." Or: "what would it mean for you if we were to get this done in 2 months instead of two weeks? How would it affect you?" Basically: try to get to more of the root of why they're questioning your estimates without putting on the table the notion that you can magically change the truth about how much time things will take.
As others have said, also express your degree of uncertainty. Try to leave your ego out of it and make sure you're not giving them some sort of subconscious ammo that you're hiding something or being manipulative.
> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.
You're right, but if their deep belief is that your team just isn't adequate, you need to force them to bring it up. Yes, it will be insulting to find this out, but people tend to dance around these things with euphemisms and coded language, and one of the best things you can do is get it out in the open.
by spoonjim on 7/11/22, 4:37 PM
by OrangeMonkey on 7/11/22, 4:12 PM
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. :)
by maerF0x0 on 7/11/22, 5:36 PM
le sigh
/rant
by orangesite on 7/11/22, 4:51 PM
by newusertoday on 7/12/22, 5:36 AM
I take data from previous feature requests that were completed and number of bugs reported/refactoring etc. to create a rough cost estimate for maintenance in terms of man hours with the understanding that this is not perfect and there could be +-10% variation and this is only an estimate for planning. It worked well for me, other org's were not able to argue with me as i just showed them the data. Estimates were surprisingly accurate(its anecdotal) but i did not saw estimates overshooting/undershooting the +-10% variation. Later on this was adopted by the whole organization. I left but my guess is they are still using the same methodology
by ineptech on 7/11/22, 6:05 PM
This is a thought-terminating cliche (https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A...), i.e. saying nothing politely. It contains no information; its purpose is to close that topic and pivot to a new one - discussing a different team doing the work, changing the ask, hiring contractors, etc.
> Ideally one that results in the customer understanding that they're crossing a boundary of sorts here.
A great low-conflict way to convey this is by being more formal/icy in your phrasing than usual.
by isitmadeofglass on 7/12/22, 9:45 AM
In reality what happens is that you end up having a manager in your estimation meetings telling you that one of the elephants have to be a gazelle, because he needs to make a deadline and believes that forcing your estimate will somehow bend reality to conform to it.
by awillen on 7/11/22, 5:20 PM
1. If there's something unintuitive to a non-technical person, call that up out front as a reason for the estimate. For example, if you're estimating how long it'll take to implement a popup, but there's some piece of information displayed in the popup that you need to get from some archaic system that is held together with tape and glue, you might come up with an estimate that seems very large to someone who thinks all you're doing is implementing a popup. When this happens, it's best to call it out up front when giving the estimate, as opposed to giving a big estimate and then giving the explanation only when questioned.
2. On a related note, give options. This works very well with toddlers (don't tell them they have to put on pajamas, ask them if they want to put on the red ones or the blue ones) but also often with PMs and management. In the prior example, instead of saying that it's going to take three weeks, say that it's going to take three weeks, but two weeks of that is because you have to pull this one piece of information from that archaic system. If we could go without displaying that piece of information, then the estimate is a week. If we could instead display this similar piece of information that's easier to get, then the estimate is a week and a half. When you do this, you come off as thoughtful and prepared, and you put the people you're talking to in a position where they feel like they've done something by making a choice.
People generally question estimates because of a lack of context, so when they do so, I really encourage you to think of it not as them not trusting you, but rather as them attempting to get the context they need to understand.
Some people do also question estimates because they feel like it's their job to haggle developers down (these people are annoying and do not represent most PMs). Number 2 above is a good way of dealing with this - it turns it from haggling into a negotiation over scope.
by EddieDante on 7/11/22, 3:02 PM
by gridwin on 7/12/22, 5:54 AM
by sneak on 7/11/22, 11:43 PM
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
We've all been bitten by the "it'll just be x, y, and z, no big deal" engineering bias when we plan a system in our head.
Reality has a lot more detail than mental planning does.
by M4R5H4LL on 7/11/22, 6:12 PM
- Get support from top management on the client-side. Provide quality metrics quarterly (number of bugs reported, releases, etc.) and show positive trends.
- Iterate faster - like every week, and show what has been delivered. Prioritize what has actual value for your clients., and let them provide feedback.
- Make your clients have skin in the game. The problem with folks challenging estimates is that they are not involved in the process, e.g., they are not contributing to the product. Without being involved, they can only provide feedback such as "I don't understand...". It would help if you found a way of having them contribute to the product, and the conversation will change from estimates to the product's actual value. Ask them to review features, prioritize, read release notes, suggest improvements, share their experience with other clients, etc. If you have ways to open your product and processes, it should help.
by gxt on 7/11/22, 10:33 PM
I'd inquire why they are saying that. Are there requirements in your proposal that aren't required? Enterprise development best practices for instance, if the customer wants to prioritize time to production or time to market, it's normal for him to push aside writing 12 factories and 7 dlls to later/never.
by nickmyersdt on 7/11/22, 6:45 PM
Fundamentally establish trust through transparency.
Remember most humans are trying to justify or find reasons to do something. Finding out it will take too long or be too expensive (in their eyes) is a reason not to do it. If those people have already made "positive noises" to other people, then your reality is going to run head on to theirs.
Help people, perhaps by asking up front "how much effort do you want to spend solving this".
It's not disrespectful at all. The engineering team does not exist in a vacuum independent from everyone else. What does happen is that engineers with a lack of maturity hate to have their judgment questioned.
Without knowing specifics of context, perhaps by understanding the constraints, needs of the business or limitation on budget, then any estimate you provide is going to be wrong in the eyes of the reciever.
IMO anyway.
by yobbo on 7/11/22, 4:26 PM
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.
by dqpb on 7/11/22, 5:23 PM
I think you're looking at this the wrong way. If the customer / manager want to get into the weeds with you, you should let them. Information sharing leads to good things.
Giving the customer/manager details about the work required for a feature will help them better understand and prioritize future work. If you and your team are excellent, going into the technical details will impress the customer/manager and gain you the respect you are looking for.
On the other hand, if you are defensive and withhold information, that will only erode trust and push them away. Eventually, they'll look for someone else to work with.
As a side note, scrum boards are stupid. What people really need are dependency trees.
by thenerdhead on 7/11/22, 5:08 PM
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.
by joncp on 7/11/22, 5:50 PM
* Known tasks and how long each will take (with error bars),
* An overview of known unknowns, how they might impact the project, and what research would bring them into focus,
* Then I bring up the dreaded unknown unknowns.
With reasonable leadership that usually leads to good discussions about reining in the scope.
by yakak on 7/11/22, 7:17 PM
I think a lot of organizations add more and more requirements to "guarantee quality" after each incident and never really streamline again, so my first guess with a group that is opaque about the specifics is that it has gradually built up doing too much and only feels comfortable if it performs a lot of rituals. An idea of where you see the risks and what buffers you are using may make people more comfortable with your estimates being logical instead of the consequences of process gone awry.
by PeterStuer on 7/12/22, 8:18 AM
Even in a fixed price setting (there is no such thing really as your sales will be peppering them with change requests on the vague initial requirements contract anyways), the client wil want the solution ASAP as 'time is money friend'.
Software is a "lemon's market". Neither buyer nor seller has enough information and there is a huge history of failure, malpractice and outright fraud. While I feel your pain, this unfortunate reality is infertile to trust building.
I wish it could be different but I doubt it will.
by jonaldomo on 7/11/22, 5:03 PM
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.
by dnndev on 7/11/22, 5:19 PM
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.
by gepiti on 7/12/22, 7:16 AM
Estimate X is 10000 (amount, time or whatever). It will come from A (5000) B (3000) and C (2000). A will come from A1 (500) A2 (1700) A3 (1300) A4 (1500). A1 is derived from A1.1 (200) A1.2 (200) A1.3 (100). The deeper you go in the analysis the more difficult it will be for anybody to check all the data and prove you wrong.
by njacobs5074 on 7/11/22, 5:30 PM
If you think it'll be valuable, you could ask them why it's important that you hit their date. Most likely they're being pressured by someone else.
But at the end of the day, you own the delivery of the product. Smile, nod, and get back to delivery.
(And yes, it's easier to write that then to do it)
by pwason on 7/11/22, 3:16 PM
by tpoacher on 7/11/22, 8:34 PM
> Why would it possibly take so long? All you have to do is A, B and C!
We would be happy to deliver A, B and C exactly as described at the proposed time. We anticipate these problems. Happy to accept the risk?
by wetpaws on 7/11/22, 5:32 PM
by stevenalowe on 7/11/22, 11:21 PM
by timdellinger on 7/11/22, 6:12 PM
by codegeek on 7/11/22, 4:46 PM
Never let someone tell you your estimate is too much. If it,s too much let them do it themselves.
by yayr on 7/11/22, 4:42 PM
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.
by uraura on 7/13/22, 3:18 PM
by steveBK123 on 7/11/22, 5:14 PM
* 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
by nprateem on 7/11/22, 5:01 PM
by daanlo on 7/11/22, 5:02 PM
