Implementing AoRs - Part One: Mapping AoRs

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:

• Step 1: Collect AoRs from your team

• Step 2: Rework your AoRs list

• Step 3: Assign ownership to each AoR

Step 1: Collect AoRs from your team

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:

• Top-down: have every team leader from your organization list their team’s AoRs. The pros here are that you should get a reliable overview of important AoRs - and in the best cases these should already be well scoped too.

• Bottom-up: ask every individual contributor to list the AoRs they are responsible for. This should help you identify AoRs uncovered with the top-down approach and get closer to a comprehensive list. With this approach, however, you will likely end up with less coherent information that you will need to rework.

In both approaches, do not put too much focus on the term AoR yet. Instead, ask the following questions:

• “Which processes do you use at work?”

• “Which tasks are you performing on a recurring basis?”

• “What needs to happen every week? Every month? Etc.”

• “What are you responsible for?”

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.

Step 2: Rework your AoR list

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.

Use a naming convention

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:

• A name

• A short description

Group them into categories

Rework your list of AoRs by grouping them into categories. To keep things simple, you can start with two dimensions:

• Department: each AoRs must fall under one team’s responsibility. For AoRs involving the collaboration between multiple departments, pick the team that should oversee things. You can also break down these cross-department AoRs into multiple ones and assign one to each department involved, but this option will result in more AoRs and more coordination needed. Avoid it when possible.

• Type: here you want to further specify what type of process the AoR relates to. For instance: Team for team and people topics, Planning for planning, goal-setting and budgeting, Reporting for any reporting produced by the team on are regular basis, etc.

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.

Remove duplicates or merge overlapping areas

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.

Assign ownership to each AoR

In this last step, assign ownership. You want to distinguish between owners, deputies and contributors.

For each AoR, aim for:

• A unique owner

• At least one deputy to take things over when the owner can’t

• Depending on the AoR, one or multiple contributors, or no contributor at all.

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:

• Owner: Operations Intern. Creating a weekly Sales report is an AoR with clear scope. Assuming that a standard has already been established - what is the report format, when is it created each week, where and with whom is it shared, etc. - a junior profile can be the owner of this AoR, in this case an Operations Intern.

• Deputy: CRM Manager. The company’s CRM manager, who initially created this report before handing it over, acts as deputy and will create the report if the intern is sick or absent. This person also interacts with the Operations Intern regarding any potential changes to be made to the report.

• Contributors: none. The AoR should be sufficiently covered with 2 people in this case. No need for additional contributors.

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:

• Owner: Inbound SDR. One person in the Sales team was made Inbound SDR and owned this AoR. Given the volume of leads to process, the owner was personally taking care of every inbound lead.

• Deputy: Outbound SDR. One Outbound SDR was appointed deputy and took over inbound leads whenever the Inbound SDR was not there.

• Contributors: none. All the work was handled by the owner and his deputy.

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:

• Owner: Lead Inbound SDR. One Inbound SDR is owning this AoR - this can be even tied to this person’s job title. In this example, the owner is still actively taking part in the process and qualifying inbound leads. But owning this AoR means this person is first responsible for all contributors performing in this process.

• Deputy: Head of Sales. The owner’s team manager is the deputy supporting the owner in the definition and improvement of the process.

• Contributors: All other Inbound SDRs are contributing to this AoR. Contributors are the ones doing most the work here: they reach out to inbound leads and try to qualify them. They report to the owner, whose role is to ensure that they are performing in this area.

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.

What’s next?

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.

‍