The information/assurance split feels quite familiar to me as an engineering manager.
My work life revolves around projects, especially big projects that takes months to complete. Other parts of the business depend on when these projects will be done. In some cases, the entire company’s growth plans may hinge on my team completing a project by a certain time. And so everyone wants as much assurance as possible about when projects will complete.
This makes it really hard to share information, because people are so hungry for assurance they will interpret almost any sharing of information as assurance. A typical conversation I used to have when I was naive to this fact:
Sales manager: Hey, Gordon, when do you think that project will be done?
Me: Oh, if things go according to plan, probably next month.
Sales manager: Cool, thanks for the update!
If the project ships next month, no problem. But as often happens in software engineering, if the project gets delayed, now the sales manager is upset:
Them: Hey, you said it would be ready next month. What gives?
Me: I said if things went according to plan, but there were surprises, so it took us longer than we initially though it would.
Them: Dammit. I sold a customer on the assumption that the project was shipping this month! What am I supposed to tell them now?
Me: I don’t know, why did you do that? I was giving you an internal estimate, not a promise of delivery.
Them: You said this month. I’m tired of Engineering always having some excuse about why stuff is delayed.
What did I do wrong? I failed to understand that Sales, and most other functions in a software business, are so dependent and hungry for information from Engineering, that they saw the assurance they wanted to see rather than the information I was giving.
I’ve (mostly) learned my lesson. I have to carefully control how much I say to anyone not directly involved in the project, lest they get the wrong idea.
Someone: Hey, Gordon, when do you think that project will be done?
Me: We’re working on it. We set a goal of having it complete by end of next quarter.
Do I actually expect it to take all the way to next quarter? No. Most likely it’ll be done next month. But if anything unexpected happens, now I’ve given a promise I can keep.
This isn’t exactly just “underpromise, overdeliver”. That’s part of it, but it’s also about noticing when you’re accidentally making a promise, even when you think you’re not, even if you say really explicitly that you’re not making a promise, someone will interpret as a promise and now you’ll have to deal with that.
There is even a comment perfectly illustrating that some people will interpret all information as an assurance (and insist that it is your fault that they do so), unless you explicitly tell them not to:
I will consider your estimate to be an educated projection based your experience, skills and qualification. [...] if you made an estimate, you need to stand by it. [...] if you say a time then that time becomes yours to live and die by. You said it, you own it. I recalculated my projections, my finances and my resources based on it. You should have said a range of estimates but you didn’t. Estimates becomes deadlines because of your own fault.
If a Doctor gave an estimate to a paitent of 6-12 months of life remaining and the actual amount was 1 month we would investigate why the Doctor was so incorrect. If a builder estimates X tons of concrete and the requirements are double we do not blame the owner of the house. [...] I would be perfectly comfortable raising a legal counter-charge against a contractor for poor estimates.
If your estimate is off you are either fired, charged or will fail to be re-hired. When a carpenter makes an estimate of between X and Y inches he is expected to be right. I apply the same scrutiny to developers regardless of voodoo regarding statistics. If you cannot make accurate estimates you are either not very good at your job (I doubt that) or are unwilling to accept responsibility.
[If you respond to this attitude by padding your estimates] you would be out of a contract for padding estimates by a ridiculous factor margin. Not to mention a counter-charge against you or your agency for misconduct. [...] don’t think for one second a good development team can hide behind the word estimate or any agile principle as some sort of sandbag against criticism. [...] It sounds like you have no confidence in your own abilities.
(I guess this person wouldn’t even have to fire me for making a wrong estimate; if I worked with them I would happily quit.)
Seems like that guy has failed to grasp the fact that some things are naturally more predictable than others. Estimating how much concrete you need to build a house is just way easier than estimating how much time you need to design and code a large novel piece of software (even if the requirements don’t change mid-project).
This happened all the time at my line of work. Forecasts become targets and you become responsible for meeting them. So whenever I was asked to provide a forecast, I will either i) ask as many questions as I need to know the exact purpose of the request, and produce a forecast that meets exactly that intent, or ii) pick a forecast and provide it, but first list down all the assumptions and caveats behind the forecast that I can possibly think of. With time, I’d also get a sense of who I need to be extra careful with when providing any forecasts because of all sorts of ways that might backfire.
I think one clear aspect of the stories here, yours and John’s, relates to what I’ll call asymmetric information flows. Basically, the times at which the information, that no one is trying to keep secret, become known to the relevant parties.
Of course understanding what a good update frequency is for various situations should be is a tricky thing itself.
The information/assurance split feels quite familiar to me as an engineering manager.
My work life revolves around projects, especially big projects that takes months to complete. Other parts of the business depend on when these projects will be done. In some cases, the entire company’s growth plans may hinge on my team completing a project by a certain time. And so everyone wants as much assurance as possible about when projects will complete.
This makes it really hard to share information, because people are so hungry for assurance they will interpret almost any sharing of information as assurance. A typical conversation I used to have when I was naive to this fact:
If the project ships next month, no problem. But as often happens in software engineering, if the project gets delayed, now the sales manager is upset:
What did I do wrong? I failed to understand that Sales, and most other functions in a software business, are so dependent and hungry for information from Engineering, that they saw the assurance they wanted to see rather than the information I was giving.
I’ve (mostly) learned my lesson. I have to carefully control how much I say to anyone not directly involved in the project, lest they get the wrong idea.
Do I actually expect it to take all the way to next quarter? No. Most likely it’ll be done next month. But if anything unexpected happens, now I’ve given a promise I can keep.
This isn’t exactly just “underpromise, overdeliver”. That’s part of it, but it’s also about noticing when you’re accidentally making a promise, even when you think you’re not, even if you say really explicitly that you’re not making a promise, someone will interpret as a promise and now you’ll have to deal with that.
Related: StackExchange: Why are estimates treated like deadlines?
There is even a comment perfectly illustrating that some people will interpret all information as an assurance (and insist that it is your fault that they do so), unless you explicitly tell them not to:
(I guess this person wouldn’t even have to fire me for making a wrong estimate; if I worked with them I would happily quit.)
Seems like that guy has failed to grasp the fact that some things are naturally more predictable than others. Estimating how much concrete you need to build a house is just way easier than estimating how much time you need to design and code a large novel piece of software (even if the requirements don’t change mid-project).
This happened all the time at my line of work. Forecasts become targets and you become responsible for meeting them. So whenever I was asked to provide a forecast, I will either i) ask as many questions as I need to know the exact purpose of the request, and produce a forecast that meets exactly that intent, or ii) pick a forecast and provide it, but first list down all the assumptions and caveats behind the forecast that I can possibly think of. With time, I’d also get a sense of who I need to be extra careful with when providing any forecasts because of all sorts of ways that might backfire.
I think one clear aspect of the stories here, yours and John’s, relates to what I’ll call asymmetric information flows. Basically, the times at which the information, that no one is trying to keep secret, become known to the relevant parties.
Of course understanding what a good update frequency is for various situations should be is a tricky thing itself.