A friend of mine worked at a large company in their IT department. He developed a friendship with an executive on the business side. One day while discussing a project, the executive openly admitted that he didn't trust him. He said, "It's nothing personal, it's just because you're in IT. The last decade has taught me that IT cannot be trusted."

So when clients (business or execs) ask about teaching their developers about better estimation, I share that story. They always identify.

Then I ask, "Do you trust your developers' estimates?" They always answer no, not really. I ask, "What would it take for you to trust them?" They always answer, "We'd have to start seeing accurate estimates?"

So I ask, "How long would you need to see accurate estimates, how many projects in a row, before you could begin developing trust and believe it's not a fluke?" The answer varies, but the answer is usually more than one or two. And in this dialog, they begin to realize that even if I can wave a magic wand and turn their developers into perfect psychic estimators, it will make zero difference to their business operations for longer than they're really comfortable with.

As they begin to recognize the  insanity of pursuing this course as a solution to their frustrations, they open up to better possibilities.

Then I ask, one of two questions:

Question 1: "Since it's going to be a while before you can really trust your developers' estimates anyway, would you like to know how to shorten the process?" This leads to a conversation about

a) shorter iterations to have more learning cycles, and

b) having the business do their own estimates based on the rate of results coming out of development - rather than asking developers to estimate. Those two things start reducing the adversarial culture, increasing safety, and increasing learning.

Question 2: "Since it's going to be a while before you can really trust your developer's estimates anyway, would you like to know some of the things that damage their ability to estimate - so you can help with the process?" This also leads to two conversations:

a) the fact that technical debt is not merely interest payments which would be predictable, it's a hazardous code base that injures everyone by creating surprises and preventing any viable projection, and

b) the fact that the adversarial relationship around estimation is damaging collaboration and costing increasing amounts of time while taking time away from delivery. Since developer estimates aren't credible in this environment anyway, they might as well put less focus on them until they heal this damaged part of the culture.