Skip to main content

Tools and Systems

I like tools, but I care more about what they let me solve.

A lot of my work sits in the space between writing, structure, process, and maintenance. That means I tend to work across toolchains rather than inside a single authoring environment forever.

Tools I’ve used in meaningful ways​

My background includes work with:

  • Excel
  • Tableau
  • Power BI
  • SharePoint
  • Tridion Docs
  • wiki-based documentation environments
  • Markdown
  • HTML
  • CSS
  • XML
  • DITA
  • GitHub Pages
  • Docusaurus
  • oXygen XML Editor
  • content management systems for help and documentation publishing

How I think about tools​

Tools are part of the documentation system​

Documentation quality is not just about the page someone reads.

It is also shaped by:

  • how the content is authored
  • how it is structured
  • how it is reviewed
  • how it is published
  • how it is tracked
  • how easy it is to maintain over time

That is why I pay attention to systems, not just writing surfaces.

I like practical tool use​

I am not interested in treating tools like trophies.

What matters is whether the tool helps with something real:

  • improving structure
  • reducing duplication
  • making reporting easier
  • supporting consistency
  • simplifying workflow
  • helping teams move faster with less chaos

I’m comfortable learning what the project needs​

Not every project comes with a familiar stack.

I’m comfortable learning enough of the environment to make progress, whether that means:

  • working in structured authoring systems
  • editing config files
  • organizing content in a docs generator
  • using dashboards and spreadsheets to track work
  • cleaning up a publishing workflow
  • figuring out where the friction actually is

I can work effectively in projects that need some build and tooling work​

I am not coming at code like a full-time software engineer, and I do not pretend to.

What I am good at is practical build work in service of a real goal.

That can include:

  • editing site configuration
  • working with Markdown, HTML, CSS, XML, and structured content systems
  • using static site tools like Docusaurus and GitHub Pages
  • iterating on documentation site structure
  • using scripts, templates, or lightweight automation to reduce repetitive work
  • troubleshooting and improving practical workflows

A lot of modern documentation work sits close to tooling. Sometimes the problem is not just the content. It is also the publishing model, the structure, the workflow, the templates, or the friction around maintaining the content. I like being able to work in that space.

Where this has shown up​

In my career, this tools-and-systems mindset has shown up in work like:

  • helping adopt DITA and XML
  • implementing documentation analytics in Tableau
  • streamlining reporting and large-data workflows in Excel
  • working in enterprise documentation systems
  • building and restructuring documentation sites with GitHub Pages and Docusaurus
  • shaping content models that are easier to scale and maintain
  • supporting environments with online help, PDFs, Word-based deliverables, CMS-managed content, GitHub workflows, and monthly build cycles

What matters most​

The point is not that I have touched a lot of tools.

The point is that I can work across writing, systems, workflow problems, and lightweight build work without needing everything handed to me in a perfect package.