Information vs Assurance

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.

And this is how talking is anchrored in Costly Signaling.

(Note that "I dunno, probably around 9 pm." is still an assurance, though of a different kind: You're assuring that 9 pm is an honest estimate. If it turns out you make such statements up at random, it will cost you.)

And that's why talking can convey information at all.

Me: I dunno, probably around 9 pm. [At this point, I’ve merely offered some information; I think most people would not interpret this as an assurance, and would not blame me much if I show up to the party at 8:30 or 10:00 or even skip it altogether.]

Assuming the conversation doesn't delve further into this, if I were your friend I'd actually be very surprised if you didn't show up. The question 'At what time are you going?' assumes that you're going, however uncertain the details. If you wish to convey the idea of 'you might not see me at all' your answer should explicitly include 'but I might not go' because without that clause you're agreeing to attend, at least at some point.

To be clear, I agree with the gist of the piece. I just find it funny how even such a short convo could lead to a quite dramatic misunderstanding.

On my model, the phrase "I will do X" can be either a plan, a prediction, or a promise.

A plan is what you intend to do.

A prediction is what you expect will happen.  ("I intend to do my homework after dinner, but I expect I will actually be lazy and play games instead.")

A promise is an assurance.  ("You may rely upon me doing X.")

There is a sort of opposite to assurance, where someone communicates their intention to do something (not merely a prediction that they will do it), but without creating any responsibility to follow through. This is usually done via non-verbal communication, like tone of voice, facial expression and "body language". The fact that the intention was communicated non-verbally creates plausible deniability. This happens, for example, in relationships. E.g. when asking after a date if they want to go to his/her room.