How to Establish Process Ownership: A Practical Manager’s Guide

Who is responsible for maintaining and updating a process over time?

There comes a time in every manager’s life, when clarification over who is doing what for the process is needed. Dealing with “the process” is such a big word with so many things behind it: all the subprocesses that make up the bigger process, all the procedures, all the process maps, additional documentation, the templates and all the little things that make everything run smoothly. The truth is a process is not something easy to maintain or update in a few steps: it’s a very complex ecosystem with multiple layers to it. Because of this there will always be a need to have people in charge of things, especially when it comes to maintenance and updates.

Most issues that can be traced back to improper procedures or that creep into the process as a result of out-of-date information, can be easily managed by placing a solid, structured and well-established framework for maintenance and updates. But with so many things to consider, what and how should a first-time manager handle this aspect?

To establish clear process ownership, a first-time manager should identify engaged team members as owners, separate process managers from daily executors, and clarify duties using a RACI matrix. Maintain stability by enforcing a Single Source of Truth with strict version control (v1.0, v1.1), scheduling periodic reviews, and empowering owners to make continuous, real-time documentation updates without unnecessary approval bottlenecks.

In this article:

The Process Owner: Defines what a process owner is, distinguishing the expert who maintains process health from the daily executor, and explains how to pitch this responsibility without forcing it on people.
Process Owner Roles and Responsibilities: Breaks down the core daily duties of an owner – such as maintaining documentation, monitoring bottlenecks, and training – while introducing the RACI matrix to keep roles crystal clear.
The Continuous Maintenance Schedule: Outlines structured review cadences (monthly, quarterly, and trigger-based) and audit checklists to shift the team from a reactive “fix it when it breaks” mindset to proactive maintenance.
Version Control: Explains how to eliminate documentation chaos by establishing a Single Source of Truth, clear file-naming rules (major vs. minor updates), and document revision tables.
Implementation and Overcoming Resistance: Offers practical advice on selecting owners using domain interest and growth goals, preventing documentation burnout, and empowering owners to make updates without unnecessary approval bottlenecks.

The Process Owner

Before you start creating files and sending emails to everyone, we need to clearly identify a simple – yet not always easy – concept: what is a process owner?

A process owner is a person with the set of skills and/or experience (or sometimes just because they want to) that can take charge of a specific part of the overall team activity. In this unique role they must regularly check how things are working, what procedures need to be changed or updated, what new information must be shared etc.

Think of them as the best source of information for that specific part of the process: when you have a question about it, you go to the process owner – they are the best possible person to answer it. Because they are a walking knowledge base for their part, process owners also become accountable for how the process runs, performs and evolves. That doesn’t mean they do all the heavy lifting or the tasks that others should.

Having process owners in your team is a great way to let people show initiative, make them be part of the “greater activity”, and provide a great way to let people showcase what they can do or what potential they might have. That said, imposing this position on someone is not a good idea, and a good leader will know how to sell this role to people. Remember: adding additional work that is not part of the job description is always a bad idea.

A lot of people get confused when we talk about Owner and Executor, mostly because they see the first one as both and never really think about the latter. In reality the owner is just the one with the knowledge that keeps the process healthy, while the executor is the one doing the actual work every day.

I saw a lot of issues in multiple teams across the years that come from improper role definition and witnessed first-hand what this can do to teams. In my early days of leadership, observing other more tenured teams and managers, I noticed something very interesting: all the more complicated tasks that people had were usually sent out to one person in the team. When I would ask other leads why they worked like this the answer was always something along the lines of “because they are the only one who knows how to do them”. This really got me thinking about how dangerous it is to place all the special cases, exceptions and more complex things in the hands of one person. On one side you have people feeling important and (maybe) more secure with the job they have, but on the other hand you create a huge imbalance in the team, tons of pressure on one person and open yourself to so many risks. What happens when your “expert” is sick or leaves? What if the volume of work is too much for one person to manage?

