How to Write Effectively for Engineering Audiences


This article gives advice on how to overcome challenges that technical communicators often encounter when writing to or for engineers.

Establish best practices

Knowing technical communication best practices, and being able to clearly articulate and justify them, is critical. As an example, a 2006 Aberdeen group report showed that involving a writer in a project in the planning stages results in the highest possible success rate for project documentation.

This is because when a technical communicator is involved early, they have the best possible grasp of project needs and goals, and can arrange the content in a way that helps to achieve those goals. Knowing that best practice, and the reasoning behind it, will help you get involved in client projects early, thus ensuring the best result for both you and them.

As with all forms of communication, conducting adequate audience and purpose analysis up front is the single biggest key to success. You must have your questions and process for discovering relevant details down pat. For example, you might be told that you are communicating with engineers. But will non-technical people also wind up using the content you produce? Do you need to take into account the needs and perspectives of administrative personnel, for example? You must be disciplined in going through your process of analysis.

Use advanced tools

The basics of good writing cut across industries and audiences. You need to balance the need for sufficiently technical content with the likely literacy level of your audience, be it engineers, support personnel, or others. Microsoft Word offers a handy tool for diagnosing the reading level of any sentence or document. You can use those statistics to justify a revamp of needlessly convoluted text, or to support your choice of clear wording in your content.

Engineers are often attached to particular conventions of communication, even if those conventions are not optimal. Of course, you shouldn’t try to shock an engineering audience in order to move them towards a better communication technique. But you should be ready to advocate for better methods of communication when the time comes.

For example, the assertion-evidence method of creating presentations is generally a more effective way to convey your ideas than the typical PowerPoint structure. You probably can’t convince the president of an engineering firm to switch to that method when preparing for a presentation at a major conference, at least not right away. But perhaps you can expose him to the benefits of the assertion-evidence method by using it in some of your internal presentations.

Avoid pitfalls

Many engineers tend to focus on features instead of benefits. You have to focus the writing on the important needs that the tool or technology meets, and include only the feature content that relates to those needs. Some engineers (though certainly not all) might explain the need as “they have a need for our product”, but that is too general a statement to be helpful.

In addition to the pitfall that is posed by a too-great focus on features, individual word choices can trip up engineering content. Lohfield Consulting provides a list of words that damage proposals. Many of the items in their list impact writing for engineering audiences, including:

  • Crutch words: Saying “We understand your requirements” instead of proving HOW you understand their requirements.
  • Boasting words: When you say the technology is best-in-class, what does that mean? It’s more effective to talk about the specific benefits of the tech.
  • Redundant words: Some engineers may think that, for example, “in close proximity to” sounds smarter than “close to”. But that’s rarely the case.
  • Needlessly long words: Many engineers have a tendency to write to sound smart, rather than to be as clear as possible. You’ll have to find a balance between pushing for clarity and respecting the engineers’ desire for safety through sounding smart.
  • Slang: Using terminology accurately is critical when writing for engineering audiences. But are they throwing in unnecessarily complex terms? And are those terms really understood throughout the industry, or are they only really clear to employees of the company or project you’re writing for?

Learn terms

A comprehensive knowledge of terminology may be overrated, since even within a given industry segment, or within a single company, acronyms and other terms can mean very different things. Still, one must be prepared – don’t go into a meeting without trying to understand the key terms that engineers may use. And set aside time early on in the project to master terms. Even if terminology knowledge is sometimes overrated, it can be the difference between getting one’s foot in the door, and being left in the cold.

Deal with myths

I’ve dealt with some business owners who believe that their content doesn’t need to be clearly written, or even grammatically correct, since they are experts with the subject matter, and their expertise will overcome all issues in the writing. However, the reality is that writing errors and unclear content can completely obscure the message. Eventually, static in the content renders the communication worthless.

You may also have to overcome the myth that technical communication is just writing, or even proofreading. Between design, research, and testing, writing tends to be a minority of what a technical communicator does.

Do you have any advice on writing for engineering audiences? Let us know!

Romance Your Clients

Is there any valid, professional connection between Valentine’s Day and our relationships with our clients? Can we apply some kind of Valentine’s Day principle to how we treat the people we serve? Let’s see if we can make a connection, without getting into anything too awkward …

Fresh eyes

It’s not enough to show that you’re special. You need to show potential clients (and current clients) that you think they’re special. To do that, you’re going to need to spend some time actually thinking about what makes your clients (and the individual employees working for them) unique. Doing so will both guide you in responding to situations that arise with that client, and will provide you with creative opportunities to express your appreciation.

For example, I’ve made it a practice to hand write thank-you notes to clients and colleagues who help me out. I don’t do so just to do it, just to make them feel as if I appreciate them. Artificiality stinks from a mile away. I only write a note when someone has genuinely been helpful to me. Thankfully, I’ve been blessed with clients and compatriots who have generally been very kind and supportive. And so I regularly feel the need to write a note to tell someone why I appreciate them.

This is related to your value proposition (see What makes you special?).

Recovering from heartbreak

