Analytical Writing for Science and Technology
Copyright © 1996 by T. M. Georges.

Lesson 22

How to Use Feedback to Simplify Approvals -- And Cut Back on Rewrites


In this Lesson:

In this lesson, I'll show you how you can find out more about what your readers want by a simple strategy -- ask them.

If someone misinterprets your carefully thought-out scientific paper, your first reaction might be, "What's wrong with him?" But the effect you intended is irrelevant if the effect you produced was entirely different.

The most important thing about any communication is the response it gets. Not the meaning or effect you intend, but the actual response produced.

To find out what responses you're getting, you need feedback.

Many writers regard no feedback as the most desirable outcome of their writing. If no one gripes about their reports and papers, they assume that their writing has been successful. No news is good news. Everyone has certain routine writing chores that they approach in this way, but if you maintain this kind of isolation in your important writing, you're sure to miss the target more often than you hit it.

Getting advance feedback from your readers is, of course, much easier if your readers are accessible. If you're writing a report to the management of your own organization, you can actually talk to them and find out what they're looking for. (Yes, you really can!). This will usually save you (and them) lots of time and trouble. Try it and see!

If some of your readers are not directly accessible, you can ask yourself questions that anticipate their responses.


If your writing requires approvals up the chain of command, you probably find yourself rewriting a lot of your reports, memos and papers many times, juggling conflicting views, and feeling very frustrated in the process. Many scientists, engineers and businessmen play a guessing game with their writing. First, they guess what their audience wants and what will get approved. Then they run it through the system, and see who knocks it down. Next, they guess and try again. In spite of its frustration and waste, people still deal with the approval process in this inefficient way. Is there an easier way?

Suppose you knew in advance what everyone who had to approve your writing wanted and expected to see in it. Wouldn't your job be easier? And suppose that everyone who had to review your document saw what they wanted the first time around? Wouldn't you appear more competent in their eyes?

Why not start out your writing assignment by making a list of everyone who has to approve it? Then after you make your outline, go to each one and ask for his opinions about what needs to be in you document, what his particular concerns are, and so forth. If you use their time efficiently, most people will appreciate being consulted in advance, and you'll probably get some valuable ideas, too.

There may be some implied taboos in your organization against going in and talking to the boss's boss or someone who runs another department. (Some people get upset when they're left out of the chain of command). If so, you can always set up a conference, offering to include anyone who might feel left out. They may decline, but at least you asked them! Then they won't feel left out.

If you have a large, important document to prepare, you should definitely call report-planning conferences that get together all the people involved at the same time. Because meetings are notorious time-wasters, you have to keep it short and to-the-point. It helps to write an agenda on the board or hand one out, so everyone knows what they're there for.

Begin by stating the overall purpose of the document and get agreement on that first. This is where it's easy to get off the track and into peripheral discussions, so you have to keep the proceedings on target. Point to the agenda as a reminder if the discussion wanders.

Then present your outline and explain how you intend to treat each topic, then ask for feedback. You'll usually get plenty. Write down all the feedback and make sure you take it into account in your new outline and your next draft. A checklist can be useful for noting the comments you get and to make sure you cover everything.

If your document is a major one, you should call several meetings as work proceeds, to make sure you're keeping on-track, that your technical conclusions are sound, and that no one's views are being disregarded. Instead of passing out large drafts of your document (which no one will read anyway), summarize the important issues and how you've handled them. If you have to hand out the whole document, do it the day before the meeting and mark the parts that you want each person's feedback on. Assume that each person will read only the parts you mark.


Inevitably, you'll have to resolve conflicting attitudes and opinions among your supervisors. Your meetings (whether individual or group) will bring out different views about technical details, policy, the audience for your document, and even details about how you word things. Your writing has to take all these views into account.

Sometimes it's useful to present facts and results, but leave out the conclusions. Then ask everyone at the meeting to voice his own conclusions. You might be surprised at the different conclusions each person draws from the same set of facts. Some will be very different from the ones you were going to write, and you may need to incorporate them as well.

Try to avoid fueling open conflict among your supervisors. That will just short-circuit your meeting. Instead, try to identify some positive and constructive aspect of each viewpoint that all can agree on, then suggest a way to add that point to the document.

If someone recognizes a point he made in your next draft, he'll be much more favorably inclined toward the whole document, even if there are other things in it that he may disagree with. You've acknowledged the value of his views, and that's what he's looking for.

Understanding the wants and needs of your supervisors is a vital part of analyzing your audience. They have to approve your report or paper before anyone else can see it. Asking them the right questions at the right time will save you and them the time and frustration of recycling your writing. You'll get your report approved before the final draft is written.


When you're getting information from your supervisors and conducting report-planning conferences, be careful who you ask to read your preliminary drafts. Apart from wasting people's time, your early unpolished drafts can present an unprofessional and sloppy image, especially if your ideas are not yet well formed. Because your writing is often the only way that some people know you, avoid exposing your unfinished reports and papers where they might damage your image.

If you must have someone else look over you drafts, ask a colleague who knows you well. If you don't need technical feedback, show it to an editor or a family member.

