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:
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.
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.
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:
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:
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.
Signs they may not be using it:
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.
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:
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.
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.
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.
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.
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!
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.
If you're not ready for a course yet:
Documentation systems workbook -- this is the workbook that accompanies this workshop and the content in this blog. $15