Ha! Honestly, it depends on the engineer. I’ve met some who sent me cryptic notes that bore a slight resemblance to standard English and some who would put me out of business with the grace of their prose. The primary reason the Education and Outreach team exists is to free up the engineering managers from having to write their own papers or speeches and to translate what the individual element teams do into information that can be shared with the public. It’s not that they can’t, but sometimes they’d prefer not to. And really, NASA (and the managers) would prefer to focus on building/managing the rocket or whatever project they’re assigned to. Call it a more effective division of labor. I would still go into an engineering manager’s office and discuss with them what they want to emphasize in a given paper or talk. What big topics or themes do they want to cover? They still have final say over the finished product, both from a technical and tone/narrative point of view. And I should point out that some engineers do, in fact, write their own papers. When I worked on Ares and then SLS, the Education & Outreach writers were assigned to help the element managers. Individual sub-element engineers were frequently on their own.

What is the writing culture like at NASA? Do people generally look forward to writing up the reports, or do they consider it one of the boring sides of the job? As someone who wants to go into science, and as someone who likes to write, I think I’d enjoy that part of the job.

Again, it varies by person and by topic. During “paper-writing season,” I could end up writing 3-4 papers all saying essentially the same thing, and that gets a little wearing. I would say that reporting on a specific outcome–say, a test, a launch, or a full mission–is infinitely more interesting to the engineering managers than just writing up a status report on what’s going on this week/month/quarter. With a test or mission, you can talk about the data, what went right/wrong, what can be done better in the future, etc. If you’re in the middle of design or development, there are a lot of little things that are happening, but it’s not necessarily the same as producing something concrete…those are all the little baby steps that have to come first. Talking about, say, what the hardware-in-the-loop (HIL) lab will do isn’t as interesting as talking about what the HIL lab is actually doing once it’s built.

Some other less-glamorous parts of space writing are the plans that must be developed for each program: Systems Engineering Management Plan (SEMP), Concept of Operations (CONOPS), Natural Environments Plan, and other documents describe how the team plans to run their organization, how their vehicle/system will operate in the field, or what types of wind environments the vehicle must be able to withstand to operate safely. There are dozens of these reports (Electromagnetic Interference, Electromagnetic Compatibility, Materials Compatibility, I could go on and on), and they all must be accounted for before someone approves a mission for launch. They’re boxes to be checked, but they have to be written so someone can see that yes, indeed, Program X has a plan for handling accidental environmental cleanups or security issues if something like that arises. All of those documents can have multiple authors working on them, and then managers will read them and provide their inputs, requiring revision, and someone has to keep track of all the changes before a document is accepted. All that takes time as well. So while conference papers are one form of writing engineers do, there are a whole lot of others that can take up their time, and then they’re really glad to have a technical writer on hand!