There aren’t many things as important to a successful career as our ability to communicate effectively with our fellow human beings. But effective communication requires a level of thoughtfulness and practice that many of us lack. Fortunately, you can take some straightforward steps to make your own communications more professional and compelling.

I want to start with a crucial point: this chapter is about communicating. Writing and speaking are two media through which communication can take place, but in this chapter, I’m going to focus on written communication. Nearly everything you learn in this chapter will apply to chapter 13, which is about verbal communication; I just find writing to be a little easier to conquer, so I’m starting with that topic.

12.1 Communicating is telling a story

The purpose of communicating is to convey information from one person to one or more other people. If people were computers—infinitely patient, absolutely unselfish, with perfect attention spans and absolutely perfect recall—communicating would be easier. But people aren’t computers: they have their own priorities, they lose interest in things, and they don’t have perfect memories. That’s why being able to communicate well requires you to do more than just spew information at someone: you need to package your information in a way that will best achieve the outcome you’re hoping for.

A co-worker at a former company once raised an issue in a team meeting:

I wanted to bring up a point, because I think it’s an important point, and I was just wondering if anyone else felt this way. During that last reorganization, we had said that we wanted to create teams that were aligned to customer outcomes, but that we knew there would be certain teams that had to be in the background and provide support for shared service. Now, that’s fine, because obviously it’s more efficient, when you look at things like payment processing or authentication or something like that. Those things are all shared services, so it makes more sense to have them centralized into one place. But I was talking to Marcy about it, and you know, some of those shared teams really do have customer-facing outcomes. Because payment processing is something that does surface a user experience and obviously things like security of credit card information is important to customers. So those background teams aren’t always really in the background if you think about it that way. Does that make sense?

Um, no. No, it does not make sense. You’ve rambled for five minutes, and I have no idea what point you were trying to make. That’s because you didn’t tell a story.

12.1.1 The rules of storytelling

Forget about communicating for a minute, and think about some of the best short stories you’ve ever read. Fairy tales are good examples, if you can’t think of any other examples right now. All these stories tend to follow a set of rules:

• They have a clearly defined hero (or several heroes) at the center of the story. The hero’s perspective is what we follow, and the hero is the one we’re meant to root for.

• The hero always encounters a problem of some kind.

• The main point of the story is following along as the hero solves the problem.

• Particularly in short stories like fairy tales, there are no tangents, side stories, or other distractions. We stay on the main storyline with the hero.

• Things in the story happen to the hero and other characters, not to the storyteller. The storyteller is there to relate the story, not to be part of it.

What were Hansel and Gretel’s parents having for lunch that day? No idea. What financial difficulties was Cinderella’s stepmother struggling with? Not a clue. What kind of arguments were the Seven Dwarfs having among themselves? Doesn’t matter. Fairy tales and other well-written short stories are notable for staying on track.

In any communication, whether it’s a quick direct message in Slack, an email to your team, or a contribution in a meeting, you need to tell a story, and to get good at it, you can practice following the rules of good storytelling. Telling a story can be especially difficult when you’re speaking off the cuff, but practice will make it easier over time.

Start with written communications I’ve been presenting at tech conferences since the late 1990s, and I’m pretty good at creating an ad hoc story when I need to. Yet I still tend to lean on written communications more. If there’s a meeting coming up, and I have a point to make in it, I’ll send a preread document, because writing gives me more time to consider, reflect, and edit the story I want to tell. Even when I plan to present verbally, I’ll often do something in writing ahead of time because it helps me frame my thoughts, iron out my narrative, and make sure I’m delivering the right message. Writing can be edited, but speaking can’t!

12.1.2 Applying storytelling to business communication

Now let’s take those rules of storytelling and apply them to everyday business communications:

• When you’re communicating with someone, make them the hero of your story. Making the story about them forces you to switch to their point of view for at least a moment and to empathize with their problems. The best way to get someone to engage in what you’re discussing is to make them part of it. When you are speaking to a group that you belong to, it can also be effective to make we or us the focus of the story to emphasize that “We are all in this together.”

• Clearly empathize with your hero’s problem. State this empathy concisely; don’t wrap a lot of unnecessary words around it.

• Keep your story focused on the hero and their problem. Don’t bring in a single piece of information that doesn’t relate to the hero, the problem, and the problem’s eventual solution.

