What is practice leadership?

This is the first in a series of articles on engineering leadership at Canonical

I have a job at Canonical, and three job titles, which is unusual and might seem a bit excessive. 

My job titles appeared at various times on paperwork or internal systems. They’re not mutually exclusive. Each one seems appropriate and helpful in its own way, so I like to keep them around and use them as needed in my work, which is to define and lead Canonical’s documentation efforts.

I am a Director of Engineering. This is the title I actually signed up for when I joined, and it’s the one I lean on most heavily. As an engineering director I’ve been able to command the attention of a lively and opinionated engineering organisation of several hundred people, and elevate the status and execution of documentation in a way that would be much harder if my role were positioned outside engineering.

I am the company’s Head of Documentation. I like being a Head of because there can only be one head of something – there’s no doubt who is in charge of documentation at Canonical.

I am also Canonical’s Practice Lead for Documentation, and I think this one is actually my favourite. I didn’t invent the concept of practice leadership, but I am the first person to do it at Canonical – which means I get to define it.

I have to explain it too, because people often ask: “What is a practice lead?”

Engineering practices

I joined Canonical to transform every aspect of its documentation: output and efforts, what it aims for, what it considers good, how it delivers it, how the organisation thinks about documentation’s purpose and value. 

That was an interesting challenge right away. There was just one of me, and 650 people who needed to become active participants in my project (650 people in 2021; by 2024 Canonical was twice the size).

I needed all those people to understand and accept my ideas. I needed them to accept and internalise the values, standards and priorities that I saw. I needed them to accept and believe in me, especially since I was going to be asking a lot of them. New work, more work, unfamiliar work, new ways of working, new tools – frankly I was going to be quite a nuisance. 

Mostly, software engineering leadership is concerned with leading teams, or leading the development of products. People are familiar with those relationships of leadership. They join a team or they’re assigned to a product, and with that comes a chain of command or some obvious duties – they signed up to accept that.

In my case there wasn’t an engineering team to lead – my team was in effect the whole company. And I wasn’t focused on any particular products. Everyone was going to be affected by my plans, and everyone needed to come along with me. 

My success was going to depend entirely on whether all those people were going to accept documentation as their problem in a way that it had not previously been.

Precedents

The idea that documentation should be pursued as a company-wide practice might be a bit unusual, but it’s not outlandish. For example, security must be part of engineering thinking, that everyone, from a junior to a senior architect, builds into their work. Security can only be delivered successfully if it belongs to everyone as a responsibility. It’s just the same for performance, and other engineering concerns.

Imagine an engineering stance that said: My job is to build the features and deliver them on time! I leave security to the security experts! With very good reason, we would reject the idea that only a security expert should take responsibility for the security of products.

We know perfectly well that security is not something that is bolted on to engineering work after it has been done – it has to be built into it, and it can only become part of the product if security practice is part of engineering practice.

It’s just the same for performance practice, which cannot be successfully bolted-on to work that failed to include it in the first place. 

So there is at least a precedent for the idea of an engineering practice, not associated with any particular product, that has to take hold across an engineering organisation – and that everyone has to accept as their problem.

Elements of a practice

A practice includes standards, against which work can be measured, and which show the direction it must take. There are right and wrong ways of doing security, and documentation, and good and bad outcomes. A practice includes particular ways of executing work. It includes the right tools (in engineering we can become rather fixated on tools, something I prefer to discourage, but all the same, the wrong tools can certainly undermine the success of a practice in an organisation).

The single most important imperative in establishing a practice, though, is to establish its value. 

At Canonical, documentation needed to be accepted, across the organisation, as a first-class engineering discipline. The values of documentation needed to be internalised by engineering teams, embraced as their own. It needed to become as impossible to shrug off the idea of documentation as to shrug off the idea of security, or performance.

When I say “it needed” what I mean is “I needed it” – my project had no chance of success if that didn’t happen. 

So I had four interesting challenges. One was to lead an entire organisation’s worth of teams and individuals, none of whom were in my line of command. Another was to lead and change their practice, a more intangible thing than a product. The third was that documentation wasn’t the core purpose or expertise of any of them.  And finally, what I needed them to do would take them away from other, more firmly established, priorities.

Four years later

Four years later, documentation is indeed firmly established at Canonical, as an engineering priority and practice. 

It works, successfully, and the results of documentation practice are visible in improved documentation. Documentation efforts are co-ordinated and part of a coherent strategy. There is a clear vision of good to guide them; our documentation output is steadily converging on shared models and patterns, quality is measured against standards, and progress is tracked.

The standards themselves are thoroughly articulated and expressed in concrete examples. Product engineering teams understand and use them. There is a deeper technical understanding of documentation principles and problems, and the language used to express them has become more sophisticated.

Teams have a good understanding of what is expected of them, and are signed up to the company’s documentation values. 

Every three months or so, each Canonical engineering team comes on stage to present their plans and progress to the rest of the organisation. When I joined, documentation wasn’t even mentioned in those presentations. Since then it has steadily acquired greater prominence: first mentioned at all, then noted as significant, then noted in detail and with pride. It has climbed up the agenda and now it’s often the first item discussed by a team. Documentation stands alongside other matters – releases, features, reliability – as a first-class engineering concern.

In 2025, Canonical has over 30 technical authors (we have dozens more to hire), each one a member of an engineering team, leading its documentation efforts and driving progress and quality. They are practice experts who help lay down ways of working on documentation.

The model of practice leadership has been developed, and adopted for other domains.

Most recently, Canonical hired a new Head of Community, Sebastian Trzcinski-Clément, to effect a similar transformation in community practice in engineering (for Canonical, an open-source software company, community practice in engineering has the same kind of status as security practice, or performance practice, or indeed documentation practice).

And naturally Sebastian also gets multiple titles: he too is a Practice Lead – for Community – and he too has to do the work of defining that particular practice, and our approach to engineering practice in general.

We continue to develop and expand our notion of engineering practice. Of course it’s not all plain sailing. Alongside the discoveries and successful experiments, there have been a few dead-ends and unrewarding investments. But, we have established some clear and reusable patterns, and demonstrated results. It’s a model we’re building on.

Subsequent articles in this series will explore the idea of engineering practice and the challenges of practice leadership in more detail.  

Canonical leadership practice handbook

Those challenges of practice leadership in engineering are much less familiar than those of product development, or team leadership. It’s not exactly uncharted territory, but it’s certainly less-visited. 

As part of the effort of establishing a repeatable model, I developed an internal manual – the Canonical Practice Leadership Handbook. It was intended for senior engineering leadership, of company-wide concerns, but I discovered that it was also being used at other levels too – by people who needed to bring about a change in practice within a team, amongst peers for example, or people who needed to influence the practice of teams that were not their own and over whom they had no formal authority.

The handbook is accompanied by a short workbook for users, that helps users capture key ideas and values, and think about how to express them as a project that draws in the support of their colleagues.

We’ve been using them at Canonical for some time, and now both have been made public for anyone to use (like our model of engineering practice, they too are being developed and expanded).

Canonical Practice Leadership Handbook

They’ve been useful to me, to clarify to myself what it is I have needed to do, and they have proven valuable to other engineering leaders at Canonical (and indeed to colleagues beyond engineering). I hope that now they might also be useful more widely, to others in our industry who face similar challenges.