In technical communication, I’ve found about half of the practitioners to be good and helpful, and the other half to be unskilled and unproductive. What if you’re seeking to serve a client who has had a bad relationship with a bad technical communicator? How do you help them rebound, in terms of their conception of their business needs?

Fresh eyes

Potential clients need to see that, due to your experience and training, you can bring a valuable new perspective to their project. They know their terminology and niche better than anyone, but you can (hopefully) help them communicate that content clearly to their customers, employees, and regulators.

What makes you special?

What if everyone wants the client, and is pursuing them? How do you stand out?

You have to be able to clearly articulate your value proposition. Can you handle complicated technical content when others can’t? What’s an example? Can you step into an instructional design project that’s behind schedule, and get it back on track while meeting quality goals? You have to be able to tell a compelling, true story of how you did that. And you have to illustrate consistency in that performance. You have to be Mr. or Mrs. Steady.

Any other ideas on attracting clients?

Critiquing an Engineering Technical Writer Want Ad


·   Introduction

·   The bad one

·   The good one


For a while now, I’ve been running across want ads for technical writers in the oil and gas industry. I have noticed some huge problems with how many of the broken want ads are written. I’ve also come across a few gems. I’m going to share one of each type here.

While these problems are present in ads for tech writers across industries, they are most evident in the oil and gas industry.

The bad one

Here are some excerpts from an example of a bad tech writer want ad (email us for the full version):

“… We are currently recruiting for a Technical Writer with an extensive background in oil and gas and/or petrochemical industry. This is for a long term contract opportunity with a fantastic company in Houston. This position is at 4 to 6 months, poss. longer”

We’ll ignore the minor grammar faux pas (I’ve written elsewhere about how technical communicators shouldn’t be too hard on others’ writing mistakes, but should seek to eliminate all of their own). The biggest problems are the focus and the scope of the qualifications here.

What exactly does an “extensive background in oil and gas and/or petrochemical industry” mean? If I have worked on newsletters for 20 years for an upstream oil company, does that mean I’m qualified to write safety manuals for a midstream gas company? When you move from niche to niche in oil and gas, most of the processes and terminology change drastically. There’s really no such thing as a “background in oil and gas,” when you get right down to it. The fields of oil and gas are too broad for that.

“The Technical Writer (Engineering) will write, format, edit, and validate technical documents to generate operation and maintenance manuals according to client and product requirements. 

Under close direction, compile data from various sources to be included in project manuals.

Keep supervisor updated on all current issues pertaining to engineering standards manuals.

Excellent written and verbal communication skills.

Thorough knowledge of products/services.

Advanced PC Skills.”

Wait a second. Is what’s most important that the writer knows about some area of the oil and gas industry, or is it that they can organize technical content, and write well? Is writing just an afterthought? Which products/services should they know about? And what are “Advanced PC Skills,” and which ones should the writer have?

Really, what many oil and gas companies want more than anything when they say they want a writer with an extensive background in oil and gas is someone who is willing to write, who knows a particular subset of terminology. They want a terminologist more than a real technical communicator. Is that wise?

Look at this simple graphic:

The red is all the people who know a lot of terminology in a particular area. The blue is the people who know how to write and organize technical content, generally. The purple is the people who know a lot of the terminology in that area, and have the ability to write and organize technical content, too.

Narrowing the candidates down to only those who know a particular set of terminology makes the graphic look more like this:

So what happens? There is almost no chance that the company will hire someone who will do a good job of writing and organizing the content. So the company comes to believe that there’s not much to be said for technical communication. They might as well just hire someone who will write, and make sure they know the terminology. And so the cycle continues.

How do you break that cycle? Check out the following ad.

The good one

Here are excerpts from a far superior ad, from a company that works with oil and gas companies. (Email us for the full version.)

“Technical writing company seeks energetic, enthusiastic, flexible

employees for immediate employment. 

Must have a great attitude and good command of the English language (to

do editing and/or writing of technical documents).”

So I know something about the company culture, and I know what my key role will be.

“Sr. Writer revises or originates technical content according to client

requirements using resources provided by the client. The writer may work

on the client site or in our office. Skills used regularly are 1) target

audience assessment 2) content assessment 3) consulting with client on

document design 4) content organization 5) document formatting 6)

document editing.”

Aha. So it’s saying that my key ability on the job will be to be able to take the right technical content and make it work for the right people. This isn’t talking about a hack who knows some terms. This is an expert in their field.

“Must be an advanced user of MS Word and skilled in the application of

templates and styles. Must be proficient with Adobe Acrobat

Professional. Advanced proficiency preferred with PowerPoint, Excel, and

Visio. “

Again, this is specific. I know exactly which software packages I need to be familiar with before I apply here.


– 4 – 6 years’ technical writing experience with an emphasis on

procedural writing

– Bachelor’s degree or equivalent experience

– Oil and gas experience is a plus

– Supervisory experience is also a plus”

Again, very specific. And “oil and gas experience” is a valid qualification, even if it shouldn’t be the primary concern. Why? Not because it actually helps you much when it comes to writing and organizing the content. But because prestige is very important throughout the oil industry and the gas industry. And being able to say “I have oil and gas experience” can help get your foot in the door at many companies, even if won’t make you more competent.

And I do have oil and gas experience.