But don't underestimate your own ability to edit and criticize your own writing. If you feel too close to it, putting your report or paper aside for a few weeks will make you more objective. Before you pick it up again, try to identify one particular reader you are writing for. Put yourself in his place and read it through his eyes.


When people read your paper, they respond in subtle, usually unconscious ways to every word, every sentence. The sum of these small responses is their total response to your paper. Many of those responses are questions about what you're saying and expectations about what will follow. If those questions are soon answered, and those expectations met, your reader is content. If they aren't met, the response he generates is a kind of low-level anxiety about what he's reading. If your writing repeatedly frustrates his expectations, you have a hostile reader on your hands. That's one response you want to avoid.

By learning to anticipate the most common stimulus-response patterns, you can read your own paper through the eyes of another and see where you may be making too big a logical jump or forgetting to answer obvious questions.

Here is a list of some specific responses you can expect from most of your readers:


One of the first questions your readers expect answered is "Why are you doing this?" Quickly establish the purpose or rationale behind the work you're reporting.

When the title of your paper or a section promises certain information, your reader will be looking for it pretty soon thereafter.

Whenever you raise a question in your writing, your reader will expect you to answer it soon, or at least explain how it can be answered.

Whenever you pose a problem, he expects some kind of solution or at least some explanation why no solution is forthcoming.

Whenever you mention one element of a cause-effect pair, your reader will expect you to mention the other element.

If you make some kind of general statement, it is reasonable to expect you to give some specific examples.

When you present a lot of data, your reader will expect you to analyze and interpret it.

If you take your reader through a complicated analysis, such as a mathematical development, you will be expected to provide a summary that tells what it all means.

Most readers expect you to answer the question "SO WHAT?" at the end of your paper.

If you have trouble asking yourself all these questions while you're writing your first draft, you may find it easier during editing.

Go through the list of expectations above and "trouble-shoot" a report or paper you have already written. Mark those places where you may have left some of your reader's questions unanswered.


Today's high-technology products make clear documentation imperative. You might be able to blunder through some muddled instructions for putting your kid's Christmas bike together, but your new business computer is just an oversized doorstop without clear, complete user manuals. In the exploding software market, the choice between competing products might easily be made on the basis of one manufacturer's reputation for clear manuals.

So why are most user manuals such a disgrace? Because most product documentation is done backwards.

Consider, as an example, how a word-processing program might be developed. A company decides to get into the word-processing business and gives its software design team a broad set of specifications that the finished product must satisfy. Perhaps they look around at other programs on the market to see what features they have, think of a few refinements, and assign the programming tasks.

When the programming is nearly finished, management decides it's time to write the user manual -- all programs have user manuals -- so they give the job to a documentation team, or perhaps contract the job out to a documentation specialist. The marketing department has decided the product has to be on the market in three months, so that's the deadline for finishing the documentation.

The poor documentation team (whose degrees are in English literature) works furiously to translate the design team's intentions into something a typist can understand. They have trouble because many features of the program were designed for the convenience of the programmers, not the users. What they end up with is a catalog of commands that tells the user how to get the program to do what the designers had in mind. Then the advertising department stamps USER-FRIENDLY on the cover and out it goes.

Many user manuals, for all kinds of products, are actually written that way. Is there a better way? Let's see.

What might happen if the user manual were written before the design team began to work on the program? Suppose our company hired a team of experienced word-processor operators. The team would sit down together and decide what's wrong with existing word-processing programs and what new features they want. Then they would proceed to specify exactly how it would function -- from the users' point of view. They would specify what every display and every message would look like on the screen, and what every command would do. Then they would write the first draft of the user manual -- in language they understand.

This draft of the user manual would be the design specification the programmers would work from. Their job is to create the program that the manual was written for.

Naturally, a few compromises and modifications are necessary, because of engineering limitations and new ideas that come up during the design, but the final version of the user manual will just be a cleaned-up version of that first design draft.

Clear, effective user manuals require so much feedback from their intended users, that you should get them involved fully, not only in the document design, but also in the early stages of designing the product itself. Not every product can be completely designed by its users, but paying more attention to their needs will solve many of your documentation problems as well.


Sooner or later, you'll have to break some bad news, report some negative results or state an unpopular viewpoint in your writing. Even competent and intelligent people get negative or disappointing answers in their investigations or have some unpopular axe to grind.

Many books show you how to soften the blow and hide the bad news, so your reader doesn't get hit with it all at once. My advice is: Don't hedge or beat around the bush. State the result or viewpoint honestly, completely and straightforwardly. Then turn the negative result into an opportunity for further work. What now has to be done differently as a result? Focus on the positive result you want, and what the negative result implies about how to attain the desired outcome. Explain what you learned from the experience. Present an image of optimism and confidence. Avoid apologies and excuses.

Here's an example of a short, no-nonsense corporate financial report with some negative results:

FIRST THE BAD NEWS: Our profits will be down in 1990 after two record-setting years. The recession is one of the reasons why.

