Why the technical writer’s perspective belongs in the room before there’s anything to document.

My mind keeps wandering back to a time when I worked in a highly regulated environment: wind energy and mechanical engineering, where the European Machinery Directive governs almost everything. Documentation there isn’t optional, and yet it still arrives last, and still becomes the bottleneck. I’ve seen the same pattern in every industry since.

The thing that happens at the end

A typical product development process looks like this: requirements, design, prototypes, risk assessment, and conformity work, the paperwork trail that has to add up to a technical file before a machine can carry a CE mark. Somewhere near the end, someone writes the instructions for use, the one document the Machinery Directive names explicitly, required in the language of every country the machine ships to. No instructions, no technical file, no CE (European Conformity) mark, no legal sale. So why does something this essential get treated as if it could wait?

Because that’s exactly when the pressure hits: information arrives late, terminology has drifted, specifications have changed, and everything still has to be written, reviewed, translated, and delivered on a deadline set without any of that in mind. The documentation team looks like the bottleneck. It isn’t the writing that’s slow. It’s the thinking that never happened earlier, now compressed into no time at all (I wrote more about that craft in The strange case of the technical writer).

One turbine, three names

Let’s stay in the wind energy business and take a single wind turbine generator. Depending on who wrote the document, it might be called a “wind turbine,” a “wind turbine generator,” or a “wind power plant.” Engineering specs use the precise term the standards call for, sales uses whatever everyone outside the industry already calls it, and “wind power plant” creeps in too, even though that actually means the whole site, not one machine.

These aren’t three names for the same thing, they’re three different scales: the generating unit, the machine, the site. Nobody sets out to cause the confusion, each term makes sense in its own conversation, but under the Machinery Directive, a single wind turbine generator is the machine that needs the CE mark, not the plant it’s part of. Once that drifts across a project, it stops being a style question and becomes a scoping question with a legal answer, and untangling it after the fact is hard.

Where the real answers were

Some of this became concrete when I traveled to wind turbine construction sites in India and the US. On-site, people had their own shorthand for parts and procedures, and none of it matched the manual I’d helped write. Standing right there, I struggled to understand what they meant.

The regulatory frameworks were different too, and that showed up somewhere very specific: how components were transported. Where regulation was strict, a lot of the how-do-we-do-this-safely questions were already answered by the rules themselves. Where it wasn’t, people had to work it out on their own, every time, because nobody had written it down.

One of the field engineers put it plainly: it would help them enormously to get exact information on how to transport components without damaging them, instead of researching it themselves. That knowledge existed, it just lived somewhere else, while the specifications were written in Germany, and nothing had ever carried it from one place to the other.

The cost of finding out late

In a regulated environment, gaps like these get expensive fast. Instructions get translated into every language of every country the machine ships to, so an inconsistency in the source doesn’t stay a single inconsistency, it multiplies across every translation. At that point it isn’t a manual anymore, it’s a legal document, and a mistranslated scope isn’t an annoyance, it’s a liability question.

Thinking belongs in the design phase, not after it

None of this is really about writing earlier. It’s about the field research, the site visits, the real conversations with engineers and the people who’ll use the instructions, happening while the product is still being designed, not once it’s finished and someone finally sits down to document it.

If the people writing things down are part of that from the start, they arrive at the end with the terminology already settled, a real understanding of the product, and a sense of what the audience actually needs, instead of discovering all three at once, under deadline.

Wind energy makes the case easy to see: the components are enormous, the safety margins are not a minor detail, and assuming a design works exactly as intended without ever standing next to it is a theoretical bet with a very physical downside. But the logic isn’t specific to giant hardware. The same field research is worth doing during the design phase in any industry, whatever the size of the thing being built, so that the people documenting it aren’t still asking basic questions when everyone else wants to ship. That’s what it actually means for technical writing to be part of the product development lifecycle, not a formality tacked onto the end of it.