Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

Documentation practice
at Canonical

At Canonical, we have embarked on a comprehensive, long-term project to transform documentation. Our aim is to create and maintain documentation product and practice that will represent a standard of excellence. We want documentation to be the best it possibly can be.

Working in documentation at Canonical

We are hiring now for Technical Authors and Senior Technical Authors — individuals at various levels of experience and seniority. They will be placed in multiple different teams to work on software and products of all kinds.

Join the team


Being a Canonical Technical Author

A candidate for a Canonical Technical author role:

  • has and uses programming skills — they might not be an engineer, but programming is amongst the things they can do
  • creates documentation that's part of a product, whether it's a proprietary or open-source, professional or personal
  • engages with the software and the development process as part of their work
  • thinks about and puzzles over the problems of documentation

If that sounds like you — maybe you're ready to join our team.


What is a Technical Author, exactly?

In some software organisations, 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 teams. They are called Technical Authors because they have technical authority: they know their products in depth, and are part of the software development process.

A Technical Author's work shapes the way our products are conceived 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.


In the documentation team

Teodora Mihoc

Technical Author (Juju)

Before joining Canonical, I spent 10 years of my life doing linguistics.

My favourite thing about that was semantics and pragmatics, and my favourite thing about that was building unified theories, in a spirit of amiable free inquiry.

I get the same pleasure in creating new knowledge and systematically, collaboratively, pursuing order in my work as a technical author for Juju at Canonical.

The subject matter is, of course, very different. But in every other way the challenge is delightfully the same: to understand the puzzle; find the solution; and repeat - until it all makes sense in an ever bigger scheme of things.


Daniele Procida

Director of Engineering

I lead Documentation Practice throughout Canonical, from long-term strategy to guiding our activities, processes and objectives along the way.

I get to work closely with a team of talented, thoughtful and disciplined authors, whose own leadership in documentation is helping transform the way the entire organisation thinks about process and the product.

I've been a long-term participant in open-source software projects and communities, notably Python and Django, and in the growing pan-African open-source software movement.

At Canonical, I have the privilege of working in an organisation that itself works right at the heart of open-source software, and is committed to attaining excellence in documentation.


How we hire

We have a rigorous hiring process for Technical Authors. Once your application is processed, you will be invited to complete a written interview, covering numerous aspects of your career, work in and thoughts on documentation and your education. Stages along the way include:


Written interview

The written interview is an important part of the process. It's reviewed - anonymously, in an effort to remove bias - by multiple members of the team.

This has several benefits. One is that in-person interviews are stressful experiences, while a written interview gives you all the time you need to gather your thoughts and put them together in a way that presents you at your best. It's a good opportunity to say things that might not otherwise come up later.

It's also excellent preparation for the interviews that will come. We want to see your best, and for you to be prepared for them. And we want them to be a good experience for you too.

Our written interviews are used by all the future in-person interviewers you'll meet. When you do meet them, they'll already have had a good introduction to you, so that you don't need to repeat the same stories and explanations to multiple people.


Peer interviews

Candidates who progress will face up to three interviews with Technical Author peers, covering:

  • Skills and experience: What have you done? What do you know? What can you do?
  • Insight and understanding: How do you think about documentation and its challenges? What ideas have you formed, about practice, process and product? How deep is your thinking?
  • Culture and value: What drives you and what values underpin your work? How do you collaborate? How will you fit in with our values, and how will you challenge us to do better?

Talent interview

Next is an interview with someone from our Talent Acquisition team, that looks back at your career, discusses how you work and want to work, and considers questions like salary, availability to start and so on.


Technical exercise

Not strictly an interview, but an opportunity to demonstrate your ability to think through and solve documentation problems (and it's not a writing test; we already know you can write). We want to see how you approach issues such as meeting user needs and documentation structure, and your analytical and critical skills.


Documentation lead interview

An interview to confirm our assessments and work out the next steps, based on your interests, skills and experience. This will help us arrange interviews with appropriate hiring managers in different teams.


Hiring manager interviews

By this stage, we'd like to have you as a Technical Author at Canonical, and now it's a question of finding the right team or project for you, where both we and you feel that you'll be excited by the technology and in a strong position to make a valuable contribution.

That is indeed a lot of interviews. It's an in-depth process for an exacting role and we take it very seriously.

Don't forget that you are interviewing us as much as we are interviewing you. We want you to be an active participant in the process, not just someone who answers our questions.

You will spend a large proportion of your life each day at work. We, as much as you, want to be sure that you're in the right place, one where you will be successful, fulfilled and happy.