Skip to content

Who am I?

TL;DR: I'm Alex 👋 (and the pup is Stevie)

portrait of me with Stevie

I'm a lifelong lover of language, education, and technology, so Technical Writing has been the perfect field for me to stay up to date on the latest technologies while continually honing my writing skills.

In university I studied Medieval European History and worked in the central IT Help Desk. History is a discipline that relies on synthesis of self-created and pre-existing sources, rigorous textual analysis and critique, and collaboration with subject matter experts. Academic writing is technical of a different kind and narrower audience, but the underlying skills overlap with technical writing well.

Working in a Help Desk environment introduced me to the world of enterprise SaaS support, and all the management, SOPs, and documentation overhead that entailed. And I loved it. I dove straight in to the world of ITIL and Agile development, since a surprising number of our tools were built in-house: I couldn't rely on external resources on the internet to write our runbooks and SOPs.

And here I am, over a decade later. Still loving it, and still appreciating this opportunity every day.

How do I work?

I work remotely in the US Pacific timezone and am generally accessible by email or your team's Slack/Teams/Github/Google Workspace in those working hours from 08:00 to 18:00, or for meetings by appointment and 24 hour notice.

However, my availability (including infrequent travel to your office or team, with scheduling and budgetary approval) will vary by the terms of our project and contract.

Though the majority of my clients operate in a "docs-as-code" environment, I have plenty of experience in more traditional CMS environments as well. I pride myself in my flexibility, and am happy to work within the existing confines and preferences of your team.

While the scope of an individual project may vary widely, my work generally follows a straightforward timeline:

Step -1: Establish your desired end-result

Step 0: Prepare access, hosting, and publication

Step 1: Dig in to the weeds of your product/tool/platform and your audience(s)

Step 2: Create Draft 1 of the documentation structure and content

Step 3: Review Draft 1 with you, directly or async

Step 4: Create Draft 2[+] from my revisions based on your feedback

Step 5[+]: Repeat Steps 3 and 4 as needed

Step 6: Go live with Final Draft!

Step 7: Handoff to your team, or transition to "maintenance(1)" for future product updates

  1. "Maintenance" in this case means that I will continue to work on the project for an amount of time, either hourly or on monthly/annual retainer. Specific terms will vary by project and contract.

Device Management Policies

If your team uses Device Management tools (Jamf, Intune, etc) to protect your IP and internal accesses, then please arrange with me for any necessary mobile or laptop devices, as I will not be able to enroll my personally-owned devices.

What are my favorite tools?

Technical writing has introduced me to more tools than I would have ever come across in a single work environment, and I definitely have favorites(1).

  1. These represent my personal preference. Every tool has its pros and cons, and with that understanding I'm happy to work with any tool(s) you wish.

GenAI or Agentic AI

Anthropic (Claude, Claude Code, MCP servers, etc) have served me best as an all-around AI platform.

However, this is an ever-changing environment: I frequently cross-reference and compare Anthropic against OpenAI, Google, and Perplexity models for a given project, especially when a new model is released.

Documentation Hub Hosting

Static-site Generators (SSGs) managed from a Github repo have historically provided me the best balance of minimal overhead, performance, and cost for standing up a docs hub or site.

For a more raw and open-source experience, Materials for MkDocs is my favorite (I use it for this website!).

For a more polished experience, both Mintlify and Docusaurus have impressed me with their well-built platform and nifty features.

For cloud-hosted CMS options, I've worked with MadCap Flare, Document360, Zendesk Guide, Atlassian Confluence, Notion, ServiceNow, and others.

What's my stance on AI tools in the workplace?

AI tools are tools, and so it is tricky to assign a morality or ethics to their existence, as opposed to their usage.

Without getting too much into the philosophical or environmental debate, I endeavor to use whatever cutting-edge tools will make my work more efficient so that we both profit.

However, there are a few guidelines I adhere to:

  • AI usage will be specifically disclosed in writing, either in supporting notes or in my delivery package.
  • All AI-generated content will be edited by me (or another human) personally; nothing will go live without human review.
  • I will anonymize (or otherwise securely protect) any confidential information that may arise in the documentation process which occurs outside of company-owned devices or accounts.
  • I will align my work with a company's existing policy on AI-usage upon explicit request in writing.
    • As necessary, I will provide a complementary guarantee and confirmation of compliance with said policies with my delivery package.

What's my approach to documentation?

There are two axes by which I orient all my documentation projects: user experience and clarity.

By user experience, I mean that each article will have set audience persona(s), and the corresponding content will be tailored to their understanding and skill level. Lay or beginner users will have each step outlined exactly as they would need to execute it, to give them as close to an exact tutorial as possible. Content for advanced users will make certain assumptions with corresponding warnings and resources to fill in those gaps.

A tangential point to user experience is the standardization of inclusive language. My documentation will be accessible, respectful, and with as little bias as possible.

For clarity, I will adhere to industry-standard style guides to ensure that my documentation is straightforward, concise, and as simple as possible. No long monologues (like every online recipe these days), but straight into the technical content the end-user needs.

Architecture Paradigm

Generally, I apply the Diátaxis Method (sometimes called the Divio Method), which breaks down all documentation content into categories by user need and the resulting approach to meet that need:

  1. Tutorials: beginners looking to learn
  2. How-To: users achieving a specific goal
  3. Explanation: users curious for understanding and deeper discussion of a given topic
  4. Reference: users searching for technical descriptions or definitions

The specific labels can change as needed, but the underlying structure will fall into one of these four categories and be written, maintained, and revised accordingly.