I like writing about technology. My first step when writing about tech is to understand the topic. How does this work? Why does it work that way? Who is my audience? Why is this helpful to them? Then, I write so my reader understands. That’s the challenge that I face as a tech writer and it’s one that keeps me constantly learning.

Growing up in the age of the digital revolution, I’ve always welcomed tech as a way of life. It’s not something to be afraid of or shy away from—it’s a set of evolving, useful tools that you can spend your whole life learning about. I believe this mindset is what makes me an effective technical writer. I like to gain a deep understanding so I can communicate well.

I’m endlessly curious about good documentation strategy, docs-as-code architecture, the Diátaxis framework, user analytics, user-centered docs, and tech stacks that improve doc workflows.

Site build

This website is built with Hugo, hosted on GitHub, and deployed via Netlify. I wrote a tutorial on how to build your own site using these platforms.

Documentation process

This is a version of a documentation process that I’ve brought with me through my career:

  1. Review pull requests, design documents, internal documentation, and any initial drafts. Test the feature to understand how it works and how it may interact with other systems.
  2. Research the topic to define the scope and determine what doc type works best. Develop a table of contents or, if I’m ready, a working first draft.
  3. Set up a meeting with the lead engineer and product owner to review my notes and ask for clarification on my understanding.
  4. Write the initial draft. Call out knowledge gaps and any outstanding questions.
  5. Request a technical review from the lead engineer or set up a meeting to synchronously review.
  6. Rewrite and edit the draft, incorporating technical feedback. Collaborate with SMEs to ensure content is accurate.
  7. Edit the draft for structure, grammar, and style according to the in-house style guide.
  8. Send the draft for peer review or wait a day and technical edit myself. Incorporate editorial feedback.
  9. Format the content and publish.

Though I’m always ready to change my method to fit the environment, I’ve found that tech writing is a career where you have to come prepared. If I don’t have much direction, this is how I would get started on a document.

What makes this process good?

  • Start with learning the decisions that went into the development and design.
  • Work with the developers who built the part of the product I’m documenting.
  • Test the feature regularly—my goal is to become a user myself.
  • Involve SMEs such as Engineering, Product, QA, Design, User Research, Content Strategy, and other Technical Writers to gain a wholistic understanding.
  • Draft iteratively to edit, improve, and refine the content. Continually test my instructions to ensure accuracy and to add or remove info.

Want to get in touch?

Send me an email.