• Introduce no tangents. Stick with your story. It’s fine to provide historical context to help people understand what you’re communicating, but limit it to the absolute minimum necessary.

• Keep yourself out of the story as much as possible. Remember that nobody’s in business for you. If you’re trying to win people over to your cause, line up that cause with the team, the department, or the company. In business, those groups are usually the heroes of the story.

Here’s an example of telling a story in a memo that puts these principles into practice:

When we created this new org chart, the company wanted to ensure that each team was focused on a customer outcome. The intent was to give everyone line of sight to the customer and their needs so that we don’t lose track of that. That has worked well for those teams, but it has left out the teams that are considered background or shared services, such as payment processing. As a result, those background teams do lose track of what’s important to customers, as we saw with the recent data breach. I would argue that every team actually does contribute to a customer-facing outcome and that we should rethink how we manage and motivate those teams.

Let’s deconstruct that story to see what’s happening under the hood. The hero of this story is we, meaning the department or the company. The story needs a tiny bit of background to set the context. That context comes at the beginning of the story, which makes sense chronologically, and gives the story a forward progression (so that it doesn’t go back and forth between then and now). The storyteller presents a problem that affects the hero—our team or company—and briefly notes a relatable example of that problem (the data breach). The empathy comes from commenting on who has benefitted and who has not. The storyteller doesn’t propose a full solution—often, you can’t solve the problem, so that’s fine—but they do suggest a next step on the hero’s journey. This story is largely devoid of unnecessary words, tangents, or unrelated information. It is concise, and the storyteller’s point can be understood by anyone who’s listening.

Even the shortest direct message can be made better through concise storytelling. Consider this rather blunt directive:

Dave, I think your team needs to refactor this whole module of code.

Now consider a slightly longer, more story-driven version:

Dave, I’ve got to submit another request against that module your team owns. I know that module has gotten huge, and I know you guys are drowning in requests. Would it make sense to talk about refactoring that into four or five modules so we can spread the load out a bit?

Dave’s the hero. You’ve acknowledged Dave’s problem in a way that he can likely recognize and relate to. You’ve offered a first step toward a solution. You’ve not demanded a solution, but you’ve offered to be a part of one in a way that still involves the hero. The revised communication didn’t take much more time to write than the first one, and it’s more likely to generate the response you’re hoping for.

12.1.3 What about mundane, everyday communication?

Not every communication needs to persuade someone to do something. Sometimes, you’re just delivering a status report. Consider this status update:

The build server is down.

Is that an example of pro-level communications? It might be. It depends on your audience.

This missive does, after all, put the audience in the hero’s role. If the people reading that communication will understand it and know what to do with it, you’ve done your job: you’ve acknowledged the audience’s role as hero and given them the most concise story possible. This update would be appropriate and effective on a tech department’s Slack channel, for example. Everyone who reads it knows what happens when the build server goes down, how it affects them, and what they need to do to prepare for it.

On the other hand, if your audience is wider than the tech department, and if the readers are left wondering “When will it be back up? Did I break it? Will I be able to work while it’s down?”, the writer did not do a good job of telling the story. They didn’t acknowledge the audience’s role as hero in the story or see the problem from the readers’ perspective. Here’s an alternative:

The build server is down. The cause is under investigation, and we hope to have it online in an hour. In the meantime, you can continue checking in code, and builds will resume when the server is online.

For an audience of developers, this communication might be more effective. The keys are knowing your audience; understanding how the status will affect that audience; and acknowledging that they, not you, are the important ones in whatever story you’re telling, no matter how short that story is.

12.2 Facing our fear of communicating

When people have trouble communicating well, the difficulty usually stems from

• Lack of practice in focusing on what makes for effective and ineffective communications

• Fear

In this section, we’ll deal with the fear part; the rest of this chapter will address deliberate focus on being effective.

As I wrote in the first part of this book, fear is a powerful human motivator. We often go farther to avoid a frightening situation than we do to achieve something we want badly.

