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