Effective written communication depends on choosing words that are clear and simple. Especially for remote and distributed teams, writing clear messages and providing understandable context is the lifeblood of productivity and success.
But what’s simple isn’t always what’s clear. It may be simple to use pronouns like this, that, these, those, and they; but I propose that these are ambiguous, and therefore dangerous, words:
“This can be used by people to make those confusing things less like that.”
Effective written communication means murdering ambiguity.
If you ever type the words, this, that, these, those, they, he, she, etc. – immediately murder the word. Stab it through the heart. Delete it. Replace this word with what you actually mean.
Typing out what you actually mean requires extra work. It takes more time. But, your colleagues will appreciate your lack of ambiguity. Saying what you mean will almost always reduce the amount of time and energy spent going back and forth to clear up confusion.
*George Bernard Shaw, or whomever really deserves the credit
Being explicit and clear is important not only when the discussion is taking place, but also for future audiences. Consider that written communication is useful as a searchable resource, so learning how to murder ambiguity now is a gift that lives on for future consumers of your eloquence.
Structured Writing is Good.
When Revelers write code, we have a lot of guidance. The languages we use have their own syntax. Even when the code syntax itself does not dictate how something should be written, we often adopt and apply our own additional style guide. We even have bots that run anytime we push up code. These bots notify us if what we wrote breaks any of our rules for how to write.
Before pushing code and testing the products we build, Revelers write a lot of User Stories with a very specific [Given, When, Then] structure to clarify what the business needs, what the various users of the software need to be able to do, and the precise expected outcomes of those behaviors.
User stories create empathy, so that there is a full context present in order to make better decisions about what to build. And by the way: “the user” may not be a pronoun, but it’s still a vague and ambiguous term.
User stories should describe exactly who the user is. It’s a parent who needs to register their child for school. Or a developer who is accessing the API. Bonus points if you’ve actually had conversations with these personas in order to understand their pain points.
There’s a lot of research and reasoning behind the structured writing that directs our work. Which leads me to…
Unstructured Writing is… well… un-good.
Revelers write thousands and thousands of words in our company Slack chat, in drafts of Google Docs, and in comments on GitHub Issues. We don’t have any bots following us around to warn us about the structure, readability, or syntax of all those words. This type of writing is unstructured. But we can make our written communication better.
We type out our communication to each other, and should continue to be encouraged to do so, early and often. One of the best known distributed teams on the planet, Matt Mullenweg’s Automattic, includes this phrase in their team Creed: “I will communicate as much as possible, because it’s the oxygen of a distributed company.”
Nevertheless, we must still remember that effective written communication means relying on structure so that we can formulate our ideas in a way that’s accessible and understandable to our entire audience.
So, when someone says a thing about that one feature that she said she wanted changed so that this will work better, there are no rules or bots to save us.
And since we don’t have those bots or syntax to save us (yet), I invented “Murder Ambiguity”. Trust me, I remind myself of this rule as often as I explain it to anyone else. The concept is simple, but the process takes practice.
Step 1: Remember the Rule
“Murder Ambiguity” sounds ridiculous. Maybe because it is ridiculous. And hyperbolic. But, such a ridiculous phrase really helps out with Step 1, which is simply, Remember the Rule.
We’ve had years and years of practice not using the rule: just pound out some words that sound right in our heads, assume that whomever reads our thoughts will naturally consume them in the same context and tone with which we created them, and just put up with the confusion later.
So, hitting send without considering the rule is a natural instinct. And, since I’m the one doing the writing, I inherently do not have the perspective to read my words outside of the way I hear them in my head. So when ambiguity ensues, I have to hunt down troubled words like I am hunting squirrel in Oregon Trail.
“From the animals you shot, you got 894 pounds of meat. However, you were only able to carry 100 pounds back to the wagon.”
Step 2: Use the Rule
And here’s how you perform the hunt. Put simply: look for any ambiguous word in a sentence, murder it – DELETE DELETE DELETE, and replace the ambiguous word with one that has a more precise meaning.
“
Thiscan be used bypeopleto makethoseconfusingthingsless likethat.”
‘Murder Ambiguity’ is a silly little rule for teams who rely on written communication to make sentences which would otherwise be confusing, much more effective.
“Whatever is well conceived is clearly said
And the words to say it flow with ease.”
-French poet Nicolas Boileau
If you enjoyed this piece, more of my writing lives here!
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.