Chapter 3:
Written Communication
It is nearly impossible to overstate the benefits of being able to write well.
In my experience it is more important to be able to write well than to speak well, at least until you reach very senior levels of your organization or are interacting regularly with the public directly as a representative of your company.
Writing’s twin skill is speaking, both public and private. Most of us handle the mechanics of private speaking (verbal interactions one-on-one or in small groups) fairly well after a lifetime of practice, and in the next chapter I’ll review some techniques for becoming even more effective. Then there is public speaking: because so many people are not comfortable speaking publicly, and because the issue is so emotionally charged for so many people, almost everyone can accept a speaker who is simply adequate. As we’ll see in the next chapter, though, if you’ll work to improve this skill you can dramatically accelerate your impact.
Writing, however, is different. Because of the central role it has in the success of an organization and the execution of the mission of that organization, the ability to express yourself only adequately is simply not, well, adequate.
Much of what you will produce as a scientist or engineer will be written products. Product documentation, Web sites, progress reports, feasibility studies, and so on are all part of the products we are helping to develop. You may be setting out to build and sell biochips for medical monitoring, but if the instruction manual or installation guide or product design guidelines for your biochip are unintelligible, your product and your company are not going to be successful.
With the importance of e-mail in all professions, but especially in technology professions, writing has become the foundation of that all-important interaction: the first impression. Many times the first interaction—perhaps the first of several interactions you have with a client, a peer, or a boss will be via e-mail. Writing well and clearly communicating your message will shape a positive first impression of you and the kind of person you are, and also of your technical competence. Creating a poor personal first impression in writing is something you can recover from when you actually meet the person, but you will have a hard time recovering from the poor impression your e-mail recipient will form of your technical abilities. They shouldn’t be related, but they are (this is because you are actually selling a service; more about this in the chapter on branding).
The importance of the written word in storing, sharing, and communicating ideas at all levels of all organizations makes a poor facility with the mechanics of writing a severely career-limiting fault. Even if this doesn’t inhibit you in an entry-level position, you will run into a wall on your first promotion. Team leaders have to maintain a variety of written documents, including project progress reports and plans, which many people will review. If you cannot create these written documents effectively, you will quickly stagnate. You might say to yourself, “Well, that’s fine for those money-grubbing prep-school folks, but I want to be an engineer the rest of my life. I don’t care about getting promoted, so my writing doesn’t matter.” Wrong! If you want to spend your life head down in the trenches, it is probably because you care passionately about what you are doing. In order for your designs and ideas to be implemented, however, you’re going to have to be able to communicate them to others in … guess what? … writing!
What’s here
This chapter covers the different types of written communication you’ll encounter in your career, and provides pointers on how you can shape the way you think about the written word and approach writing, ways that will help you turn this powerful tool to your advantage. I will not spend much time talking about the techniques of effective writing or the mechanics of style and grammar. There are literally hundreds of books, classes, and workshops that cover these topics, and I urge you to take advantage of them to develop fully your ability to communicate powerfully in writing.
Communicating in writing: the platinum rule
The act of writing is fundamentally the act of communicating information to someone else. This sounds simple enough, right?
Pick up a technical article in your field. Or, even better, pick up one in a field you don’t know much about. What do you see? Does the author organize his material in an easy-to-follow, logical progression from background through the technology advancement being discussed and then explain the ramifications? Or does she assume you know all the details and jargon of delay-tolerant packet routing protocols and jump right into the details of RFC 1934? Are the sentences grammatically correct, relatively easy to read, and written with standard vocabularies? Or do you get lost in sentences that are a paragraph long? Is she so impressed with her own vocabulary of 5 and 6-syllable words that you feel sure she is writing only to convince you she’s smart?
The platinum rule of the written word is that you aren’t writing for you, you are writing to communicate with the reader. Act accordingly.
Writing in technology—outside of the consumer-level press designed specifically for my mom, generals, ceos, and eighth graders—is riddled with jargon, complex sentence construction, and words seemingly selected only to amuse budding dictionary writers. Why? People who write this way are writing solely to convince other people that they are smart, whether they realize it or not. They are not writing for clarity, to share their ideas with others, or to advance technology. They are not writing to communicate.
How many times have you read something that was too complex to decipher? You might think that person is smart, but you probably wouldn’t turn to her for help in a pinch. At the gut level, you might be too intimidated to approach him for fear of looking stupid. At a more sophisticated level you might be concerned that you wouldn’t understand the explanation and so asking him would be a waste of time anyway.
Now think about the people and places you do go regularly for help, for example, a particular Web site on network configuration or semiconductor chip design. I’m willing to bet that the reason you turn to this resource is that its information is concise, clear, and easy to understand, even when the topic is complex. This is one reason that discussion forums and the Dummies books are so popular. In both cases, information is presented for consumption by regular people. There is no jargon (at least not without definitions), and no complex and fancy grammatical structures to hide meaning. What is there is a single-minded focus on communicating information.
The permanence of the written word
Writing is communication that lasts. If you don’t believe me, Google for the phrase “antiquarian books” or “rare manuscripts.” You’ll see books, codices, manuscripts, scrolls, and tablets going back millennia. White papers are stored for future reference. Progress reports are passed up the chain and stored as a permanent record of accomplishment. Journal articles are entered into vast bibliographical databases to support other research. And e-mails are stored indefinitely on hard drives all over the world. No matter what you are writing, write well the first time, every time.
Obviously you’ll have drafts of work in progress that won’t be your best work, and you may even share this work in draft form with coauthors for early input. When creating their first draft of a document I know many people who sit down and, once the ideas start coming, let them flow unedited, uncensored, and uncorrected. This is a great approach to getting started with your product because it is often easier to edit than create (you can’t correct a blank sheet of paper!). But the first time something goes out of your immediate group, or up the chain in your organization, spend the effort to make it as clean, tight, and clear as possible. Get your first draft done, and the main ideas captured, as quickly as possible if that’s your style, then edit, edit, edit.
“Except e-mail, right?” Nope, that too, and this does mean you.
Most of us spend a lot of time writing and reading e-mail, and most of us have our first experiences in e-mail communicating with our friends. In this respect e-mail sometimes resembles instant messages, and you may treat them interchangeably with regard to form: sentence fragments, abbreviations (LOL, IMHO, AFAIK, and others), inside jokes, obscure references (“it’s only a flesh wound”), and strange vocabulary are part of what has enabled us to convert a formerly rigid medium—the written word—into a powerful mechanism for building and sharing in virtual communities with people we rarely or never see. This is wonderful and amazing.
Once you begin to have professional communications (whether related to your academic career or to life after school), however, these practices are out of place and damage your ability to communicate effectively with others to whom you are not so intimately connected by circumstance, age, and culture. If you are reading this book, the odds are pretty good that you’ve already started your professional life, even if you are still in school or working to complete your training. Now is the time to start breaking these habits of familiarity and informality. I’m not suggesting that you sterilize your e-mail of all things personal and write with the formality you would employ on a final project paper in senior design. What I am suggesting is that you write in complete sentences, with proper usage (spelling, punctuation, and grammar). Spend a little time organizing your thoughts. If you aren’t sure, look up the difference between affect and effect before you hit the send key. In much of the Western world we start e-mailing and texting in elementary school these days. It will probably take you a while to break your bad habits, so start now.
If you really feel that this will cramp your style in a particular social community to which you belong, let me encourage you to separate this community from all your other e-mail transactions. Get one or more e-mail addresses (there are dozens of free Web mail offerings out there). Use one for your informal communications and one for everything else. This will get you in the mindset of having different writing styles for different contexts, and this will serve you well when you need to separate your work e-mail from your personal messaging.
No matter what you write, be accurate and be sensible
I could also say, “be careful.” Writing is communication that lasts. Make sure that what you say is accurate and sensible.
This is obviously true for the documents we think of as “permanent” and we are used to taking care with papers, manuals, and reports. Again, the real problem is communications that we think of as ephemeral; these days, that mostly means electronic communications. The problem is, no electronic communication is truly ephemeral. It is all—or could be anyway—stored somewhere. Electronic communication is also very easily shared with others, and so is particularly vulnerable to being taken out of context.
Even if you are only using e-mail for personal communication right now, my advice is to be careful. Avoid flaming someone in e-mail. If you cannot suppress altogether the urge to give someone a piece of your mind, at least let a couple hours pass between drafting your e-mail and hitting the send key. Reread it and make sure it’s not too harsh after you’ve calmed down a bit. The more important the topic, or the more valuable your relationship with the person on the receiving end, the longer you should consider your flame before sending it. Even better, pick up the phone or walk down to the person’s office and do it in a way that let’s you react to nuance and emotion. It may be that there is more to this story than you think (there usually is, by the way).
For communications where you are representing your organization, avoid nastiness in e-mail altogether. No matter what the situation, you do not want a written record of what you said in the heat of the moment. You will undoubtedly have to give unpleasant news to the people or companies you work with, and some of this news will be delivered most expediently by e-mail. But these e-mails should be reasoned, rational, and stick to the facts. Acting in anger is never wise. Acting in anger and providing a permanent written record of exactly what you said is an open door to more trouble—including legal action—down the road.
When considering whether and what to send in e-mail, I use the billboard rule: would I mind having this message posted on the billboard in the coffee-break room? If so, I use the phone or walk down the hall to visit in person. And remember, as I said earlier, bad news is always better delivered in person.
Tell a story
Another way to say this is “know what you are saying, to whom, and why,” but “tell a story” fits better on a t-shirt, don’t you think?
You might think that this sort of thing goes without saying. If so, you would be stunned by the mountain of technical writing I review in my job that is created apparently totally independently of who is in the audience, what they already know about the topic, what they want from the author, and what the authors want to accomplish with the paper.
Before you start to write, you’ve got to decide what to write about. Your goals and your audience, which we’ll discuss next, will heavily influence the way in which you write. But even before that, you’ll need to know what you’re writing about.
The odds are pretty good that since you’re in the technology business as a scientist or engineer you know a lot about at least one topic. So unless you are writing a whole book about that topic, you’re going to have to limit your message to a specific aspect of that topic. And, depending upon the needs, goals, and training of your audience, the approach you take to explaining that aspect will vary. Remember that you are writing to communicate, not to produce 3 inches of documentation or to astound your audience with your perspicacity. In order to convey your message to your audience, you have to meet them on their terms and present your concepts in ways that they can easily understand and internalize. If you cannot or will not do this, then you are wasting everyone’s time, including your own.
Your goals
Much of the writing you’ll do in your technical career will be for one of three purposes: dissemination, persuasion, and information. There are other areas, such as writing to express personal opinions, but these don’t show up often in the course of your professional writing. There is some overlap between dissemination, persuasion, and information, but the divisions are unique enough to be useful.
As you shape the specific piece of the larger topic you are discussing, you’ll want to consider your goals for the document. Are you trying to share new research results in a technical interchange with peers? Are you trying to convince your reading audience of the merits of a particular technical approach? Are you updating your management chain on project progress?
In this section, we’ll talk about the three goals and how your approach with each may vary.
Writing to disseminate
When you are publishing the results of new research or details of a new product in a technical setting, you are writing to disseminate. Users manuals are dissemination documents, as are technical specifications given to design specialists, white papers that familiarize technical audiences with your technology, and so on. You aren’t trying directly to convince anyone to take a specific action or make a specific decision. In writing for dissemination, you are preparing your audience to apply knowledge, information, facts, or processes that you have developed to their specific purposes. Writing for dissemination is then writing to educate.
Another important form of writing that is primarily educational is the professional publication produced in some settings to demonstrate a substantive contribution by an individual researcher to a specific field. For example, in university settings before a staff member is granted tenure, she has to show a body of technical contributions to her field. This is most often demonstrated by having a certain number of refereed journal publications in science and engineering fields; in the humanities, such as history, it is generally by books. Many government and industrial R&D organizations have similar requirements for career advancement beyond a particular level.
It may at first appear that these publications are less directly tied to a specific goal for your audience, that your goal is to publish enough to advance the next step in your career. If you write from this perspective you are less likely to be successful in communicating the essential concepts to your audience. Review committees for conferences and journals are looking for contributions that advance the state of the field and that clearly articulate the core ideas. In other words, they are looking for contributions that other researchers in the field can use to advance their own research. So while your personal goal may simply be to get another article published, your goal for your audience will be to articulate the benefits of your research, and to possibly persuade them that your approach will allow them to build to the next step in their research.
Writing to persuade
When you are writing to persuade your audience, you are trying to convince them that your idea, product, or solution is the one they should select or act upon. You are really selling your idea to the audience. Not only do you have to give them enough technical information to understand, implement, or act upon your solution, but you also have to convince them of the superiority of your approach over competing approaches.
The kind of information you present to accomplish this last goal will vary widely depending upon your audience. An audience of engineers will likely depend much more heavily on the technical information surrounding your solution. An audience of managers will want to know (probably from the engineers) that the solution is technically sound, but they’ll also want to know whether the technology is in keeping with the budget, and what the past performance and successes with your company and technology have been. An audience of financial managers will want to know what contract vehicles and billing mechanisms your company is prepared to support if your solution is selected.
In writing to persuade, as in almost all writing, you must understand the perspective of your audience. What are their concerns? What issues need to be addressed for them? Answer their questions before they ask them. Make them feel as if you and your solution will fit perfectly into their situation. If possible, talk to people with concerns similar to those of your audience before you start writing to get a firsthand appreciation for their perspective.
Writing to inform
Much of your writing, at least early in your career, will likely be writing to inform. When you are writing to inform, you are creating a document that provides a status or progress report, a new perspective, or an opinion for your audience. For example, project progress reports are information products.
I’ve separated this from writing to disseminate (or educate) mostly because of the different time scales that the written products have. When you write to disseminate, your document is valuable as long as the technology you are describing is relevant; sometimes this is years or decades. When you are writing to inform, your document is only relevant until the information you have presented is consumed. For example, a progress report is only valuable until you produce the next progress report, and it is most valuable right after it’s written because at that time the state of the project is most closely reflected in the report. Each day that goes by after you’ve written the report, you make additional progress, and the relevance of the original report diminishes. The same is true when you are describing the options available for solving a particular problem or the rationale for a specific design decision. Once a choice is made or a design decision approved, the value of the document is reduced (other than as a historical record of how a project progressed over time).
Writing to inform is typically less formal than writing to educate or persuade. You tend to inform those in your immediate sphere of influence: your supervisor or another design group in your company working on a different aspect of a project. These documents tend to be internal, working-level documents. Often they exist only in e-mail form, and may be read only once and discarded.
Remember, however, that while this form of writing may be less formal, the need for accuracy and style is not reduced. These documents reflect your thought processes in making a decision or represent the progress of your group; they are reflections of you and your team. Even though they are less formal than other forms of writing, they too need to be written thoughtfully and executed carefully.
Finally, it is not a given that all documents that inform will be less structured and formal than other kinds of documents. Your company may have a very detailed, formal structure for progress reports that make them highly polished and lengthy. As with all documents you produce for your company or organization, it is important to understand and conform to the expectations of your particular organization.
Your audience
You know what you’re going to write about and you know what you’d like to accomplish. You are all set to disseminate, persuade, or inform with your writing.
Before you start, remember that you are writing to communicate with your readers.
In order to communicate effectively, you need to understand to whom you are talking, and I can prove it. You are likely familiar with Internet Protocol (IP) addresses, those dot-delimited numeric addresses (like 123.45.76.201) that tell the rest of the world exactly where your computer lives on the network so that you can receive e-mail and chat instantly with buddies all over the world. Now, imagine you have to give a 15-second explanation of IP addresses to a friend in business school who is not a computer scientist, but is your age, has used computers, and has tinkered a little bit with the hardware. Sketch out your explanation. Now, imagine explaining the same concept to your mother who is retired from social work and only used a computer for e-mail occasionally at work. When you sketch out your explanation for her and compare it to the one you offered your friend, you’ll see marked differences. Why, and why is this significant?
Being an IT person, I’ve actually done this exercise, more than once. My friend knew the basics of what a network is, the hardware involved, and was comfortable with e-mail and the Web. So my explanation to him centered on computing concepts, leveraging things he already knew. My mom, on the other hand, is not so comfortable with what’s under the hood of her computer and doesn’t really care how any of it works (as long as it does work). I explained IP addresses to her by comparing the numeric address to the postal address of her house, something to which she could easily relate.
The concept in both cases is the same, but it is explained to the two different audiences in two different ways. In each case, the explanation offered built on the perspective and sophistication of the audience and tried to relate the concept being explained to concepts that were already familiar. In this way your audience is led from an understanding of familiar concepts to the new material you are trying to communicate, traversing your explanation as the bridge between old and new.
You should always research your audience (not just your topic!) as much as possible before you begin writing. The degree to which you understand them—what they know, what they want to know, and why they want to know it—determines the degree to which you will be able to craft a document that presents the new information to them in a way that is easy to understand and leads them to take the action that you desire.
What do they know?
The first thing you need to understand about your audience is what they already know about your topic.
Consider that you work for an appliance company in their engineering department, and your team has just finalized new technology that can microwave popcorn from across the room, safely, in half the time of the old way of microwaving in a small, closed appliance. You’ve been asked to help the company explain the new technology to its customers, primarily appliance re-manufacturers and industrial consumers. You target several industry conferences and trade publications for a series of articles about the breakthrough and how it can be deployed in next generation consumer products. In these venues you can be fairly sure that audience members are in your industry and knowledgeable about at least the basics of how the current generation of microwaves work, or they wouldn’t be in a position to be exposed to the very trade-specific venues you’ve targeted for publication. For these audiences you can probably dispense with introductory and background material describing how microwaves work now, and move straight into your approach and the ways it will revolutionize the consumer experience in the future. Your articles are fairly technical, with little of the “basics,” and a fair amount of industry jargon.
You are successful, and your documents generate a buzz in the industry. The consumer-appliance industry licenses your technology, and they begin announcing products based on your team’s designs. Now the consumer press gets interested, and you get a call from the New York Times to provide technical information for a short piece they are doing in their consumer-electronics section of the Sunday edition.
Now who is your audience? You probably can’t assume the reader knows anything about how microwaves currently work, so that’s background you’re going to have to provide. The technical aspects of your design are going to have to be watered down to simple block diagram concepts, and you’ll have to dispense with the industry jargon completely. These changes are necessary because this new audience doesn’t share the technical background of your industry, and in order to communicate with them you have to provide them explicitly with the context and concepts in ways that they can understand.
On the other hand, maybe you shouldn’t talk about how microwaves work at all. It really depends on what your audience is going to do with this information.
What are they going to do with your information?
So, ask yourself: what is the audience going to do with the information I give them? What do they want to do? What do I want them to do?
Let’s say your piece for the Times is in the Technology section. People reading this section are generally interested in how things work, at least at a layman’s level. They don’t just want to know that your new microwave heats stuff up across the room; they want to know how it works and why it’s better. What technological advancement have you wrought to make this possible? And they want to know how your technology changes the way things used to be done. So you’re probably going to want to explain how microwaves work to this audience after all.
On the other hand, consider writing a piece for the Times in the Lifestyle section. What this audience wants to know is how the new technology will change their experience with microwaves. How will it affect their lifestyle? The odds are pretty good here that understanding how microwaves work now is not relevant to how your new technology will impact the consumer, and so you probably won’t explain it. Furthermore, and much to your dismay if you are in technology, you probably won’t even explain how the new technology works. For this audience, folks aren’t trying to figure out how something works so much as they are assessing whether they should buy it, and so you shouldn’t focus at all on the technical details of your solution and why it is better than the others. The Lifestyle reader doesn’t care; don’t waste his time. Focus instead on explaining how the new approach will make his life better, and why he should buy your technology.
Incidentally, while you are answering these questions about what your audience is going to do with the information you’re giving them, you have a great opportunity to tune your content more finely if you are writing a document to persuade rather than to inform. The opportunity is in the difference between the answers to the questions “What do they want to do?” and “What do I want them to do?” If these answers are different, you can use them to highlight the distance you must move your audience and to construct a plan for getting them to where you want them to be.
Becoming outstanding
You’ve finished your document, and your deadline has come. You submit it to your boss, and she’s satisfied with it. Is it your best work? Was it the best product manual you’ve ever seen at your company? Was it the most convincing project proposal you’ve ever read? Was your boss surprised at the quality, or only satisfied that you completed the assignment?
It doesn’t matter whether this is your first document, or your fiftieth, or your hundredth. You can improve what you write. You can have a more dramatic impact on your readers. Read on, and I’ll give you some of my tips for reaching proficiency, and then for moving on from there.
To write well, read
So much of your success as a technical writer hinges on understanding your audience. If you understand their needs and goals you can make sure that your document provides them the information they need, in a form that they can absorb.
A big part of understanding your audience is knowing what they expect from your document, not only with respect to content, but also with respect to style, format, and presentation. Remember that your goal is to communicate with your audience. Communication is most effective when the two parties share a common language, common background, and common style. In verbal communications this equates to speaking English with a Southern accent if you are in the South, but toning down the twang a bit when you head up North. Adjusting in this manner lets the person with whom you are speaking focus only on the content of your words, not on your goofy accent or what it might mean about your questionable character. Having the same language and accent creates between the two parties an instant communication bridge, and you can move more rapidly to the heart of the matters at hand.
On the other hand, if you don’t share a common language and accent, you’ll have to spend more of your time interacting with the person to build the communications bridge. More time will be spent in small talk so that you can both be sure you are able to understand one another before you move on to more serious matters.
In written communication you want to assure your audience that you share their language, experiences, and accent. You are part of their clan. In doing this you take advantage of the instant communication bridge, and you allow them to focus quickly on the content of your document. The way you accomplish this is to write in the style and format your audience is expecting from you. This will provide immediate assurance to your reader that you are part of the organization, you know what’s expected, and you can be trusted.
Many organizations, especially large ones, have style guides for their documents. These guides are often specialized by the type of document being written (manual, proposal, etc.), and are probably available on your intranet. Get them, and read them.
After you’ve read them, or if your organization doesn’t have style guides, read everything you can that’s been written in your organization. Reports, manuals, proposals, everything you can get your hands on. Notice the differences between them. Do they use first or third person? Future or past tense? Do they capitalize gigaflops or keep it lowercase? Is there a title page? Do authors list their full first name or only an initial? Is the voice formal or casual? Also notice how the answers to these questions vary with the types of documents you are reading.
This may sound like a lot of work, but it’s very manageable. Odds are you aren’t going to be writing every day; you’ll probably usually be working on the things that you’ll write about only once a month (or even less often). Make a commitment to yourself to read one document a week. Print it out and take it home to read before bed or with your Cheerios in the morning. Nothing can take the place of this kind of immersion in the style of your organization. Even reading the style guides won’t make it live for you; you need to heart-learn this stuff, and you do that by exposing yourself to it as much as possible.
Once you’ve got the style down and understand what the existing body of work in your organization looks like, adopt that style as your own, but adapt it as necessary. Take advantage of the instant communication bridge to reach past your audience’s defenses and make your message their own.
Rules are meant to be broken
That said, rules are meant to be broken. Regarding writing, you should always be sure when you aren’t following the rules of convention of your organization that you are actually breaking them, as in intentionally, not just ignoring them out of ignorance.
You can break the familiarity rule in writing intentionally and with powerful effect. If what you are writing about is different—perhaps radically different—from the norm, you may want your style and format to reflect that difference. You can use these elements to say to your readers even before they open your document that what’s between the covers is different and powerful, something to which they’ll want to pay great attention.
You can do this in small ways, such as with color or choice and layout of type on the page. For example, if you work for a financial company that is trying to attract a new clientele for its electronic services you might choose to write your technology proposal in a sans serif font with more vibrant colors in the report to contrast with the staid colors and serifed fonts of their usual internal documents.
You can also do this in big ways, such as by preparing an all-electronic multimedia document rather than a paper artifact.
No matter what you do though, in general you don’t want to torment the rules, just bend them gently. You probably wouldn’t ever want to depart from standard usage and punctuation rules, for example, in a technical document (e. e. cummings was successful, but he didn’t work in the documentation department at Celera Genomics). And remember that your goal is to communicate, so don’t get so absorbed in being new and different that you leave your audience confused and suspicious.
In general depart from the norm only infrequently, when it really matters, and only after you’ve demonstrated a clear command of the usual way of doing things.
Eschew obfuscation
We talked about this earlier, but it bears repeating here: be clear. Remember your purpose is to communicate. You want to inform, persuade, or educate about a topic. Whatever your topic is, I’ll bet that you are most definitely being paid to write to convince someone that you are smart. If someone reads your writing and their only comment is “Wow, you are smart. I had to look up half the words you used,” throw it away and start over.
The phrase “eschew obfuscation” is fun to use, because it’s big and fancy and one rarely hears or sees the words. Not everyone uses them. This means not everyone understands them. Avoid making things unnecessarily complex. Don’t “eschew obfuscation” but “avoid making things complex.” Be clear, or don’t bother.
Neatness counts
Here’s a simple rule that I bet you heard in first grade: neatness counts. It’s still true (not running with scissors in your hands is also still solid advice).
Those of you who are engineers, and perhaps the scientists among you, will likely chafe at the notion that an important part of your document isn’t the content. Surely everything else is a distant second? Yes, and no.
No matter how good your work looks, it will fail to achieve your purpose if the content is not excellent. Excellent content, effectively communicated with correct usage is the minimum for entry into the communication club. However, these things by themselves are not enough to ensure that your message is received with the full impact you intend. The package—the way in which you present your content—is important. Here’s why.
First, you are going to be sharing your product with one or more people who will review your work. The bigger the final audience for your document, the more people there are to review what you’ve written. It is in the nature of these people to make comments; this is what they do. Some of them will be useful, constructive comments that will improve the quality of your work and the effectiveness of the message. These are the comments you want (even if you don’t realize it; this is a fantastic learning opportunity, so swallow your pride and listen to these comments).
But a bunch of comments will simply be the reviewers imposing their style preferences upon your product. You can’t stop these comments, and depending upon who makes them (and where they are in your management chain) you may not even be able to ignore them. You can, however, create an environment that minimizes opportunities for these kinds of comments to be made. The way you do this is you play on the unconscious. People are less likely to make comments that they consider optional on a document that appears polished and finished already. Unconsciously they are getting the message that this is a finished product, and any changes they suggest will be difficult to implement and therefore should be substantive. They also are likely to feel that a great deal of effort has already been invested in the work they are reviewing, and so are less likely to invest a lot of time themselves, giving it a less thorough review because it “obviously doesn’t need much help.”
Never hand a first draft to your reviewers. Edit the text, make sure as much as you can that before anyone reviews your work it is as finished and polished as possible. The document should be set with proper fonts and margins, endnotes and footnotes (preferably footnotes: nobody likes to go flipping back and forth between endnotes and the main text), figures, tables, contents, introduction, and index, and a cover page (if appropriate). You’re going to have to invest this effort eventually anyway before it goes out for printing. If you do it up front you’ll be contributing to the “completed” quality of your document and helping to ensure that any comments you do get are likely to improve your document substantively.
You get another benefit here as well. If you invest the effort in formatting and selecting fonts early when you don’t have a lot of text already in the document then you can spend some time thinking about the logical use of layout, margins, and fonts for headings and body text. After a couple of times doing this, you’ll settle into what will become a nice template that you can create in your word processing program that will automatically handle these details for you, saving you time and effort in the future. There are dozens of great books on typographic design and page layout; pick up a couple beginner-level books to get a flavor for what to think about. If you are ever ready to advance further in this fascinating field of study, I heartily recommend Robert Bringhurst’s The Elements of Typographic Style, 3rd edition, Point Roberts, Washington: Hartley & Marks Publishers.
The second substantial benefit is to your career potential. For a moment, imagine yourself leading a group of several hundred technologists. You are reviewing a document produced by your team that’s heading out to a set of important customers. As the leader of the organization, you are concerned that everything that goes out representing your organization makes your team look as good as you know they are. If something doesn’t look right by the time it gets to you, even if the content is perfect, it’s probably going back for edit. Receiving something that’s ready to go removes this burden from you. It also doesn’t happen routinely, because your technologists cannot seem to learn that neatness counts. But there is a talented young female technologist who routinely sends you A+ quality stuff. Her supervisors have also confirmed that she saves them a lot of time and effort as well. Remember that as leader you are responsible for selecting and preparing the next generation of leaders for your team. This young lady has made the list because she gets the whole picture.
The third reason that neatness counts is that presentation either supports or detracts from your message. Since you get to choose, opt for a presentation that supports your message, one that conveys that you are professional, knowledgeable, and produce work of consistently high caliber. In other words, opt for a polished product. The best technical content in the world is going to be tarnished (at best; at worst it won’t be read at all) when delivered on wrinkled paper, splotched with spelling errors and sporting a ring where you set your Coke® can down on it. Worse, you will be tarnished.
Documents that you author are little pictures of you. Good work is tied to the mental image of your competence that everyone carries around. But so is bad work. Neatness counts.
Get feedback
How do you know whether you are writing well? When your audience understands your points on first reading them and is moved to act in accordance with your goals.
But how will you know when this happens? The odds are pretty good that, early in your career anyway, you won’t have any automatic indicators. Sometimes you will be writing a decision paper, and your decision will be adopted as the company line, and this is a good self-test. But this won’t happen often; more often than not early in your career your writing will not be directly acted upon.
If you are a CEO presenting your company’s future directions at the quarterly earnings call with Wall Street, you’ll have an automatic indicator: the stock price. You’ll know you’ve not been effective when your stock price falls.
But you aren’t influencing stock prices yet! So you’re going to have to solicit feedback. UGH! That’s right, you’re going to have to open yourself up to receive, listen to, and learn from, feedback. Unfortunately we human beings don’t learn a lot from positive feedback. If you do something right the first time then you haven’t learned anything new this time, you simply repeated something you already knew. So what you really want is feedback on the things you did wrong. You want negative criticism.
Here is a real test for the young leader: seek, accept, and act upon criticism in the knowledge that it is making you more effective and that by being more effective you will ultimately serve your team better. Leaders serve those who follow them. This is one of the things that make someone want to follow you in the first place. A leader who doesn’t learn, adapt, and improve his or her service over time will not lead for long. It is a leader’s obligation to improve in order to better serve, protect, and advance the team. It is a leader’s obligation to seek out imperfections in his or her style or knowledge, and correct them. Cling to anyone who will give you honest feedback and constructive criticism. These people will make it possible for you to forge yourself into a polished diamond from a rough one. Do you think that you are already so good that you don’t need criticism? Think about Caruso, probably the greatest tenor in history, who at the height of his career as the star of the Metropolitan Opera conscientiously took voice lessons to improve his singing and acting on stage. If you are a better technologist than Caruso was a singer, maybe you don’t need criticism. Otherwise seek it out and treasure it.
How do you get feedback? There are some obvious choices. Your teammates can be a good source of feedback on the quality of the technical information you are presenting, but they are probably not the best indicator of how effectively you are communicating if they are already familiar with your topic. Your boss, or his boss, can be good sources of useful feedback, as they probably understand less of the technical details and will be able to tell you whether you’ve effectively explained them. Note, however, that here you might run into what I call IAS, or Ignorance Avoidance Syndrome. I have experienced a variety of bosses who perceived it a sign of weakness if anyone ever caught on that they didn’t know every detail of everything everywhere all the time. This is, of course, ridiculous, but if you have one of these bosses you won’t be able to take his feedback without doing some more work first. You’ll have to probe further. Have a casual conversation about this or that aspect of the content of your paper. Test whether he really did understand. Then act on what you find.
You can also turn to your family or significant other to review your work. I find this especially effective when I am writing a mass-market piece about my field. It’s very easy to lose sight of just how specialized the topics in most technology fields are. For example, high performance computing is more than a little arcane to those who aren’t part of our community (yes, that’s nearly everybody!). My mom is smart and very capable, but she doesn’t know much about my field. Early in my career I sometimes tested things I’d written for lay audiences on her. I figured that if I wrote something about high performance computing that my mom could understand, I’d be good to go.
Another excellent way to get feedback and constructive criticism is to publish in your community. Conferences, journals, and trade magazines usually subject submitted material to technical and editorial review before publication. In many cases these reviews are made available to the author for corrections and improvements prior to publication. Study these reviews carefully, for they provide the very interesting perspectives of people who read hundreds of articles in your field every year.
On the other hand, be prepared. Because these people read such a wide range and large volume of work, they often have little time or patience for work they feel isn’t “worth the effort.” Sometimes they are right. But sometimes they are just letting their personal disregard for an otherwise meaningful and exciting topic color their judgment of the quality of your work. Try to discern the difference before you let the crushing weight of their disdain forever discourage you from writing again. You can always do what I do: put a bad review away, and read it again in a month. Then decide what to do.
One of my mentors had an interesting story that he used to cheer me after a particularly scathing reviewer had really let me have it. He was well-published, even when he was a student. During his PhD work he and his advisor submitted a paper to a journal. Their writing received scathing reviews from all three reviewers. They put the paper and reviews in a file and forgot the whole thing. A year later, one of them found and resubmitted the work, unedited, to the same journal. It received excellent reviews and was published without any substantial changes. Sometimes you win, sometimes you lose.
Times, technology, and tastes change, as well as the quality of the reviewers you get in the random draw. Learn from all your reviewers, but don’t take any of it personally. This year’s reject may be next year’s cover story.
Practice makes good enough
We are technologists, not Pulitzer prize-seeking novelists. We are overworked and over caffeinated. We have deadlines on this project and a new project starting next week. In short, we aren’t going for perfect when we write a document.
It is possible to become so involved in the process of trying to make every sentence the perfect vessel for your message that the writing never actually gets done. We usually cannot afford for this to happen. Find a compromise with each work, learning from this document enough to make the next better, but never lingering beyond the time it takes to communicate your message effectively and meet your purposes in your writing.
The best path to good writing is practice. Write every chance you get. If your team has been asked to draft the next project press release, volunteer to do it or to help do it. If the local chapter of your technical society has a newsletter, volunteer to write articles for it. Volunteer to consolidate your team’s input and create the monthly progress report. Write every chance you get, get feedback as often as possible, and learn from each experience.
As a technologist you cannot lead well if you cannot write.
