This can be one of the good ways to get something like a team of 10 (consisting of 5 engineers and 5 non-engineers), to outperform 10 engineers in a culture where they have much less integration with the non-engineering employees.

Some projects are based on a (big?) complex idea of a single outstanding specialized engineer.

If the project or prototype is to be advanced or completed single-handedly, it's essential for that engineer to have enough knowledge & ability, often without very many notes and data, so they could halt the project at any time, then fully produce as detailed documentation as necessary only after the engineering itself is over. At least for that particular milestone. That would be the only time it was finally no longer a moving target.

From that point with hindsight, depending on the degree of thoroughness needed, that top engineer can then justify a period of non-progress while they sit down and focus on fully appropriate documentation for that exact completed or halted project. That would be an engineer who was expected to be an accomplished technical writer already beforehand.

With the knowledge of what this kind of final thorough documentation would look like the whole time, since even before the project got underway, the interim note-taking and essential micro-subdocumentation tasks could be anywhere from truly minimal to almost-publishable as you go along. Depends on how the engineering process is slowed by having the engineer spend more time sitting down producing interim documentation, when real progress might be completely dependent on them not sitting down. Whether or not they are actually running around designing, building, or testing "engines" the entire time they are not remaining seated.

Not every kind of engine is needed for a rocket, but every kind of rocket needs an engine.

But you don't get to the moon single-handedly.

The reason a team is then often formed can be because one engineer is simply not enough for the size of the project, or it can greatly expedite the completion of subengineering components.

The reason to have a dedicated writer is the same reason to have a team to begin with.

For a multi-year project, if you're going to document it thoroughly, the top writer will be working closely with the top engineer for quite a while. Take advantage of that time so a lot of learning takes place in both directions.

Nothing else comes close.

Now there are times when the top writer needs to be the second engineer, so the top engineer can focus only on the engines themselves, and it needs to be accepted that a very capable second engineer will be focused intensively on documentation rather than engines of their own for that period. Ideally final editorial review can be made by an accomplshed technical journalist without the need for the editor to be very familir with that exact engineering discipline. This does require that the second engineer rise to a certain level of journalistic sophistication, probably best if an entire engineering culture can do it.

Very few things are ideal.

In another part of the spectrum, every engineer may have more than one engine and there's no way that's going to be thoroughly documented no matter what. Even if each engineer had their own professional journalist, if the engineers are being streched thin so is the documentation.

This is where the technical writer can feel like a bewildered scribe.

And everything in between.

So I really admire the author's actions to step up to the plate to handle the more difficult situations by improving their actual engineering familiarities & abilities as journalists.

If the top writer is going to be a professional journalist instead of the second engineer, the writer still needs to spend a great deal of time along with the second engineer in the room with the engine. And fundamental questions from the writer need to be answered to good journalistic satisfaction as documentation goes along. If the witer can not be recognized as one of the essential engineering team members in this case, you're not getting your money's worth.

Like it says in the article, it's more than just documentation, it's communication.

And with so many projects the only thing you have to show for it afterward is the paperwork.

So engineers need to step up to the plate to do their share to make better documentation possible to begin with.