How to create a documentation system: Assigning roles to your team

The hardest part of documentation is starting the habit of creating documentation. 

The next hardest part is keeping it up-to-date, especially throughout the entire company.

The first step in creating a system to keep documentation in use and updated is creating a personal system to set a good example, test the system works, and communicate the success.

But at a certain point, you will need to involve other people in the documentation efforts. 

At a minimum, there will be users of documentation who utilize the process instructions to perform their jobs or train new team members.

Even if you wish to remain your company's documentation advocate, or Chief Documentation Officer, you will not always be able to complete and update all the company’s documentation yourself. You won’t have the time or knowledge of all the processes. This is especially true if you belong to a company larger than 10 people.

Let’s talk about roles, the different ways people can be involved in your documentation system:

• Using documentation – Users
• Subject matter experts who are interviewed to create documentation
• Creating documentation – Creators
• Editing documentation – Editors
• Approving documentation - Approvers
• Eventually, owners/managers of certain categories of knowledge - Knowledge Owners

The same person may hold more than one of these roles.

As your company's documentation champion, you may hold all the roles.

Click the links above or scroll down to learn more about each role.

Important note:

It’s important to introduce people into the system in a logical way, considering change management. Though this blog describes the roles you can use in your system, look for a future blog about how to convince people to accept those roles and acknowledge the part they play in building a culture of documentation.

Here's a short introduction to the change management needed to introduce these roles:

When you start involving other people, an important thing to remember is that we are trying to “rebrand” documentation as knowledge sharing or enablement.

Position documentation efforts as team members who are helping each other. Documentation helps prevents other team members from repeating the same mistakes, or repeating all the research one person already did to solve a problem.

We are not thinking of documentation as compliance tactics, HR compliance, such as 'do it or they will get fired,' 'do this or else.' 

Ruling with fear will not get you very far in your efforts to convince people to adopt documentation habits,

It will make your culture toxic, which has the long-term effects of making it hard to hire and retain people.

A documentation culture's long-term effects make it easier to hire and retain people... so don't ruin your efforts toward your goals!

The content of this blog is from my workshop and course on documentation, and you can read more about the documentation class topics in this guide.

If you like to take action as you read, I have a documentation systems workbook you can use as you follow along with the post.

I also discussed these concepts in a webinar for Operations Nation on how to set up your company for success by getting the right documentation systems in place.

The First Role: Users

Technically, the first role is yours, the documentation advocate reading this article and hoping for their team members to see the benefits of documentation! Eventually, you will want people other than yourself to use the documentation you create.

If you don’t have consistent users yet:

• Start by asking the people who you think are most likely to use documentation 
  • Make it easy on yourself to get quick wins in documentation adoption. Don't choose people who you know will oppose documentation, during this pilot or beta group of users.
• Communicate with the users about the benefits of documentation, not only communicating that it exists
  • Ideally, you will put measurements in place to document time saved, fewer errors, or the processes being more successful. For example, having a documented sales process resulted in more sales in less time.

Though...any of your documentation communication efforts will also help your team remember that it exists and should be used. Quite simply, if they do not remember it exists, they are not going to use it!

That concept is similar to this example from The Marvelous Mrs. Maisel TV show where the housekeeper, Zelda, creates documentation before she leaves her job. But her employers did not know the book existed, so they kept calling her to ask how to do everything in the house.

Fun fact -- this is similar to one of the first reasons I started creating documentation. I created a book of instructions as I was leaving a job, so the next person could easily take over the job without extra stress on my manager.

When you introduce users into your system, you will also want to create a way for users to give feedback on the documentation:

• • Submitting simple changes or feedback like “this is helpful” or “I don’t understand this part” may be easiest via Slack channel, or another messaging tool 
  • Submitting a form with the changes to be made can be a good first step, if you are able to reduce friction or other barriers to using form submissions

Additional advice about adding users to your system 

• Communicate regularly about what documentation is in progress
  • Make your tasks and wishlist visible so the team knows what’s coming soon
  • Add links, bookmarks, or pinned notes anywhere where people normally ask questions or seek help, such as in Slack channels or project task templates