For most people, the fear involved in communicating is a fear of embarrassing ourselves: we’re afraid of looking stupid, and nobody wants to look stupid. Standing up in front of a group of people, we fear that we might ramble, forget the point we’re trying to make, or speak too softly. We fear that this failure to communicate well will cause people to lose respect for us, which might affect our ability to move up in our career. Worse, we fear that people will mock us. Even worse, they might mock us behind our backs. So much can go wrong that maybe it’s easier to stay quiet. Imposter Syndrome plays a role as well, because Imposter Syndrome is essentially rooted in our fear of being found out that we’re not smart enough to deserve to be in the room.

The fear of looking stupid often hinders people from speaking up in meetings or giving presentations, but it can affect written communication as well: writing reports or important email can be nerve-wracking for similar reasons. In fact, one of the reasons I used to reply to emails with extremely terse answers was that I was afraid to write longer, more meaningful, and more compelling responses!

Let’s be clear: if you’re afraid to communicate, you’re locking a big ball and chain on the leg of your career. No matter what you define as your success, and no matter what type of career is needed to achieve that success, communicating effectively is a major part of any career.

Because being an effective communicator is nonoptional, you’re going to need to get past your fear. Section 12.2.1 discusses a path that worked for me and has worked for others as well.

12.2.1 Analyze the causes of your fear

We have a huge advantage as technology professionals because we’re used to analyzing and troubleshooting problems. We do it with code, with networks, with operating systems, with data structures, and even with business processes. Most of us analyze and troubleshoot all the time without being conscious of it.

I was once discussing troubleshooting with a colleague. “I’m terrible at it,” he said. “I always get stuck with where to start.” It was a hallway conversation, nothing serious, and we were both headed to the same meeting. In that meeting, we were told that we wouldn’t be getting the head count we’d requested for our team, which meant that we wouldn’t be able to implement a new set of product features that we’d been looking forward to (and that solved some specific customer problems).

“Wait a minute,” my colleague said. “We’re already spending more than that amount of money on the contractors that make one of the software components we use. We’ve been saying for months that it would be cheaper to ditch that component and use an off-the-shelf one that we pay a small licensing fee for. Can’t we do that now—use the new head count to integrate the new component and then put them on the new feature we know we need to build?”

“Yeah,” I whispered sarcastically to him, “you’re terrible at troubleshooting.” He also thought he was a poor communicator, but from my perspective, both his troubleshooting and his communication were spot-on.

The point is that almost all tech people are really good at troubleshooting, even if we don’t always recognize it. So let’s troubleshoot the causes of your fear of communicating. Here are some possible causes that spring to mind, although you should make your own list (and don’t limit yourself to these):

• I don’t know enough to talk about this.

• I misspell things all the time.

• I stutter.

• I use punctuation incorrectly.

The key is to identify the specific root cause or causes of your fear. Don’t say, “Talking in front of people makes me nervous,” because that’s too vague and does not get to the root cause. Why does it make you nervous? Don’t say, “I don’t like writing.” Instead, ask yourself why you don’t like it. Maybe you have a fear of writing because you took technical writing in college, and the teacher was harsh and unfeeling in his critiques. That’s closer to a root cause: you felt that you were being made fun of, you didn’t enjoy it, and you don’t want to repeat the experience.

12.2.2 Address the causes of your fear

When you start to identify some root causes honestly and frankly, you can do something about them.

Are you afraid of misspelling things? Fine: work on improving your spelling. There are online spelling-improvement courses and websites designed for adults.

Do you have a stutter that embarrasses you? Look into adult-oriented speech therapy classes.

Are you worried that you don’t know what you’re talking about? Remember the difference between confidence and arrogance: confidence is knowing what you know, and arrogance is pretending to know something you don’t know. Nobody wants to appear to be arrogant, but a lot of times, we downplay what we do know and consequently don’t develop confidence. Work on developing your confidence in what you know. Don’t be afraid that you may be wrong about something. It’s fine to be wrong (or at least should be). If you work for an organization that punishes people for being wrong, you should seriously ask yourself why you work there.

Don’t front-load your fear Don’t derail your story by starting with a deprecating remark about it. Whether you’re writing or speaking, don’t open with something like this: “Look, I probably am not an expert, and my concerns might not even be justified, so I apologize in advance if this isn’t appropriate.” Never apologize in advance; you undermine yourself as well as the communication you’re trying to make.

Conquering your fear of communicating is a lot like troubleshooting. First identify the precise problem, and then address the problem. Your first attempt at addressing the problem may not solve the problem, but that’s no different from troubleshooting code or network routing. Sometimes, you need to try different things before you arrive at a solution that sticks.

