In some software organizations, the work of documentation specialists is to produce documentation. They receive explanations and descriptions of software from their engineering colleagues, and turn those into polished output. They are expert technical writers.

Our documentation specialists have a different role. They are technical authors, members of our engineering and teams.

They are called technical authors because they have technical authority. They know their domains in depth, and have much wider influence than a traditional technical writer. For example, in an engineering product team they are part of the software development process.

A technical author’s work shapes the way our products are conceived, designed, and presented. Amongst other things, it’s reflective, critical, active and creative. It’s work that feeds back into the product itself, and helps define what it is, and always seeks new and better ways to add to its value.

Our technical authors come from many backgrounds, including academic research, software engineering and journalism. What they have in common is that they are expert, effective communicators. They share an intense sense of technical curiosity, and a strong feeling for the perspective of a product’s users. Their strength of imagination and qualities of empathy are crucial to their work.

Documentation is something that everyone contributes to; technical authors encourage and lead documentation work, and help guarantee its quality.

We rely on various tools and platforms to build, manage and publish our documentation.

Our product documentation is maintained in Git, built with Sphinx and published by Read the Docs. We have developed and open-sourced a lot of our own Sphinx tooling such as extensions, along with workflows and other machinery to help manage the production of documentation at scale.

We have also developed tools for hosting documentation for other purposes, such as our internal Canonical Reference Library (a CMS, that uses a Google Drive of documents as its backend).

We use Python, Django and Flask; for web frontends we use React, TypeScript and htmx.

We don’t just create tools and applications, we put them into production on our own infrastructure. A documentation platform engineer quickly becomes familiar with Juju and our charming ecosystem.

Sometimes we find a suitable web platform engineer candidate in our technical author hiring pipeline, but the best entry point is our Web Developer advertisement. When you apply, emphasize your Python web skills, and your affinity for documentation.