Instead of having “the one”, the better practice is to have a clear definition between the person with the know-how and in charge of updates, while the rest execute and do the “business as usual” workflow.

Then we have the other type of teams, where everyone is in charge of everything. This is equally as bad because it simply will not work. You can’t expect 20 people to all be in charge of everything on the process at the same time. What will most likely happen in this case is everyone will assume everyone else is doing it and you end up with no one. People need clear, very well understood structures and rules: expecting humans to move to the next level of existence and higher responsibility is just not real – it looks like that in Star Trek, but this isn’t the United Federation of Planets, it’s real life.

Process Owner Roles and Responsibilities

Now that we understand a bit better what the owner is and what they are not, it’s time to look at clarity: roles and responsibilities. In most cases we will observe this by looking over 2 important layers: the core duties and the RACI.

Core duties are the most important and common activities that an owner must fulfill when they take on the role. Here are the ones you will usually find, but of course feel free to spice things up and amend them for your team when or if it is needed:

Process Documentation: the owner will keep this up to date and accurate. They go over each SOP, check info mailers, look at knowledge base articles and whatever other type of articles you have that describe the work instructions. They are in charge of this, meaning they check, make the changes, communicate and report to the lead. They don’t wait around to receive instructions, they take charge.
Bottlenecks, friction and errors: it’s the owner of the process that must keep a close eye for these things and report on them. The role is not to fix them, it’s to observe and report to the leader. Once your owners start doing the work and taking charge of errors or bottlenecks your whole order is lost. The job is to monitor, nothing else.
Training: every new person in the team, every change in the process and any other similar type of activity will fall under the owner’s responsibilities. They are in charge of teaching people about whatever part of the process they manage.
Feedback gathering: owners must check with their peers and gather as much feedback as they can about how things are doing, how the process is running and anything else relevant.

The RACI Matrix is the other layer we must look at, as this will offer a quick, simple and easy to understand table with what each person is doing. A very underutilized tool, RACI can help out more than you can possibly imagine, because in a few seconds every person in your team can check who is doing what. The idea is simple: list all the activities you have, put all the people from your team and start assigning the responsible, the accountable, the consulted and informed.

The Continuous Maintenance Schedule

With the first, and most important steps now complete, it’s time to look ahead and start planning how to maintain the momentum. Like any other fix we implement, we need to make sure it stays like that, otherwise we end up back at the start. To achieve this with process ownership we must move away from the “fix it when it breaks” mentality and more to the periodic reviews. Simply put, waiting for something to become an issue is a complete waste of time, a huge waste generator and honestly a big source of added stress and pressure on everyone – not to mention the high probability that it can also turn into a potential financial impact (overtime, for example).

To keep things simple and efficient, here are some review mechanisms you could potentially implement in your team:

Monthly spot-checks: For high-risk or high-frequency processes. This will either be when you are dealing with very high volumes of work (in which you need to have at least a monthly check on things – the bigger the volume the more chances you have for something to break, and with a lot of work the impact can be greater), or for very complex processes where the skill level needed and the time invested in one activity is way above “the average”.
Quarterly reviews: For standard day-to-day operations. This one is the most common one and a great way to both create a good engagement with your team but also touch on the ownership aspects.
Trigger-based reviews: Updating procedures immediately whenever a tool, system, or team structure changes. As a general rule, procedures and work instructions should always receive live updates each time they are needed: never wait a number of months to make changes in your instructions just because you have an annual or 6 months-based SOP review and update.

To help you out with some easy checklists for the actual reviews, here are some of the things I found work across the years:

Step-by-Step Accuracy: Are the steps outlined in the document still matching how the team actually executes the work today?
Tool & System Changes: Have any software updates, field changes, or new templates made any part of this process obsolete or redundant?
Bottlenecks & Friction: Did the team encounter recurring errors, delays, or workarounds in this process over the past month?
Link & Resource Audit: Are all referenced templates, forms, scripts, and folder links up to date and accessible?
Ownership & Training: Has a designated Process Owner been assigned, and are new team members trained on this current version?

