I'm Huw, and I have been doing technical writing and documentation engineering for six years, where I have specialised in docs-as-code and documentation pipelines. This approach treats documentation as part of the code base, and makes it slot directly into the existing toolchain. I work with both the content and the tooling: writing, editing, and building the pipeline.
Before starting DocOps Architecture I served as a technical writer at Tern Systems, GraphAware, and Kaptio, working with ATC software, graph analytics, and travel software. Now I'm taking my skillset independent, applying my pipeline-focused approach to clients directly.
Experience
Tern Systems
Created a self-publishing AsciiDoc-to-PDF pipeline with the aid of the DevOps team. Created templates for engineers to build on for air traffic control software.
GraphAware
Worked with graph and data management software based in Neo4j. Revamped the Swagger API reference site builder, while creating more through AsciiDoc.
Kaptio
Created a self-updating documentation pipeline with Antora. Oversaw mass migration and audit of existing documentation in a Salesforce workplace.
How we would work
01
We arrange a call and identify your documentation needs and current system's weaknesses. I begin analysing which tool I think suits your needs best.
02
An inventory of what exists, both what content is missing, and what is wrong with your current publishing process. You'll get a report showing my decision and why, as well as guides to the new processes I propose.
03
I write up a basic proposal, estimate the timescale, and outline my plan. We decide how to move forward.
04
Decide the documentation structure and set up the repositories in your existing code storage space.
05
Create the pipeline itself, using the CI/CD tools I've decided on. Create processes for updating and reviewing documentation for future publications.
06
I hand over your docs site, process, and supporting documentation (e.g. style guides). I include a guide to the new process I have set out.
07
Decide if I need to remain available for maintenance of the repositories and pipeline. Agree to a timeline and commitment if so.
Email me and let me know the basics of your current documentation issues and needs. We will then line up a call and start making plans.