In the previous articles we covered why you should implement AoRs in your organization and went through the steps towards mapping them and distribute ownership across team members. In this article we are going to cover one cornerstone of every AoR: documentation.

But first, let's begin by addressing an obvious concern: no, you won’t need to document everything.

Documentation is always behind

In every organization, documentation is always behind. Documenting can be time-consuming, and in fast-paced environments, it can be difficult to keep up with all the changes and updates.

There are always good reasons to report documenting a topic:

1. Lack of awareness: people may not be aware of the importance of documentation.

2. Lack of time: documenting takes time, time your people may not have to devote to this topic.

3. Lack of motivation: people may not be motivated to document things - as opposed to “doing actual things”.

4. Lack of knowledge: your team may not know how to document effectively, or may lack the knowledge related to the specific area.

5. Fear of change: because documenting may also involve change, people may be resistant to change and may therefore not want to document.

The good news is you don't need to document everything at once. You can go step by step.

Documentation is not admin work. It’s a discovery process

In any area of work, you rarely have everything figured out. The act of documenting is a way of thinking things through and solidifying your understanding of how work is currently done and could be improved.

Treat documentation as a discovery process rather than an activity you perform at the end. Start with a lightweight format, and gradually document things as the need for a clearer process arises.

You can use the following framework for documenting your AoRs. Based on the maturity level of your AoR, you will document more of it:

Let’s examine each level.

Initial: Listing an AoR (~ 1 to 5 minutes)

“Who is taking care of this?”

The act of listing an AoR and assigning an owner is already in itself documenting things. You are communicating to the rest of the organization that this area of responsibility exists - and who owns it.

You shouldn’t need more than 5 minutes for this level - there is therefore no valid excuse for your team to skip this.

Basic: Listing the process steps (~ 5 to 10 minutes)

Is there a basic process in place?

As the owner of an AoR, once you have a basic process in place to manage it, you should add a list of the process steps to the documentation. At this point, it’s enough to just document what you do at a high level and skip the details of how you do it.

This level of documentation is good enough for small AoRs where the owner is the sole contributor and other team members don’t need to take part in it .Once again, it should just take the owner a few minutes to document it.

Defined: Document the process steps (~30 to 60 minutes)

Are the process steps clearly defined?

When the process around the AoR is clearly defined or must be handed over, the owner should document the process steps in detail. For this, the best documentation format are how-to guides.

The how-to guide should go through each of the steps listed previously and explain in detail how to perform these tasks.

See here for examples of well written how-to guides.

The ultimate test to see whether your documentation is good enough at this point? Have someone else go through the process with the documentation as only guide. If the person gets it and can perform the task, you have passed the test.

Managed: Define metrics and SLAs (~30 to 60 minutes)

How is the process working?

For some AoRs you will want to take things further and start measuring and tracking how well your process is carried out. Let’s take here another example for a B2B SaaS company where Account Executives from the Sales department need to hand over newly won clients to Customer Success Managers, so they can take care of their Onboarding process.

This process is a great candidate for operational challenges as it sits between two teams and can quickly get complex if your product offers a wide range of implementation options.

Having someone oversee that this process is carried efficiently is a good start but it might be a good idea to measure and track that this is actually the case, in this example:

• Tracking the time it took AEs on average to hand over won customers to CSMs ensures no customer is waiting too long for their onboarding

• Measuring the percentage of Onboardings CSM rejects gives you an indication of how well AEs prepare their handovers, and a much more concrete basis for discussion should this problem become a recurring issue.

You should only do this for selected AoRs as this requires not only to document more but also to setup tracking and reporting. Not even mentioning the discussions you will have around the metrics to choose to represent performance.

Start small, but start today

Good documentation is key when it comes to implementing AoRs in your organization. The key here is to start small and and approach it as a learning process, and only go into more details for AoRs that your teams need to optimize.

In our upcoming article, we'll explore different strategies for optimizing important AoRs.