NOW THE GOOD NEWS: The other reason is we're giving up some of our earnings to invest more heavily in future growth.

We could add more than $2 a share to 1990 earnings just by holding research and development in oil and gas exploration spending to 1989 levels. But we're not going to do that. We're going to spend more on research and development than ever before. About $200 million. 32% more than last year. We're also increasing our capital spending to about $700 million. Up from about $609 million in 1989. And we've budgeted almost $3 billion for oil and gas exploration and development over then next five years.

The way we figure it, the choices we're making now are going to pay off later. In the next decade, we expect our growth to be more and more profitable. Then we'll have nothing to tell you but good news.


The usual approach to a research or engineering project is to first do the work and then write up the results. Do you remember that sequence when you took laboratory courses in school and then had to write the lab report for homework? But how often do you have the experience of writing up your results and, in the process of putting your thoughts down on paper, gaining new insights that you wish you had during the data-collection process? And how often, while writing up your results, do you find yourself rationalizing faulty procedures and apologizing for inadequate care during the data-collection phase?

Usually such insights shed new light on what you were really trying to do. If you had them while you were working on the project, you might have significantly improved the experimental procedure. Because such insights usually come too late, they are sometimes called hindsight. But are they available only after the fact?

What if you began writing your paper at the same time you began the project? Aren't the principles that should guide you in organizing and writing your paper the same principles that you should use in organizing and carrying out your scientific or engineering project?

In both cases, your thoughts should run something like this:

1. How can I concisely define the problem I'm working on?

2. How will I know when I reach my objective?

3. How do I break down this problem into subproblems and questions of manageable size?

4. What specific procedures should I use to solve these subproblems?

5. What purpose will the results ultimately serve?

Many scientists and engineers wait until they've collected mountains of data, and it's time to write up the report, before asking these questions. At this stage, their minds are cluttered with facts, analyses, opinions and biases. They can't sort out the meaningful things to write because they have too much to say. Often they just write everything. The result is usually a paper that says no more than "See my wonderful data!"

If, instead, you consciously and deliberately consider the questions above before the data begin to pour in, you'll not only be better equipped to perform a meaningful experiment, but you'll be half done organizing your report.

These days, everyone has to submit some kind of plan or proposal before he can begin his project. Unfortunately, such plans are often so cluttered with grandiose promises, flow charts and budget requirements that the basic questions (like the ones listed above) are never addressed.

If you have to write such plans and proposals, why not take the opportunity to begin the kind of thinking and organizing described above? If part of your job is reviewing and processing such proposals, you could do their proponents a favor by insisting that such information be clearly spelled out.

When you begin your research prospectus, write a clear and lucid statement of the rationale, objectives and scope of your project. This statement or prospectus would be an excellent first draft of the introduction for your paper.

While you're studying how far others have gotten on the problem, write your literature review.

Before you actually begin your experiments, write out the detailed procedures you expect to follow. (Typically these are modified beyond recognition in the field, but comparing what you actually did with the original plan might be helpful to others who might later cover the same ground.)

Once you determine how you will analyze the data, prepare the data shells and graphic presentations you expect to use.

You may find it useful to imagine the most optimistic possible outcome of your project and to carry those results (in writing) through all their logical consequences and implications. What are you expecting others to do about your results? Are those expectations realistic? This sharpens your thinking about where you're going and may stimulate procedural changes. Your paper might well compare the expected outcome with the actual one.

If you set up this kind of continuous feedback between your writing and your project, you'll find that your writing tasks are greatly simplified, and that your project itself flows more smoothly, too. If your project involves many people, they will appreciate being in on the rationale and plans behind it.


If your organization has a staff of editors to clean up your grammar, spelling, punctuation and rhetoric, consider yourself fortunate. Instead of regarding them as just another obstacle for your document to hurdle, use them to make your paper more presentable and free of formal errors.

Many authors resent the red marks that come back on their manuscripts, and so they ignore all but obvious spelling or punctuation errors. But even though editors may not understand the technical details you're writing about, they usually are trained to recognize awkward or inappropriate wording, poor construction and convoluted or ambiguous sentences. Their red marks are signals that your writing is not as clear and readable as it could be. Take their suggestions seriously. They probably know more than you do about clear writing.

Some editors, of course, are overly concerned with enforcing rigid grammatical rules. Others understand that minor rules can be broken in the interests of clarity. Sentence fragments, split infinitives and dangling participles are sometimes the best way to make a point. You, of course, must make the final decision.


Because writing deprives you of direct feedback from your audience, it's a poor way to communicate. You can compensate for that missing feedback by contacting a sample of your audience in person and by learning how to ask yourself the questions they are likely to ask.

Your supervisors are an important part of your audience, because they have to approve what you write. You can save everyone's time by finding out in advance what they're looking for.

The quality of instruction and user manuals is particularly sensitive to feedback from their intended audiences. Such manuals can sometimes serve as design specifcations.

In the train station at Sendai, Japan

-- End of Lesson 22 (the last lesson) --

Beginning of Lesson 22 || Contents || Afterword