Implementing AoRs - Part One: Mapping AoRs
.webp)
In the previous article we outlined why organizations should implement AoRs. In this piece, we want to cover how to get started with mapping them.
By the end of this three-step process you will have an overview of how responsibilities are shared across your team. The three steps are the following:
In this step you want to get a first picture of what everyone is doing. To get there you can combine a top-down with a bottom-up approach:
In both approaches, do not put too much focus on the term AoR yet. Instead, ask the following questions:
Once defined, AoRs should answer these questions. But if you have not implemented these yet, asking the questions above will help you identify current responsibilities.
Once you have collected everyone’s input, it’s time to rework the list. The goal of this step is to get a comprehensive and coherent list of AoRs for every team in your organization.
A good naming convention will make it easier for anyone to understand what each AoR is about without having to dig into the details. It will also set a standard for upcoming AoRs.
Your naming convention should contain at least:
Rework your list of AoRs by grouping them into categories. To keep things simple, you can start with two dimensions:
Depending on the size and structure of your company, you might need to add other dimensions. For instance, if your company is operating in multiple countries, it might then make sense to add a Country or Office dimension to your AoRs.
Your initial list will likely contain AoRs that are similar or overlapping. Make sure that every item in your final list is unique by removing duplicate AoRs or combining overlapping AoRs into one. If multiple team members reported the same AoR, make sure to keep track of this information for now.
At this stage, your goal should be to avoid having too many AoRs within each team. This should help you visualize large blocks of responsibilities and how they might relate to each other. Large areas of responsibility can always be broken down into multiple ones later, when you dive into each area.
In this last step, assign ownership. You want to distinguish between owners, deputies and contributors.
For each AoR, aim for:
Ownership is where things usually get harder. To help you figure this step out, let’s dive into two examples.
Example 1: AoR without contributors
Let’s assume Sales needs a report on a weekly basis summarizing the past week’s performance. How to assign ownership in this case?
Here is a suggestion:
Example 2: AoR with contributors
In this second case, let’s take an area that scales in volume of work over time: inbound qualifications for a SaaS company.
On the first year, the company got an average of 15 inbounds per week that could all be processed by one person alone. Here is a suggestion for assigning ownership:
On the second year, the company now gets an average of 50 inbounds per week, a volume of work that needs to be handled by multiple people. Here is a how the ownership changes for this AoR:
What changed between year 1 and year 2? The amount of work as outgrown the capacity of one individual, so the owner had to “recruit” contributors.
What remained a constant? One person in the organization is the directly responsible individual (DRI) to make this process work and the people doing it perform. It is up to this person to make it work. The key to defining ownership is keeping this principle in mind: in the end, you want one person to own each topic.
Going through this process won’t be a walk in the park. Defining and scoping AoRs, or assigning ownership will likely spark discussions within your team. But going through the exercise will force them to proactively organize their work processes and take a new perspective on distributing ownership across the whole team.
After completing these steps, you should now have an up-to-date list of all AoRs for each team with ownership clearly defined. It’s time to use your AoRs as a tool to drive performance company-wide.
In the next article we will start with discussing the different levels of documentation for AoRs.