Context of whom you are communicating with is also important. That’s the trade off of approaches like these rules. In some situations they are fine. In others not so much.
Wait, what? How does a team habit of bluntly stating facts result in "tribal knowledge"? If anything it should be the opposite. The approach in the article has problems but I don't believe that's one of them.
> This is a recipe for disaster.
What about Crocker’s Rules, and/or this post’s advice to follow them, do you consider a recipe for disaster?
> Please don’t follow Crocker’s Rules;
What outcome are you hoping will result from granting your request? Do you have personal experiences with Crocker’s Rules underpinning this advice? Do you tend to experience social discomfort typically, atypically, or infrequently / never?
> just get better at communicating than the person who wrote this
Other than the presumed adherence to Crocker’s Rules in writing this, which is addressed by the questions above, do you have other criticisms of their writing to present? What communication ideals do you consider as better models than Crocker’s Rules? Do you consider there to exist appropriate circumstances for Crocker’s Rules?
> Both messages contain the same information, however one of them respects time.
Unless you’re an incredibly slow reader this is a tiny amount of time.
> The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear3, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report. You can document contributing factors if they are actually actionable, meaning if there is something structural that needs to change, name it specifically and attach a proposed fix to it.
Those are absolutely relevant! A lead told you to do it? Documentation unclear? One stressed person unable to hand over the task?
And you don’t have to have a solution there to highlight a problem.
> If the payment service went down because a config value was wrong, the incident report should say: the payment service went down because config value X was set to Y when it needed to be set to Z.
Contains zero useful information as to how this happened. It’d be like saying you don’t want to know what the user did before the crash, just that it crashed but shouldn’t have done because it got into invalid state X.
Similarly, many times when you say a variation on "I know you're the expert on the codebase" or whatever, that's because it's true and important. Something I think is a problem, which this article wants me to phrase as a short, plain declaration, might actually just be a misunderstanding on my part. If I get one of those messages, I'm not going to see my time being respected. I'm going to see an arrogant jerk too lazy to learn what they're talking about before shooting off their mouth.
> Thank you for your careful report, I will attend to it asap.
The response was short and to the point, because no other information was relevant. And, indeed, I have written emails like that in the past. But, from the article:
> The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear3, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report.
Those things are often all relevant. I beg the author to read a book about system-theoretic process analysis (STPA). Some are freely-available from the MIT PSASS website: https://psas.scripts.mit.edu/home/books-and-handbooks/. Nancy G. Leveson's CAST Handbook is perhaps most directly applicable.
A proper balance of direct and indirect is the appropriate tack to take.
Why not just
"Communicate clearly"?
- Don't add fluff
- write as plainly as possible
- write as precisely as is reasonable
- Only make reasonable assumptions about the reader
- Do your best to anticipate ambiguity and proactively disambiguate. (Because your readers may assume that if they don't understand you, what you wrote isn't for them.)
- Don't be selfish or self-centered; pay attention to the other humans because a significant amount of communication happens in nuance no matter how hard we try to minimize it.
The number of junior engineers I have had to coach out of this way of thinking to get the smallest fragment of value out of a postmortem process... dear Lord. I wonder if this person is similarly new to professional collaboration.
The larger personal site is very aesthetically cool, though – make sure you click around if you haven't!
This reminds me of when my kids declare "I'M HUNGRY". Cool story bro, I'll record it in my journal.
Isn't it quite the opposite? The person invoking Crocker's Rules is saying, in effect, "my feelings about the information and how I might receive it are my problem to manage, not yours, just give me the information."
You also should take care to avoid crossing the line into just being a jerk. This type of thinking is also often used by people who are simply arrogant and rude and are patting themselves on the back for being that way in the name of "directness" or "efficiency".
oncallthrow•1h ago
dennis_jeeves2•1h ago
Those rules are not meant for everyone.
d-us-vb•1h ago
Smaug123•1h ago
titanomachy•1h ago
I don’t know enough about autism to know if that’s the right label for the second category. (I’ve had coworkers who identified as autistic who seemed to deeply care about whether I enjoyed working with them.) I think these two types of people can work together productively, but I don’t think they’ll ever totally understand each other.