• Regularly ask for user input for new documentation or improvements
  • Don't position your questions as: ‘Hey, did you read this?’ Position a question seeking their input, such as ‘Hey, I noticed you did something different for this step in the process, was that successful for you? Do you think we should change the documentation?’  This is where they may reveal that they did or did not read the documentation, and you can have a conversation about why.
  • Ask users how they do a process, for their review before finalizing the documentation
  • Make it a habit to ask for their feedback about it when they do something “wrong” or are struggling with something. Ask what they think would be helpful to add to the documentation to make the process easier to understand or complete.
• Celebrate & praise people you see using or talking/writing about documentation
  • Find other champions of documentation so you won't be alone in your excitement to scale your documentation efforts! Having more than one person communicated and excited about documentation will aid in your adoption efforts.

After your pilot or beta users are showing success, you can expand the use of documentation to other teams, using the above methods/system you’ve now tested.

How do you know people are using documentation? 

• If the process is working as expected and you’re getting the results you want 
  • Ideally, you are measuring the process outcome in some way, so you can tell if the process is working correctly. 
• If you get feedback such as questions or edits for the documentation

Signs they may not be using it:

• If the process is not working as expected, if it is not generating the expected results
  • Ideally, you are measuring the process outcome in some way, so you can tell if the process is not working correctly. If that metric is not in the ideal or expect state, investigate if the documentation is being used. Ask people.
• If you’re receiving a lot of questions that are answered in the documentation 
• If you don't get feedback from certain people about it, if there are no questions or potential edits 
• If you ask someone for their input about new or updated documentation and they tell you they didn’t know it existed

Subject matter experts

As you expand documentation beyond your own role or team, you may not have the knowledge needed to create it yourself.

If you’re not ready to enable other documentation creators, or if the person who holds the knowledge is very busy, you can interview the subject matter experts to retrieve the information.

Schedule a call with them to walk you through their process. Record the call so you can transcribe it and cut up the video into useable pieces if needed. Make sure to ask a lot of clarifying questions during the call, to add details to the document.

Then you will write the first draft and ask the subject matter expert to review and edit the document.

Editing is a much smaller and easier ask of someone than starting it from scratch, so you will face less resistance from the people who may not (yet) have documentation in their job description.

An example of this process is at my last role, my CEO needed to document some of her work to delegate to me and to other new roles we were creating. 

But she was busy. As CEOs are.

So I would book a call with her and record the call and have her walk through the process and talk about it while doing it, and I’d stop to ask her questions, 

I could then write that first draft of documentation that she could edit.

Then I would ask another team member to test it, to make sure the documentation steps were clear enough.

Creators and Editors

After you have users involved for a while, perhaps a few months, it’s time to start getting editors and creators involved in documentation.

As discussed earlier, even if you want to remain the Chief Documentation Officer, you may need help to scale your efforts across the company. Enabling other documentation editors and creators will help you encourage more users to adopt documentation, too.

Important note: Make sure you have clear categories in your documentation storage tool before assigning creators and editors. The editors and creators will only be using certain categories, matched to their knowledge and role.

If you’re scared to give people these roles, after all your hard work documenting up-to-date processes, remember:

• Not everyone will have these roles. Some people will still only be users. 
• You can always take away the role from certain people if needed.
• You can usually set permissions in the tool so only certain people can create or edit.

Trusting and empowering people to do this documentation work can do a lot for improving company culture and communication, so don’t be too scared to eventually give up some control of the documents. You can ensure quality standards using the approver roles, discussed below in this article.

Here are a few ways to start using creators and editors:

• Make it easy for them. Be specific in your expectations -- document those role responsibilities 
• Document/Communicate who is an editor or creator, so users know who to go to with questions or feedback
  • This also gives recognition to the people in these roles 
• Add them into your documentation time / task / reminder system, and explain it to them (discussed in the personal system part of the workshop or course)
• When you know they will do a process for the first time, ask if they could draft documentation 
• Start building documentation into any new task or project, as a standard step they need to complete
• Start adding a step for editing documentation into any projects (not just new processes)  
• Have the editor or creator communicate the changes and new documentation they create, to the rest of the team
  • Celebrate them for doing documentation by giving them public praise and recognition
  • A celebration or reward I used was a creating custom emoji of their face in Slack. One way to earn that emoji was by creating or editing their first piece of documentation.

