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.
5Related: 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 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.)
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.
1Me: 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.
In contract law, there’s this thing called a “representation”. Example: as part of a contract to sell my house, I might “represent that” the house contains no asbestos. How is this different from me just, y’know, telling someone that the house contains no asbestos? Well, if it later turns out that the house does contain asbestos, I’ll be liable for any damages caused by the asbestos (like e.g. the cost of removing it).
In other words: a contractual representation is a factual claim along with insurance against that claim being false.
I claim[1] that people often interpret everyday factual claims and predictions in a way similar to contractual representations. Because “representation” is egregiously confusing jargon, I’m going to call this phenomenon “assurance”.
Prototypical example: I tell my friend that I plan to go to a party around 9 pm, and I’m willing to give them a ride. My friend interprets my “plan to go around 9 pm” as an assurance: if I fail to show up around 9 pm to drive them to the party, and my friend misses out on some big thing at the party as a result, then they’ll place the blame on me. It’s a kind of non-monetary insurance - if my assurance fails, then I’m socially liable for damages.
In that context, it all seems pretty obvious - people would normally interpret me as having made an assurance (even if they wouldn’t know how to articulate it), I have knowingly taken on that assurance, so it’s totally reasonable to blame me if I don’t show up around 9 pm. But the whole thing is very implicit, which can make things subtle and tricky.
Suppose the conversation leading up to the 9 pm plan went like this:
That’s the sort of subtlety which comes up: I intended 9 pm as a prediction, but it might get converted to an assurance in hindsight. And whatever request would convert my prediction to an assurance is implicitly more costly than it sounds.
One major problem which information/assurance ambiguity creates is that it’s potentially-costly to share information, if that information might be treated-in-hindsight as an assurance.
Here’s a real example: a year or so ago, a colleague applied for a grant from the Long Term Future Fund (LTFF) to work with me. One of the fund managers reached out and said roughly “John, we’re imagining a virtual John Wentworth organization, and here’s the amount of funding we’re willing to allocate this year to the virtual John Wentworth organization. Do you want some of that funding to go to your colleague?” and I said “Yup”. Some time later, the colleague applied for another grant, and the amount he applied for was turned down. I contacted one of the fund managers and basically said “WTF dude, last I heard I was using way less money than the LTFF was willing to fund me for, why is this being turned down?”. It turned out that the information I’d received was out of date, due to various changes at the LTFF.
… and afterwards I apologized for being so annoyed. Because I want it to be cheap for people to share information with me, and getting angry when the information shared with me turns out to be wrong makes it more expensive to share information with me.
Takeaway: notice when you treat information shared with you as an assurance, and check what incentives you set up by doing so.
but do not represent/assure