When it comes to debugging code or fixing a server, you’re not allowed to just give up because you don’t want to address the problem. It’s your job to debug the code or fix the server, and you keep at it until you succeed. You hop on the internet to see what other people have done in similar situations. You take a best guess at the problem, try to fix it, and iterate from there. Solving for a fear of communicating follows the same process.

The only difference between troubleshooting and fixing a fear of communication is that your boss won’t make you fix your communication. You have to choose to address communication fears on your own. It’s up to you to develop the motivation and the sheer will to dig in and do it. The task isn’t always comfortable, because it’s not fun to look at your own weaknesses. But being an excellent communicator is part of your job and your career even if that work isn’t written in the job description.

12.2.3 Conquer fear in written communications

I find that it’s easier to address weaknesses in written communications as a first step because writing isn’t done in the moment; you have time to write, to edit, to reconsider, and to edit again. Here are some ways to improve your written communications:

• Do not use autocorrect. Instead, use your word processor’s spelling and grammar check tools to call attention to your errors. When the software highlights a word or sentence, take the time to understand why it identified that text as a mistake. Research grammatical terms and proper spelling, if need be. Don’t let the software fix things for you; learn the fix yourself.

• Use a tool like Grammarly (which requires a subscription) that can dig deeper into grammar problems than most word processors. Consider using one for a while to see whether it explains the problems and makes the fixes more understandable.

• Take much of what you learned in college writing classes, and set it to one side. Too many of those classes focus on formal types of communication, often requiring you to write in an awkward, stilted-sounding style. You may have learned this style of writing because that’s how technical documents are written, but this is why so many people hate reading technical documents. Instead, write like you talk. While you write, imagine that you are having a conversation with the person or group who will receive your written communication. Then, after you write a piece, read it out loud to yourself, and see whether it sounds like you.

I’ll take that last item a step further: look at how I write right here in this book. I use contractions all the time (although sometimes copy editors who are following a specific style guide will remove them). I refer to myself as I, and you, the reader, as you. It’s like we’re sitting down together and having a chat. On the few occasions when I’ve turned one of my books into an audiobook and done the narrating myself, the work was easy, because my books already more or less read like a script for me. The best compliment I ever received was when a reader came to me after I’d finished a conference presentation and said, “Listening to you is exactly like reading your books, and now when I read your stuff, I’m going to hear your voice in my head.”

If you’re comfortable using short sentences, fine. Do that. Most people tend to speak in relatively short sentences, and short sentences can be easier for others to comprehend. You don’t need to have a special style that you write in and a different one that you speak in.

Learn what passive voice is, and work hard to avoid it in your writing. I’m going to spend some time on that topic later in this chapter, as it’s worth special attention.

When you feel comfortable with what I call the mechanical bits of writing—spelling, grammar, and writing something that reads naturally—you can get into the structure of your writing.

12.3 Applying structure to your storytelling

Structure brings us back to storytelling.

These kids threw the witch in the oven! Can you believe that? Well, I mean obviously she was going to eat them; she was the one who turned the oven on in the first place. And yes, I suppose they were eating her house, but who makes a house out of pastry and candy in the first place? She was obviously a predator trying to entrap children. She might as well have been driving a windowless white van.

Not such a great story, right? The writing is mechanically fine, but the structure is wrong. Who’s the hero? What is their problem, and what is their journey? As you write (or rewrite), ask yourself, “Am I presenting things in a reasonable order that will make sense to my audience, or am I presenting things out of order? Am I providing sufficient context to make my story make sense to my audience, or am I going off on tangents?”

Creating a good story requires you to think about your audience, which many of us don’t do instinctively. Consider this passage:

Our coding standards were developed in a different time and place. Originally, our goal was primarily to make our code more readable, so our standards focused on naming conventions for variables and functions. Over time, we developed basic standards for modularization to try to address the code bloat we were experiencing in some critical sections of the code. But back then, we all used a single coding language: C#. Today, the organization has evolved into a polyglot, with a large code base of C#, a large code base of JavaScript, and a growing code base of Python within the DevOps engineering teams. The coding standards we originally developed no longer scale well across these different languages, and attempting to maintain them slows us down and creates animosity between our teams. I suggest that it is time to rethink the purpose of coding standards, what value they bring to us, and how we achieve that value in our current environment. And rather than the top-down approach we used in the past, I would argue that a more collaborative approach would give everyone, and every team, a stake in the discussion.