Approvers 

It can be helpful to have approvers of documentation, for the quality control standards for the documentation itself and quality control for the processes the documentation describes.

You, the documentation advocate, will probably be the original approver.

At some point, you may not have time to approve all the documentation being created, or you won't have the subject matter knowledge to approve it. For example, you’re not sure how that department’s manager wants the process to be run.

Then you’ll want to bring in other approvers. This is especially important for approving changes in processes, not just clarifications of the documentation steps.

The approver may be a manager or other leader who isn’t doing as much hands-on documentation. For example, a sales team manager may be the approver of all sales team documentation. Approving is a smaller ask or time commitment than creating and editing, so it will be more likely for them to accept this role.

Having approvers also eases the anxiety of creators/editors who are not yet confident that their work is “correct” enough to share with the team, such as newer team members or people early in their career. Knowing someone else is reviewing it before the team sees it can help them be more confident in creating documentation. 

For the potential difference between approver and owner (the next role discussed), the approver may be the person in charge of creating improvements in processes, while the owner is in charge of making sure those improvements or changes get documented.

Documentation approval process

If you have approvers, or even if you are the only approver, it is very important to have an approval process. This creates consistency in the documentation and quality control.

You need a clear approval process that everyone (in all roles) knows how to find, which tells what to do and what is involved in approval.

You also want to make it easy for approvers to know what to do, to make them more likely to adopt the role. Have a checklist or task list which tells them what to look for in the document.

Another reason this is important is that eventually, the creators/editors may be excited to announce their new or improved documentation, and they may announce it too soon before the approver has seen it. Having an approval process can solve that problem.

My two-level approval process:

• A department manager approves content for subject matter accuracy
• Then a documentation expert (you if you wish) approves for formatting, clear language, naming, linking, ensuring consistency and standardization

Knowledge Owners

The final category of role for your system is a knowledge owner. This person might be all the roles we just talked about, all in one person. These people own certain categories, subcategories, or documents.

For an agency example, a client services manager owns the documentation applicable to all services, at a high level. But a senior team member owns the retainer processes subcategory. And another senior team member owns the project processes subcategory.

What does owning mean?

You will be teaching your complete time/task/communication system to them, for their assigned category of documentation.

You will make sure they have time reserved for this work, and you will provide accountability that it gets completed. If you are not the person's manager, you'll likely need to work with their manager to ensure the knowledge owner is given time and accountability for this important work.

The biggest part of ownership may be the quarterly updates to all the documentation they own, and making sure the most important documentation on their topic exists. (Quarterly updates are discussed in the personal system part of the workshop or course)

Knowledge owners have the most responsibility, so it could take more convincing or rewards to accept this role.

It is likely the final role you will create, because you may need HR and team managers’ help in setting up rewards and allotting time for these people to do the work. This will be tough to do if you aren't already proving success in your documentation efforts by rolling out the other roles first.

At my last company, we had a program lead role, which was one level above the regular strategist/account manager role. Part of their responsibility was being a knowledge owner of a program, a category of documentation. This created a career path to becoming a team lead, and then manager (of people).

It may take a while before you can add documentation duties into job descriptions and promotions, though that is a good example of a reward to aim for!

Timeline

You should not try to introduce all the roles at once, unless you already have a good documentation system and a few of these roles in place! 

Introducing all roles at the same time will be overwhelming and confusing for you and your team members, resulting in less successful adoption of this system.

I recommend taking three months to test and improve your personal system, then introduce these roles in the above order over the next 6 months or more, depending on the size of your company. Larger companies usually require more time for change management compared to smaller companies.

Additional help

You don't have to take your documentation journey alone.

If you're not ready for a course yet: 

Other resources:

• I create a guide for documentation of your processes, which contains many of the course topics
• Addy Osmani had a great Linkedin post and article with a helpful change management framework that shows what happens when you skip a step or component
• Watch a webinar about tool adoption and utilization, if this is one of the challenges you face
• Watch a webinar about change management
• Long article about how a culture of documentation helped Remotish’s hiring & onboarding
• Short article recapping some points about systems and cultures of documentation
• Medium-sized article about Google, Spotify, and Twitter’s culture of technical documentation