My grandfather worked on the Apollo 11 mission as a contractor with Lockheed Electronics. He was one very small part of a huge operation. But he had a specific, important role, and he filled it with excellence. However, he did have one complaint: He hated documenting his work.

He was and is an outstanding engineer, but his mind works so fast that it’s hard for him to slow down and record what he’s done. Besides, time spent making notes is time spent not working on his project.

Understanding that about my grandfather guided my approach to NASA’s Proposal Writing and Evaluation Experience. I learned three main things.

Take the load off

My team elected me to be project manager in addition to my role as technical writer. I emphasized early on that I was there to make the lives of the scientists and engineers on my team as easy as possible.

What did that look like?

  • I kept up with the deadlines and scheduled milestones to ensure we met them.
  • I took the lead on non-technical tasks, like creating our team slide and organizational chart.
  • I made sure all deliverables were stylistically consistent.
  • I created and compiled citations for all sources.

Most importantly, I fought decision overload at every turn. My technical teammates needed to focus on researching and developing their ideas, reaching out to subject matter experts, and creating their deliverables. They did not need to spend time designing a team logo or creating an organization chart!

Organization chart

This frees us up to work as a team on the things that really matter. It gives technical teammates more time to work on their projects. If I was on my grandfather’s team, I would have done my best to take off the load of documenting his work so he could focus on designing circuits.

(I still would have had to ask him a few questions…)

Get buy-in

What a cliche—but like many cliches, there’s truth to it. Only a couple of my teammates knew what a technical writer was, and few if any had ever worked with one. So, I took that as a chance to explicitly demonstrate the value of technical writers on any team.

How did I do this? Mainly, I just showed up and did the work. All of the little stylistic things that are so annoying to technical teammates are almost second-nature to me: punctuation, citations, consistency, tense, voice, etc.

Of course, they were absolutely able to create citations and ensure good style, but if you’re an engineer, wouldn’t you rather spend time building instead of proofreading?

Jump in early—and really jump in

Earlier, I mentioned I was elected to be my team’s project manager. How?

I had no formal project management background. I did have some experience from Coursera and a rather interesting work experience, but I didn’t even mention this to my teammates.

Instead, I just jumped in being a project manager. I helped set a meeting time and wrote agendas. I kept meetings on topic while making sure everyone’s voice was heard. And I took the load off of my teammates by handling non-tehnical deliverables.

It didn’t mattered that I wasn’t thoroughly qualified. What mattered is I showed my team members I could and would do the work. At the end of the day, that’s what really matters.