Few business, creative, or technical professionals write effectively to achieve results. Your writing makes a difference for good or for bad, even if it takes as little as an hour of your work day: blog + chat + comment (in blog or code or document) + email + report + text + tweet. In your professional development, prioritize your communication skills above your favorite skills for a while. If you take risks to communicate more clearly and learn from situations when people misunderstand you, your influence will increase to benefit your team and the community.
Many people think less is more, but feel too busy to write that way. For example, Blaise Pascal wrote, “I made this [letter] very long, because I did not have the leisure to make it shorter.” Jakob Nielsen estimates that most people read about 20% of the words on Web pages. Don’t expect people to spend more of their time reading what you write; invest more of your time writing less for them to read. If you cut anything that causes readers to miss or misunderstand what they need to know and do, you save time that you would spend to solve communication problems.
Just as frameworks like jQuery have helped developers “write less, do more,” Kent Beck suggested a pattern to write a paragraph that gets the attention of busy readers [ACM SIGPLAN Notices, October 1993].
- Important problem: Many people think… For example…
- Why the problem is worth solving: Jakob Nielsen estimates…
- Surprising solution: Don’t expect people…
Beck writes, “You want the reader’s eyes to open wide when they realize what you’ve just said. I think some people are reluctant to boil their message down to one startling sentence because it opens them up to concrete criticism.”
- Result of the solution: If you cut…
Where else can you find that pattern in this article?
It is good if you write less in chat, text, or tweet, unless you leave out
conditions like when, where, or why someone needs to do something.
Communicate more: about what to whom?
Dennis Chambers begins Writing to Get Action with “Focus on the Reader.”
- “Why do so many savvy business professionals insist on beginning with ‘I,’ the deadliest word of all? They wouldn’t begin talking about themselves in a prospect’s office, would they?”
- “If you can’t solve some kind of problem for readers, why are you taking their time?”
- “If you do not have a single main [reader-centered] idea, then you cannot create a strategic document that will drive action.”
Make sure you understand their context: Which readers? Where they are coming from?
The Visit Us page is a good example of focus and context:
Advance thank you’s for your upcoming visit.
If you are… coming from the Airport, driving yourself, taking the Lynx Light Rail
If you apply the robustness principle (be conservative in what you do, be liberal in what you accept from others) as take responsibility for how you read and write, then you won’t need assume that others must be at their best to understand you.
Some talented people jump so quickly from problems to solutions that they short-circuit collaboration. A premature solution discourages other people from suggesting alternatives or even improvements, let alone warning against a
successful failure (the right solution to the wrong problem). Delegate by results to be achieved instead of tasks to be performed. You unleash the potential of your team when you clearly describe the what and why of a problem separate from the how of any particular solution.
When you write to multiple audiences, prioritize and organize what applies to whom.
See also: A Better Way to Fire People by Josh Oakhurst
Lose some battles: you cannot please all people
If your writing helps ordinary people solve difficult problems, expect negative responses! If “experts” feel they are losing control, they might criticize your writing as “simplistic.” One size doesn’t fit all: do what fits your audience and situation. If critics are responsible for work which affects the outcome for everyone, you might rewrite so they get on with it; otherwise, keep calm and carry on.
Just as designers avoid not-quite alignment, writers avoid patterns which don’t quite fit the audience and situation. For example, what got good grades in school might not get results at work. But some people will evaluate your writing
according to inappropriate patterns (their expectations might change eventually if they read enough better writing). If 20% of people give 80% of feedback, how do you decide what to rewrite? Evaluate your communication like an application: test the “user experience” of your writing with up to 5 representative readers, and then iterate if you make significant changes.
Nielsen writes, “To design the best UX, pay attention to what users do, not what they say. Users do not know what they want.” Pay attention to what readers need to understand to do things that matter, not what they say they want to know. Compare the results from tests of representative readers to the feedback from internal reviewers, and then prioritize future feedback: what is an opinion you can ignore and what is a problem you must solve.
Here are 3 C questions to help internal reviewers improve their feedback to you:
- What is incorrect?
- What is unclear?
- What is incomplete for the primary audience?
Reward reviewers who ask why are you telling me this? about any sentence, paragraph, or section. Either cut it because it is irrelevant or rewrite it to make it clearly relevant.
If a coworker asks you to give feedback, don’t say here’s how I would have done it…
Win a war: you can help most people
Many technical workers minimize communication by preference of temperament or from lack of experience. Unknown assumptions increase project risk: if I ass-u-me what you are thinking and why you are doing, I make an ass of you and me. For example, a silent team might not balance efficiency (doing things right) and effectiveness (doing the right things). If someone needs to communicate seemingly-obvious-but-unspoken things, why not you? A few courageous words might change the outcome of a project from failure to success.
Prioritize the audiences of your communication like an application. Alan Cooper writes: “A well-balanced software user interface…doesn’t cater to the beginner or to the expert, but rather devotes the bulk of its efforts to satisfying the perpetual intermediate. At the same time, it avoids offending either of its smaller constituencies.” Because experts have so much influence, Kent Beck writes: “Even if your topic is of broad interest to beginners, there must still be some spark to keep an expert reading to the end.” If you can balance what is interesting to you with what is important to others, you can write something to help the silent majority of people with intermediate skills who do most of the work most of the time.
Illustrations complement of Stephen Davis