Clients ask me to translate their documents all the time. A tender specification, a contract, a technical manual. The logic makes sense to them: I already work with their team on their English, so why not hand me the German or Dutch version too?

I always say no.

Not because I am not willing to help. But because I am a teacher, not a translator. I studied pedagogy. I did not study translation, and those two jobs are far less similar than they look from the outside. My work helps you improve your own English. A translator's work produces a finished text in another language, to a standard I am not trained or certified to guarantee.

So I invited two translators to my podcast to explain the difference: Anthoinette Međjedović-van Winkoop and Chelsea Janssen. I expected an interesting conversation about a profession most engineers never think about. What I did not expect was how much of their quality system you can use for your own writing.

Most engineers do not realize that you don't need to be a translator to think like one. The habits that make a professional translation reliable are the same habits that make your reports, manuals or emails clearer. Translators work systematically too, and that system is exactly what engineers can learn from translators. You can start using it today.

Translating and interpreting are not the same thing

A lot of native speakers use these words interchangeably.* Non-native speakers often don't even know about the second.

Translation is written. Interpreting is spoken, often live and simultaneous, like the voice you hear over headphones at an international conference. Two different skills, two different kinds of training.

Both aim for accuracy. A good interpreter does not guess at meaning any more than a good translator does. But a translator works on the page, in writing, with more time to sit on the exact meaning of a word, and more documented responsibility for getting it right.

And getting it right matters more than it sounds. In technical documents, a wrong word is not just clumsy. It can be dangerous. Manuals carry warnings, safety steps and operating limits. A translator who guesses is like a surgeon operating with shaky hands: the mistake does not stay on the page, it reaches the person using the machine.

So a translator sits with the source text and asks a narrow, disciplined question: what does this actually mean, and how do I carry that exact meaning across without adding or losing anything? When something is unclear, they default to ask the client.

That habit alone is worth borrowing. When you write a technical email in English, your job is the same as the translator's. Ask yourself what meaning that word carries. And if there is even a slight chance of misunderstanding, choose a different word or add a definition.

The four-eyes principle (and why your emails need it too)

Here is the single most useful idea:

As a certified translation agency, Anthoinette's team works to an ISO standard. At the centre of that standard is something they call the four-eyes principle: no text ever leaves the building after only one person has looked at it. Every translation is done by one qualified linguist, then reviewed by a second. Four eyes, minimum. Sometimes a project manager adds a further quality check on top.

Think about how that compares to how most engineers send their English writing. You type the email, you read it once yourself, you press send. Two eyes. Your own. The same eyes that made the mistake are the eyes checking for it, which is exactly why the mistake survives.

Your brain reads what it meant to write, not what is actually on the screen. This is not a language problem. Native speakers do it too. It is just how attention works.

You will rarely get a second pair of human eyes on a routine email, and asking a colleague to proofread every message would slow you down and look unprofessional. But you can still get closer to four eyes than two. Here are three ways.

The first option: when your company's AI guidelines allow it, a large language model is the closest thing to a second reader you have on demand. Ask it to check your text for inconsistencies and ambiguity, and tell it both your native language and your reader's. That context helps it catch the specific errors most likely to happen between those two languages.

A second option, when you would rather not use an AI tool: become the second reader yourself. Write the email, then do something else for ten minutes. Come back and read it as if someone else wrote it. The gap is what gives you fresh eyes.

A third option: read it out loud. Your ear catches what your eye skips: the missing word, the sentence that does not end, the wrong preposition.

The principle underneath all of these is simple. Important writing deserves more than one check or review. Professional translators build their entire reputation on that rule. You can borrow it for the cost of a few minutes.

Be your own reviewer: build your own quality assessment

When a text is reviewed by a professional translator, they do not skim.* They run a quality assessment: a structured check against specific things. Is the terminology consistent? Does the style match? Does the punctuation follow the source? Do the numbers in the original all appear in the final text? Even the small conversions get checked, like the fact that English uses a full stop for decimals where some languages use a comma.

The reviewer is not looking for a general feeling of "this seems fine." They are working through a list.

This is the habit I most want you to take away, because you can copy it exactly.

I tell my engineering clients a version of this already. You know the mistakes you tend to make. You know you drop the comma. You know you forget the full stop at the end of the sentence. You know you leave the -s off the third person, "he design" instead of "he designs." So write your own checklist, and run through it before a document leaves your desk.*

I used to just call it a checklist. I have a better name for it now: your own quality assessment. Same idea, sharper mindset. Be your own reviewer.

Here is how to build one. Over a week, notice the corrections you get, or the errors you catch yourself. Write down the two or three that keep coming back. That is your list. It will be short, personal, and far more useful than a general grammar guide, because it targets your mistakes, not everyone's.

Then there is the mindset the whole system rests on: translate as if nobody is checking your work, and review as if the translator got it wrong. In other words, take full responsibility when you write, and drop all your assumptions when you check. Expect to find something. That is not pessimism. It is professionalism.

What engineers can learn from translators: time, context and terminology

The things a translator most needs from a client are the same things that make your own writing better. They come down to three: time, context and terminology.

Time. A translation is not something done in the last five minutes of the day. A huge amount of work goes into a website, a manual, a set of specifications, and then translation gets remembered at the end, with the deadline already gone. Rushed language is worse language. The same is true when you write. The document you draft two days before it is due will always beat the one you write an hour before. (I see you, fellow ADHDers.) Give the words time and they get better.

Context. This is the one engineers underestimate most. A translator was once given the single word "service" to translate. On its own, it points to maintenance, servicing a machine. But the source file showed it sitting in a table next to "service brake." Different meaning entirely. Without seeing where the word lived, the translation would have been wrong, and the reader would never have known. Words do not carry meaning on their own. They carry meaning in context. When you write, give your reader the context, and when you hand work to anyone else, a translator, a colleague, a client, give them the surrounding picture, not just the isolated line.

Terminology. Engineers know their field better than any linguist ever will. If you have a list of your key terms, even a rough one in a single language, it is gold. It removes guesswork and keeps the words consistent everywhere they appear. Consistency is not a small thing. When the same part is called the same name every time, the reader trusts the document. When it drifts, they start to wonder if they are reading about one thing or two.

Time, context, terminology. More of each produces more quality at the end. It is true for a professional translation, and it is true for the report you send on Friday.

Work like a translator, without hiring one

None of these habits require a translator. It requires the mindset of one: check your meaning, review with fresh eyes, run your own quality assessment, and give your writing the time, context and terminology it deserves.

That mindset is exactly what I coach engineers to build. If you want help turning these habits into your own reliable system for writing clear, correct English at work, book a free 15-minute discovery call. We will look at where your English is costing you clarity, and what would make the biggest difference.

Frequently asked questions

Language notes

A few phrases in this article are natural for native speakers but worth a quick note if English is your second, third, or fourth language:

interchangeably — used to mean the same thing, as if there were no difference between them.

to skim — to read something quickly and only on the surface, without paying attention to detail.

before a document leaves your desk — before you send it, submit it, or pass it on. "Your desk" here stands for you, the person responsible, not a physical desk.

The last word

Most engineers never think about translators until they need one. But you do not have to hire one to work like one. The habits are simple, they are free, and they turn "I hope this is clear" into "I know this is clear."

That is worth more than it looks. On an international project, the engineer whose writing is easy to trust is the engineer people want to work with.