Version Control

This one is a very easy, yet complex for some, topic!

I saw plenty of teams that had a complete mess when it comes to version control: multiple copies of the same procedure (each with completely different updates and information), no rules on what the file naming convention was, people sending the wrong files left and right, some hoarding the correct ones and only using them themselves, others just following the SOP they specifically have saved. When we don’t have proper frameworks (I know, I use the word a lot) we tend to create unnecessary chaos without even knowing it.

To avoid this mess people need something simple: A Single Source of Truth. You don’t need to have 10 copies of the same SOP, just keep one single copy on a shared drive and encourage people to access it in real time, not to save it – or if they do, to make sure the version is the latest one.

To help people out with understanding what SOP is the latest, you can start using 2 simple things: file naming and version control for your document.

File Naming is very simple: the first file you create will always be version 1.0 (SOP_Order_Entry_v1.0). Notice the “v1.0” at the end as this is the first signal people can look at to correctly assess the status of the file. After your first version all others follow more or less these rules:

Major updates should be with greater numbers, for example: v1.0, v2.0, v3.0, v4.0 etc.
Minor updates should use minor numbers, like: v1.1, v1.2, v2.1, v2.2 etc.

The version control consists (usually) of 2 tables located at the top of the SOP: one with the details about the procedure, and the other with all the modifications and updates done in that document.

Implementation and Overcoming Resistance

It’s all nice and simple when we just write about something, but much harder to implement – not to mention dealing with the natural push-back from people. For this reason, we also need to talk about how to deal with them both.

Picking the right owner is KEY! Don’t be fooled by the fact that you (the leader) can just assign things to people and they will do them purely based on the hierarchy, because this is far from reality. When you need to make a decision on who will be the owner of a specific part of your process a few things are essential to look at: domain interest, development goals and operational involvement.

Domain interest is all about who from your team is actually interested in that specific aspect. Some people will be naturally drawn to whatever part of the process they like most, in which case you need to speculate and take advantage: it’s a great opportunity for both you and that person to “find the right person for the right job”. Putting someone that is not at all interested in doing that is a waste of time: maybe they do an acceptable job, but in the long run you will invest way more time with them than you would with someone that is genuinely interested in it.

Development goals feed into the feedback and coaching sessions you have with your team. Make sure you capture these details in your notes and when the time is right and you can match the interest with the opportunity… do it. Creating a good bridge between development (letting people take charge, showcase what they can do, get more practical experience etc.) and the availability of the ownership gap in your team for whatever activity is the perfect recipe for success.

Operational involvement is the last, yet the most important of the 3. If people don’t want to get involved, regardless of how they feel about the topic or how much it can help with their development, it’s a waste of time. As such you need to use your leader eye and check these things from the start, and not assign ownership to people that are not at all interested in doing the task. Remember: process ownership is not always part of the job description, so you have to be very careful with what and how you are approaching this (unless you actually have it captured in the job description – case in which things are a bit easier).

Now that you have the right people for the job, your responsibility is to do “health” checks regularly, in order to avoid document burnout. The process owners must understand that this task is not about creating endless documentation, but clear and concise documentation (using bullet points, visual flowcharts, or quick videos) rather than long, wordy manuals no one reads. This is why your input and coaching as a manager is needed at every step – people need support and help to on one side not create waste with tons of irrelevant documentation, and on the other side to make content that actually helps, not hinders.

And lastly, empower your process owners to implement improvements without waiting for unnecessary approvals or reviews: if they can make things better, and there is no real need for a manager or customer approval – just do it. Many teams stall by having others review and approve things, instead of just letting people do them: you save time and make the process much more fluid and easy for everyone. What is the actual point of waiting for an approval if in reality it’s really not needed?

Until the next article, stay safe, happy and healthy!