Is that passage well written? Take a few minutes to critique it.

(Did you catch were developed in the first sentence? That’s passive voice; you can tell because it doesn’t say who developed the standards. I’d want to rewrite that as something more clear and direct, taking out the passive voice, such as “We developed our coding standards in a different time and place.” If you can’t see what I’m talking about, don’t worry; later in this chapter, I’ll go into the passive voice and its chilling effect on your writing.

What you may realize is that you can critique it only to a point. After all, you don’t know who the audience is. You don’t know what context the audience already has. Is the discussion of where the coding standards started relevant? Maybe, if the audience doesn’t have that history. But if they do, it might be time-wasting. The point is that communications should be designed for the audience who will receive them. Have you ever sat in a meeting with someone who droned on and on about stuff you already knew? They didn’t design their communication correctly.

Beyond that, the structure of my example passage could use a little improvement. Along with the focus on the classic story structure of the hero’s journey, effective written communication often follows a problem-context-solution approach, as I’ll demonstrate in this rearranged version:

[Present the problem first.] The coding standards we originally developed no longer scale well across our different languages, and attempting to maintain those standards slows us down and creates animosity between our teams.

[Provide context.] Our coding standards were developed in a different time and place. Originally, our goal was primarily to make our code more readable, so our standards focused on naming conventions for variables and functions. Over time, we developed basic standards for modularization to try to address the code bloat we were experiencing in some critical sections of the code.

[Connect the context to the problem.] But back then, we all used a single coding language: C#. Today, the organization has evolved into a polyglot, with a large code base of C#, a large code base of JavaScript, and a growing code base of Python within the DevOps engineering teams.

[Offer a solution.] I suggest that it is time to rethink the purpose of coding standards, what value they bring to us, and how we achieve that value in our current environment. And rather than the top-down approach we used in the past, I would argue that a more collaborative approach would give everyone, and every team, a stake in the discussion.

If you’re a visual person, you can think of it like figure 12.1.

Figure 12.1 A model for effective communications

I like this version of the original memo a bit more because it follows a clearer problem-context-solution approach. I want to point out something especially effective: by writing “We developed our coding standards in a different time and place,” the author gives a face-saving out to anyone in the room who may have been a defender of the original coding standards. “Hey, it’s not your fault,” they’re saying. “It was the right thing for its time, but we’re in a different time now.” In doing so, the author avoided a needless confrontation but didn’t waste time beating around the bush.

Focusing on both the mechanical and structural in your writing can be time-consuming, I know. But if you keep at it, you’ll gradually get better. Human brains are amazing things, and they’re wonderful at picking up on what we’re trying to do. If you practice this kind of writing enough, eventually your brain will start doing more of this structural planning proactively, without your having to think about it as much.

Practicing your writing is one of the easiest things in the world to do, thanks to the internet. Start a blog. Don’t worry if anyone else reads it. Heck, make it an entirely private blog, if you want. But dedicate yourself to writing in it at least weekly. Write about a problem you solved, a conversation you had, or any experience or idea that interests you. You’re not trying to teach something to anyone, so the topic isn’t important. What’s important is the act of writing—the process of reviewing and reordering what you’ve written and the focus on the mechanical aspects of writing. Just do it, and I promise you’ll get better at it.

12.4 Practice, practice, practice

There is no way to improve your communications skills except through constant practice. Our global culture doesn’t offer many informal opportunities to practice, though: we communicate more in informal writing like text messages, in which spelling isn’t a priority (let alone grammar). So here are some more suggestions for getting your practice in:

• Blog. As I’ve already suggested, blogging is a good way to practice. Write something, even if it’s only for you.

• Commit to making your work and personal emails more structured. Avoid one-word or one-line replies; write something more meaningful for the sake of practicing.

• Even in instant messages, make an effort to level up your writing. This includes business platforms such as Slack and Teams. Use complete sentences, tell a story, and strive to have writing that shines.

The time you spend improving these skills will repay itself a hundredfold when it comes to enhancing your career.

12.5 Common written defeaters

Writing can be error-prone, of course, and I don’t mean just spelling and grammar errors. A lot of us defeat ourselves with our writing, making it an area in which almost nobody is perfect. But by focusing on two of the most common defeaters, you’ll start pushing yourself closer to professional writing.

12.5.1 Avoid passive voice

If you already know the difference between active and passive voice, stick with me anyway for a second. There’s more here than meets the eye.

You can read official definitions of active and passive voice at sites such as the Grammar Girl blog (http://mng.bz/XYoG), but here’s how I think of them: in a sentence with active voice, it is clear who is doing what to whom, whereas with passive voice, an action gets done, but it’s not clear who’s doing the doing.

Consider The computer is restarted versus Sandy restarted the computer. The first example is passive, and the second is active: Sandy is doing the action (restarting).

College technical writing classes tend to emphasize passive voice, and many of my friends and colleagues tell me that this is where they learned to use passive voice so deliberately. The theory, they tell me, is that technical documents shouldn’t refer to specific people; they should avoid using words like you and I. This approach implies that there are no people in technical documentation, only the things that happen. Can you imagine if technical writing professors wrote fairy tales?

The shoe is manufactured from glass measuring 9 on the Mohs scale. The shoe is worn only until midnight local time. If used during running, the shoe may detach from the wearer and be left behind. The shoe might then be found by someone else.

In real life, we like characters in our stories. Stories are almost always about people, so put people in the stories. It’s fine to use words like we, you, and I. Write in active voice, and make it clear who is doing what.

Avoid the “royal we” Use we only when you’re referring to a group that includes yourself (“We need to think of a new solution to this problem”). Don’t use we in an attempt to avoid the word you (“We will learn how to restart a computer”).

One reason why I emphasize passive and active voice is that in running communications workshops, I’ve found that recognizing and understanding them can act like a switch to make someone’s writing more engaging and natural. That is, when you stop using passive voice, something in your brain flips around, and you start writing wonderful, naturally flowing text that reads much more like a person speaks. Passive voice keeps people from writing like they talk, and as soon as they start using active voice, feeling permitted to use words like I and you, they suddenly get it and start writing well. Give it a shot for yourself.

12.5.2 Prune that flowery garden

We all know that businesses love almost nothing more than trying to dress up language.

In trying to create synergy between our disparate bases, we have identified a number of blocking issues from our customers. The ask we have received is high level, but once we double-click into it we discover a variety of opportunities.

I honestly can’t tell whether that is good news or bad news. This kind of business-speak not only hides the meaning, but also triggers my inner word nerd. Let’s look at some of this jargon.

• Issues have no objectively correct or incorrect answer, only opinions that are open for discussion, such as political issues. Also, magazines have issues. Yet the use of the word blocking suggests that we’re dealing with a problem. If it’s a problem, call it a problem.

• Ask is a verb. It is not a noun. You cannot have an ask. You can have a request.

• Double-click is a trendy way of saying “look deeper into something.” I suppose it was inevitable that drill down would be replaced by double-click, but it’s already feeling archaic. Maybe this should be double-tap? I’m being only slightly sarcastic here.

• Opportunities are usually good things, but in this case I’m left wondering whether the word is a replacement for problems. It’s impossible to tell, which means that this text is isn’t doing the basic job of communication, which is to convey information accurately and unambiguously.

Just because your CEO likes to write flowery, ambiguous, misappropriated words doesn’t mean that you have to do it too. I’ve always tried to advocate for clear, unambiguous writing. If we already have the word request, use it. If something is a problem, and you want to work on solving it, call it a problem. The title of this section, for example, is “Prune that flowery garden.” Why didn’t I use “Avoid ambiguous, pretentious language”?

12.6 Action items

For this chapter, I offer some exercises to help you improve your communications, with a particular focus on written communications:

• Start by going through some of your sent emails and direct messages. Given what you’ve read in this chapter, how would you rewrite any of those communications?

• The next time you send a substantial written communication (say, 600 words or more, which is about two pages in Microsoft Word), follow up with the recipient and ask them what they thought of it. Was it concise? Did it communicate everything they needed to see? Was it clear and well ordered?

• The next time you need to make a written recommendation, review what you’ve written before you send it. Is it concise? Is your recommendation justified, with clear, unambiguous, well-presented data? Do you acknowledge other options and provide data-based reasons to not consider them?