How to document your business processes

What is documentation?

If you search online for the word 'documentation,' you'll likely see articles about product documentation. Product, or technical, documentation usually describes how a product, usually software, works. It is intended for the customers to use as a form of self-service to answer their own questions.

The type of documentation this article discusses is process documentation, which explains how to complete the processes, the main work activities, in our job or our business.

Other names for this type of documentation include standard operating procedures (SOPs), wikis, how-to guides, instructions, playbooks, knowledge bases, handbooks, business manuals, training manuals, and more.

The GitLab Handbook is one of the most commonly cited examples of publicly-shared documentation.

Dive Deeper

• Read more answers to 'What is documentation?"

 

Why is documentation important?

Business process documentation is important for many reasons. Some of the reasons benefit companies, and some reasons benefit individuals.

A few of the top reasons for companies to invest in documentation include:

1. Profitability! As a result of the following factors
2. Process improvement is possible if the processes are documented. The change management for the improvements is also easier
3. You can save the time that was previously spent fixing errors (documentation helps with quality control) or recreating the wheel
4. Documentation enables clear communication among the team, accountability for completing work, and empowers team members by training them to take on new tasks
5. Documentation helps ensure processes are executed consistently among current team members and after someone leaves the company (the proprietary knowledge doesn't leave with them)

Individual-level benefits of using documentation include:

1. Taking time off without stress
2. Working fewer weekly hours
3. Less worrying about missing steps in the process or making other types of errors
4. More time for proactive, strategic work that may earn a promotion instead of getting stuck in reactive fire-fighting mode (fewer things are breaking, and it's faster to fix them)
5. Saving your creative brain power for more valuable building and improving work instead of using that energy for remembering how to complete repetitive processes

Dive Deeper

• Read more about why documentation is important from several expert contributors.
• Find more answers to leadership's common questions about documentation here.
• For more of the mental health benefits that documentation can provide, see this post.

 

How do you start documenting? Prioritizing

Starting can often be the hardest step for any new habit, process, or routine. Here are three common roadblocks to starting to document your business processes and how to overcome them.

Overwhelm

To overcome overwhelm, start small.

Start by documenting one of your own tasks you repeat often. One example might be documenting a playbook for how to create an agenda for a weekly meeting.

If you experience this roadblock, do NOT start by trying to document something long and complex such as a detailed explanation of your sales process. You'll likely get frustrated and give up if you don't start experiencing any small wins while building your new documentation habit and routine.

Adoption

Are you afraid other people won't adopt and use the documentation, so why would you even start?

If this is your roadblock, you should start documenting where you think the process, person, or team is the most likely to adopt it. For example: Does one of your team members take a lot of notes or always request more details? If so, one of their processes may be a good place to start testing documentation.

Don't start by documenting the processes that will get the most resistance or documenting for the teams that you predict will give you the most resistance. Let's set you up for a better chance at small wins to help you start!

Leadership buy-in

Are you're afraid that leadership won't give support (and time) to their teams for creating and using documentation?

If so, then start your documentation with a process related to current business goals. Choose processes where you can measure the before and after documentation metrics, to show improvements caused by documenting the processes.

For this roadblock, don't start your documentation with something un-measurable, like how to make a custom emoji for Slack. That may not win you any points with the leadership team, who may be expecting measurable results from their team's time.

 

No matter what your roadblock is, don’t overthink it!

If you can't identify you're roadblock, overwhelm is the most common, so choose the 'start small' tactics.

Start taking action to gain some momentum and get unstuck.

 

Dive deeper

• Read more about prioritizing and starting documentation.
• If you're ready to take action, I have a free documentation prioritization template (part 1) below and an additional prioritizing template (part two) here.

 

How do you document each business process? Writing the documents.

A few tips before you start:

• Perfection is the enemy of progress! Don't put too much pressure on yourself for the first draft to look like any finished examples you've seen -- those examples probably had numerous revisions over many years. Embrace the messy first draft! Remember that something is better than nothing.
  
  
• Documentation is never finished, so 'completion' or perfection is not even possible. To be successful, think of it as "living documentation" that is consistently improved and updated as the processes change. 
  
  
• "What software should I use to start documenting?" is a common question or roadblock to starting. For the first draft of writing, use whatever software is easiest for you. Researching the "best" writing or documentation tool is often a form of procrastination.
  • Note that later, you can transfer the writing to another tool if needed, or you can delegate that copying and pasting work. It is more difficult to delegate the work of getting the steps out of your head or your team's heads.
    
    
• If starting with a blank page is terrifying, and/or you find talking easier than writing, you can record yourself talking through the process. Use whatever meeting recording software you have. Then transcribe it into your first written draft of steps, using the built-in transcription or other free tool. Keep it simple!
  • If you're still stuck on starting writing, for software-based processes, there are special tools that can record the steps your mouse is taking onscreen, and some can also transcribe a voiceover. This software includes Guidde, Iorad, Tango, and Scribe -- but don't spend hours researching these before starting any first drafts of documentation!

 

Writing steps

Since the steps of the process are the minimum amount of information necessary for your documentation, I suggest starting documentation by writing instructions for how to complete the steps.

Unless you have a fear or hatred of cooking, a recipe analogy is helpful when thinking about creating step-by-step instructions.

Think about what you do first, second, and third in order to complete your meal or task. Write it down.

Reasons why recipe-thinking can help:

• It helps you break down the process into small, clear, manageable steps
• Thinking about making yourself a meal instead of thinking of how you need to complete a critical work process can relieve some of the pressure you may feel when you are... procrastinating...writing your documentation 
• Thinking of the process as physically assembling something, not clicking around a screen, can help you think of steps you automatically do, which could be steps other people wouldn’t know about 

Tips to write a good recipe / document: 

• Write your steps with the user in mind. Put yourself in the shoes of someone who has never done this before.
• Use a second-person point of view, directing the instructions at "you," not "I do this." Starting each step with a verb can help with this tricky tense. 
• Clarify which person completes the step(s), but don't use people's names. Use a title since people may change roles often.
• No jargon allowed! Don't use words, symbols, or abbreviations people (such as someone new to the company) may not understand. 
• Include context or steps about what triggers the process to start and end. 

User testing the steps of your documentation

An important...step...of writing the steps is having someone else read it and test if they could complete the process using your drafted documentation.

Suggested workflow:

1. Write a messy first draft or brain dump of the steps
2. Complete the process while reading through your documentation, adding or clarifying steps as needed
3. Ask a peer to review it to see if they could complete the process using your documentation 

The reviewer's questions and comments will help you improve the document. Don't wait too long before asking for feedback.

The tester doesn't need to be the person who actually does the task in their job. Someone unfamiliar with this process could better test that your steps are clear enough for training someone new to the process. 

 

To see the importance of user testing the process steps, watch this video of a dad asking his kids to write instructions for making a peanut butter and jelly sandwich. 

 

Structure

Naming

Start your documentation structure by creating a naming format or naming convention for the documents or articles.

People aren't going to use your documentation if they can't find it or if they don't understand the title or name.

Use words and phrases that everyone understands, so they can easily search or navigate to find the documents they need.

Having a naming convention also helps documentation creators overcome procrastination since the name is at the top of the page, where many people start filling out a template. Making the naming process easy prevents one of the first roadblocks in writing the documentation.

Suggested naming format:

Starting the document name with “What is” or “How to” is a helpful constraint.

Think about naming the document as a question people are asking, similar to popular Google searching methods. 

The question format, or the ‘how to’ format, also helps the writer think through what they are trying to teach someone in this document.

Example: How to write documentation for your clients

Example: What is our budget approval process?

You may want to include the department name in the file name, depending on your storage system's category/foldering features or if you have many processes with similar names. 

Example: Marketing: How to create a content calendar

 

Table of contents

 

If possible, include a table of contents at the top of their document, which contains links down to headings or anchors on the page. You can see an example above.

The links help people scroll down to the main sections of the documentation and to the main categories or subsections of the process steps. 

Why is this table of contents important?  

• Encourages team members to refer back to documentation more than one time after they've already read through it once
  • Makes it easy to find the answer to their question, the exact section of the process, instead of scrolling through the whole document 
• For some tools, such as wiki/web-based tools using anchors or even Google Docs, having the subheadlines or anchors creates separate URLs for each section, which allows you to send people messages with a link directly to the relevant section.
• Requiring the subheadlines for several purposes, besides ease of reading for the user, makes the writer more likely to use them 

Suggested interior sections of the document

See the slide below for the suggestions of what types of interior sections should be included in your documentation template.

Each piece of process documentation should use the same template so the documentation is easier to create and easier for users to find the information they need across all documents.

You can see these sections in the sample template. 

Formatting of the document text 

Here are a few tips about formatting your documentation:

• Use bullets to make it easier to read at a glance
• Use bolding and headings to visually separate the information
• Insert colored boxes to visually show important info
• Use short sentences
• No jargon! Use simple language 
• Link the article to alternate formats when it makes sense, such as an agenda template, checklist, or project management task template

In-progress language

To make documentation more manageable and not overwhelming, add language to indicate which sections are still in progress.

This may help you be more comfortable sharing it before it looks 'complete.' Remember that having some documentation is better than having none!

I like to use brackets to note this temporary, in-progress information, and for notes or questions for myself to look into. 

BUT... don’t make ALL of your documentation "coming soon" or you'll end up like this meme!

What if the process changes depending on an action or decision at a certain point?

When a process changes depending on a decision made at a certain point, known as a conditional process or if/then decision path seen in a Choose Your Own Adventure book, it can be difficult to know how to indicate that choice and the following actions in the documentation.

To solve this "if X happens, choose A," or "if Y happens, choose B" difference, two potential tactics are:

• Use anchor links to link down to the A or B section of the document. This will make it simple and clear where the reader should continue the process
• Link to separate articles to continue the process for A or B, one article for A and one for B

Visuals

After you've got a handle on writing the documentation, it's time to improve it by adding visuals or multimedia.

Different people prefer learning using different formats, and some processes are more easily shown in particular formats. Limiting documentation to a text format won't create the best documentation that is likely to be adopted by the entire team.

Examples of visuals:

• Screenshot
• Flowchart or process map
• Video
• GIF (no audio)
• Charts or graphs
• Infographics
• Embedded slides
• Emojis
• Images (for physical processes)

See more details and examples for adding visuals in this blog post.

 

Why do I teach the writing part first, if visuals or multimedia are so important?

A few reasons include:

• Text editing is easier than editing videos or flowcharts. There is no special software or special skills that may be a roadblock to documenting. 
• That being said, start with the format easiest for you. If audio or video is easier than writing, record yourself and transcribe it into written text. Even if you have a video for your steps, I also recommend having the written text document as the main home for the video(s) and transcriptions to live, since text is more searchable and skimmable compared to video or audio.

 

Dive deeper

• Read more about how to write business process documentation in this article.
• Lisa Wells talks about How to Write an Effective Standard Operating Procedure (SOP)  
• Layla Pomper at ProcessDriven shares How NOT to Write Standard Operating Procedures (SOPs)

• IT Glue shares a guide for writing standard operating procedures (SOPs)

• Trainual shares a guide for how to document a process
  

How do you create a system to ensure documentation stays in use and updated?

After you've accomplished the hardest part of documentation (starting it!), the next hardest part is continuing the habit of creating and updating it as your processes change.

You'll want to set up and beta-test a documentation system for yourself before you start to bring other people into the various roles for documentation.

And by system, I don't mean the storage tool or knowledge base where the documentation is created or organized. That software is just one part of a system!

The Oxford Language Dictionary's definition of a system is more appropriate here: 

• a set of things working together as parts of a mechanism or an interconnecting network.
• a set of principles or procedures according to which something is done; an organized framework or method.

Skipping the people and process system work, buying storage software, and expecting it to work miracles all by itself will probably fail. Remember, we are dealing with human behavior, so the solution is never as simple as just buying software. Time management, project management, communication, and other topics also need to be addressed to create the system.

Let's dive in.

Creating a personal system

Creating a personal system to ensure documentation is continually created and updated involves setting up habits and processes for time management, task management, greater project management, communication, and then documentation storage.

Time management

Making time to create, use, and improve documentation is where many companies fail in their documentation efforts. So let's start here, to ensure greater chances of success!

How do you currently remind yourself to spend time on ongoing work such as networking? Before it became a habit or routine, how did you ensure you did it on a regular basis?

Documentation is not a one-time, set-it-and-forget-it project. It is constantly evolving. Think about where you've had success in making time for similar never-ending work, and apply those tactics in this situation, too.

Two suggestions:

• Calendar blocking – with email or popup notification reminders
• Project management recurring tasks – with email, Slack, or other type of notification

Reminders are very important, especially at the beginning. If the task is just sitting on your calendar or in your project management system, it's easy to overlook or ignore it. Set up something like a popup or time-delayed notification that is going to get in front of you and catch your attention.

Task management

Has this ever happened to you:

You have your time blocks or tasks set up and are feeling proud of yourself. (And you should be proud! You took the first step to create the system.)

But when you arrive at that time of day, or see the task…you’re overwhelmed and don’t know exactly what documentation tasks to work on. 

And then spend that entire block of time trying to figure out what to do first. And nothing actually gets done.

 

Does that sound familiar?

To solve that problem of overwhelm:

• Add the specific details of what you are going to work on into your time blocks or tasks for documentation
• Add details to at least one future recurrence, if not a month or more at a time
  
  

Here is a good example of what I mean by being specific with tasks/time blocks:

“Complete the drafted document about creating a marketing email.” 

(Make sure you add a link to the draft into this title, so you’re not searching for the draft)

 

A BAD example of the name of a time block or task:

“Documentation”
(Unless it links to your detailed list of what to work on next.)

Part of creating a good system is interlinking everything, to make it easy to find what you need to work on, and spend less time searching around in all your tools.

Broader project management

In my classes, one of the assignments is to prioritize the first ten pieces of documentation to work on. But what happens when you’ve finished the initial version of all the documents on this list?

At that point, here are three project management parts of your documentation system:

1. Create tasks for building and/or improving documentation
   • Only make tasks for your top priority work to do. 
   • Ideally, small edits occur in real-time when a change is noticed or made to the process. 
2. Create a wishlist
   • This will contain the “nice to have” documentation for the future
   • It could contain brand-new articles and larger improvements to current documents
   • You may need a time cutoff to distinguish between when to add a current task and when to add it to the wishlist.
     • In my last role, my definition of 'future' was 3 months away (at a fast-paced agency). If you don’t think it needs or realistically can happen during the next three months, put it on the wishlist so it doesn’t distract you from priority documentation.
   • The wishlist also 'documents' all your ideas so you don't forget them
   • A wishlist helps team members feel seen and heard when you capturing their ideas, putting it where they can see it so they know that you didn’t dismiss their idea
3. Create a process for quarterly review & updates 

• • Reserve time to assess entire categories of documentation for maintenance and improvement 
    • Perform edits that were not made in real-time
    • Identify gaps where new documentation is needed
    • For larger improvements you identify as you read through each document, anything that takes more than a few minutes each, make tasks to complete after your category review. Don't lose momentum while reviewing.
    • Ensure all documents are standardized, as you read through entire categories at once
  • These reviews should be set up as recurring tasks in your project management system, or recurring calendar time blocks
  • Create clear instructions for how to complete a quarterly review 
  • By the time of the first quarterly review, you'll also need clear categories of documents, and to know which person  is responsible for each category (explained later and in the article about expanding your system to other people)

Communication tools and habits

Once your time and task management are set up and working well for you, it's time to start the routines and processes of good communication about documentation. 

Communication will help with change management, as you begin to change your teams from not using or being involved in documentation, to using and other roles in the documentation. Getting people accustomed to seeing you talk about documentation will help.

Poor communication about documentation is one of the main reasons why people don’t use it.

They simply don’t remember:

• That it exists
• When to use it
• Why they should use it. 

Let's fix that problem before it starts!

 

You'll eventually have many interlinking methods of communicating about new or improved documentation.

But don't overwhelm yourself and try to do everything at once! Start small, with one channel.

Think about: What communication channel is used most often by the most team members? Where would it make sense to discuss documentation or changes in processes?

Examples of channels:

• A messaging system such as Slack. I suggest creating a separate channel for processes, templates, documents, etc., to give this topic more importance and visibility
• An existing recurring email/ internal newsletter that you can add to
• An existing recurring meeting where you can add a small agenda item

Test your first channel and see what people respond to in terms of the channel itself, the formatting, the cadence, and the messaging.

Later, you can expand your efforts to multiple channels, using your first channel as the main source that you copy and paste from. Repeating the information in multiple places is important since different team members pay attention to different channels. It is also not realistic to expect people to remember something they saw or heard once.

What do I mean by communicating about documentation?

When you're starting your personal system, documentation communication will likely be a mix of informing people about what you are doing and informing people of the benefits or reasons why you are doing it. They likely won't need to take action from this communication aside from reading it.

Example:

 “The newsletter process document (link to it) was updated with a new approval process. The marketing team should review it and reply with questions.” 

 

Documentation Storage & Organization Tools & Habits

You've decided when to work on documentation, what to do, how to communicate about it...

Now it's time to decide where to put it.

When you're starting version 1.0 of your documentation, use the storage tool easiest for you, because the habit is more important than the tool at this point.

Remember the advice from earlier -- Once you actually have some documentation, you can hire or delegate to someone to migrate it from one tool to another. But it's difficult to hire someone to write your processes for you and extract that information from your brain, without taking up a lot of your own time in calls or emails. 

Write version 1 of your documentation before researching tools.

Once you actually have some documentation and are ready for your team to be more involved, then think about a tool easiest for your team to use. It may or may not be different than the tool you're currently using for yourself.

What documentation software should I use?

The best answer is: Use a tool your team is already using daily.

Think about where they spend most of their time working, such as in Slack, the CRM, or a project management system. Can you use those tools for documentation?

If the tool itself is not set up well for documentation storage, find a tool that integrates with that 'home base' where people are working, so they don't have to leave their main tool.

Then you also won't have to teach them a new tool IN ADDITION to teaching them new habits about creating, using, and updating documentation. 

Tool adoption is hard. New habits are hard. Most companies don't have documentation, so people aren't used to using it or creating it. Don't make the work doubly difficult for yourself by compiling these changes, unless absolutely necessary. Make sure to weigh the pros and cons of this change management.

If you do need to choose a new documentation storage tool, see some features to consider and potential options in this article.

 

 

Expand your system to involve your team 

Once you've completed the first step in creating a system to keep documentation in use and updated, a personal system, it's time to involve other people in your documentation efforts. 

At the very least, there may be users of your documentation, people who read it to learn about and perform their jobs.

Roles that could be involved in your documentation system:

• Users - people who are using documentation
• Subject matter experts  - people interviewed to create documentation
• Creators - people creating documentation 
• Editors - people editing documentation  
• Approvers - people approving documentation 
• Knowledge Owners - people responsible for certain categories of documentation 

Scroll down to learn more about each role.

One person may hold more than one of these roles, and you may hold all of them if you're in charge of starting the documentation initiative (Chief Documentation Officer 😀).

How to add these roles

You will be trying to rebrand documentation as knowledge sharing or enablement. You should not be talking about it in a compliance, "do this or else," type of way.

Position documentation efforts as team members helping each other, preventing their team from repeating mistakes, or repeating the research already completed to solve a problem.

Roll out these roles in the order listed above, over the course of several months. Don't introduce them all at once, as it will be overwhelming to the team.

You may want to start with one department as a pilot test for the roles.

Users

If you have a company larger than one person, you will eventually want people other than yourself to use documentation.

A few tips:

• Start by asking the people most likely to use documentation. Not the people you know will resist! Make it easier on yourself. 
• Communicate regularly with the users about the benefits of documentation, not only communicating that it exists
• Create a way for users to give feedback on the documentation, to improve it and help them feel more involved

How do you know if people are using documentation? 

If the process is working as expected and you’re getting the results you want, that is a sign they may be using documentation. Ideally, you are measuring the process so you can keep an eye on this status. If you get feedback on documentation, such as questions or potential edits, that is another sign people are using it.

People may not be using documentation if you're receiving questions answered in the documentation, if the processes are not working as expected, or if you don't receive any feedback or questions about the process documentation.

Subject matter experts

When you expand documentation efforts beyond your own role, you may not have the knowledge needed to create it by yourself.

If the person who holds that knowledge is too busy to become a creator, you can interview them as a subject matter expert to retrieve the process information.

Make sure to ask a lot of clarifying questions during this recorded call, then transcribe it into the document.

You can ask the subject matter expert to review and edit the first draft of the document. Editing is an easier request than starting it from scratch, so you will face less resistance.

Creators and Editors

Once you have users for a few months, or for another time frame of your choice, start to get documentation editors and creators involved.

Tips for introducing documentation creators and editors:

• Make sure you have clear categories in your documentation storage tool before assigning creators and editors, since each person will only be using certain categories, depending on their knowledge and role.
• You can usually set up permissions in your creation or storage tool to only allow certain people to have these roles, which may ease your mind that the new documentation system won't become a free-for-all mess anytime soon!
• Document those role responsibilities to make it clear what they are in charge of, and who is in charge of what
• Teach these people your documentation time / task / reminder system
• Ask this person to be in charge of the communication about the creation or edits of their documentation, so they get recognition for their work

Ways to get them started:

• If they are going to complete a process for the first time, ask if they could draft or edit the documentation 
• Add documentation into any new type of task or project, a standard step for completing the work
• Add a step into every project for editing the relevant documentation 

Approvers 

For consistency and quality control of the documentation itself, and for the processes the documentation describes, it can be helpful to have designated approvers.

You will probably be the original approver, but you may not have detailed knowledge of all company processes. For example, you’re not sure how that department’s leader wants the process to be completed, if if they'd want a process change.

Knowing someone is reviewing and approving the work also eases the anxiety of creators/editors who are not yet confident that their work is “correct” enough to share, such as newer team members. 

You'll also need an approval process that everyone knows how to find and use, so approvers know what to look for and editors/creators know what to do next.

Here's a suggested two-level approval process:

• The department manager approves the documentation content for subject matter accuracy
• Then a documentation expert (probably you, if you're reading this) approves it for consistency and standardization, such as formatting, clear language, naming, and linking

Knowledge Owners

The knowledge owners own certain categories, subcategories, or documents. They make sure all necessary documentation exists, and is up-to-date. They also answer team questions about these processes.

The biggest part of ownership may be the quarterly review and updates to all the documentation they own.

They will need to know and use your entire time/task/communication system to them, for their assigned category.

It will probably be the last role you will create because you'll need HR and managers’ assistance setting up rewards and allotting time for these people to do the work.

 

Read more about roles in this article about adding people to your documentation system.

•  

Improving an existing system

Congratulations on HAVING a system for documentation!

That is a rare accomplishment!

To improve your system, you'll need to identify what is currently working and not working in your current system.

Suggested steps to improve your system:

1. Complete User Research
2. Perform an Audit
3. Decide on the Changes to Make
4. Begin Making the Changes

In case you didn't read the above systems sections, note: the documentation system is NOT just the tool or software for storing documentation (Notion, Google Docs, etc.).

Perform User Research

Though you may have ideas for improvements, it is important to get other users’ (and other roles) opinions.

Complete some user research!

This will help you uncover problems you may not have known were contributing to the system issues. It will also help with change management since people will become aware of potential changes, and you'll make them feel involved and less likely to resist the changes. 

The first research question may relate to why people are not using the system or using it correctly. 

Reasons why people aren't using documentation could include:

• It is outdated
• It is not written clearly
• People don’t know where to find it 
• The team was never trained on HOW to use it 
• They can't use it because of software permissions 
• They don't know WHY they should use it.
  
  

Do surveys and live interviews to find the root cause(s) of the issues, not merely guessing or identifying the symptoms.

What are people doing instead of using documentation? Is that working well? These are also good questions to ask.

Complete an Audit

What comes first, the audit or the user research? 

You may have to perform them both in stages or rounds, since you may not have a clear idea of WHAT to audit until you complete some user research. But you also may not know the best questions to ask users until you uncover insights in the audit.

And don't just audit the storage tool or the documentation itself!

Investigate all parts of your documentation system -- time management, project management, communication routines, storage tools, roles & responsibilities, and more.

Potential things to audit (and document!): 

• Outdated information or outdated entire articles
• What articles are used or edited more often?
  
• What documentation is missing?
• What categories or subcategories are missing, especially if your company has grown?
• For the individual documents, does your template, structure, or naming convention need to change?
• Have the time & task management systems been effective? Why or why not?
• Are your communication processes clear? Are people using them? Why or why not? 
• Audit your roles – if you have roles set up! You may need to set them up.
• Lastly -- Is the storage tool the problem with people not using it? Does it need changes in permissions, features, or integrations with other tools?

 

Decide Which Changes to Make

Plan out the improvements to your system using the insights from the user research and the audit.

Ask other influential leaders or team members to help plan and prioritize. Don't do it by yourself. This will help get their buy-in so they will champion this plan to their teams and not resist it (change management). 

Communicate:

• The plans
• WHY the changes will benefit individuals, teams, and the company
• Often! Before, during, and after the changes

 

Begin Making the Changes 

First, ensure you have documentation for how your documentation works and for how your current system works.

For example, have two articles:

• One for creating or editing the documentation articles themselves
• One for how to manage and maintain the system

Updating these articles as you roll out the changes will help train people and instill trust that you're "walking your talk" and keeping documentation up-to-date and useful.

You may want to begin these changes with a pilot group. Find a team or department that is likely to accept changes, and roll out the changes over a month or so. This could help you identify initial problems with your planned changes, and fix them before you roll out the plan to other departments. The pilot group could turn into champions for the changes and help you communicate to the other teams later. 

 

Dive Deeper

• Read more about improving documentation systems
• Read more about creating a personal system for documentation
• Read more about the team roles in documentation
• See the workbook for the documentation system workshop
• Watch or read about my Operations Nation talk about documentation systems and more
• Susan Fennema and Amber Kemmis discuss Using Teamwork to Document Processes at the Teamwork.com User Group
• First Round Review discusses: Investing in Internal Documentation: A Brick-by-Brick Guide for Startups
• Jeff Cypher shares How to Create an Internal Wiki in ClickUp
• Justin Norris shares his knowledge base on RevOps FM
• Examples of public knowledge bases:
  • GitLab Handbook
  • Open Org Handbook
  • Open Org also compiled a user-submitted Airtable of company policies (turn off the filters to view them all)
  • Oyster's open employee handbook
  • Remote Handbook

How do you create a culture of documentation?

Building a culture of documentation can be difficult because it combines several tricky interconnected topics such as:

- Making time for long-term work instead of defaulting to the day-to-day reactive work

- Tool adoption (potentially)

- New behaviors and habits in general

Many of those topics relate to change management. 

You want yourself and your team to change how they are working. Remember that documentation is not a normal behavior; most companies don't do it. So it can be scary for people who've never worked in this way before. That fear often leads to objections.

 

Overcoming objections

When you start involving other people in your documentation system, you will probably get pushback and objections from people who don’t currently use documentation or hold other roles in documentation.

If you only take one thing away from this section, here it is:

One of the best ways to overcome objections is to learn what the objecting person cares about, and explain how this change (documentation) will benefit that topic they care about. 

 

For example, think about what leadership cares about.  

There are a lot of potential answers, but one common response may be that they care about achieving business goals or department goals. So explain how documentation benefits their specific goals or goals in general (Hint: You can't improve if you can't see what to improve in order to meet a goal!)

Let's discuss a few of the most common objections and potential responses related to uncertainty about benefits, time, money, and confidence.

Uncertainty Objection: “I don’t see why I should care; how does it benefit me?” 

This is usually subtext, such as someone not responding to any of your requests to be involved in documentation.

To overcome this objection, tie the benefits to their business goals or their role’s goals. 

Here are a few potential scripts.

For leaders responsible for building and retaining a team:

• “Documentation will help us attract and retain more talent (people), by offering benefits of efficiency like reduced hours.”

For anyone responsible for increasing revenue (and also expanding teams):

• “Documentation will allow us to onboard new employees efficiently and increase revenue faster.” 

For team members who are creating or improving processes or aligning teams:

• “Documentation makes it possible to see, agree on, and improve processes.”

For anyone involved in testing and innovation:

• “Documentation makes iterating and experimenting more efficient.”

Another tactic, if you're more familiar with the person: tie the benefits to their personal values or to improving company culture.

• “Regular documentation fosters a culture of open communication, collaboration, visibility, transparency, learning, helping…these are signs of a healthy culture where people want to work. I’ve heard you talk about the value of culture and how important it is. I think getting people using and involved in documentation could really help improve our communication & culture.”
  
  

Time Objection: “Our company is innovative. We move fast and break things. We don’t have time to document. It’s a waste of time.”

Potential responses:

• “If you want to grow the business, we need documentation. It only takes a little more time upfront, using an efficient system I planned, to save us a lot more time in the future months compared to the amount of time spent documenting.”
  
  
• “If you want to scale, we can’t rely on people transmitting information in real-time through Slack or in meetings every time our people need answers. That solution doesn’t scale when you add more people, more volume of requests, and an increased need for that knowledge, as we hire and grow our customer base.”
  
  
• “If we document our experiments as we break things, it will help us not repeat the time & and mistakes of past tests. We can use past knowledge as context for future improvements to iterate and move even faster.”

Additional advice:

• Speaking of tests -- getting their support on a ‘test’ or ‘experiment’ of documentation may be the first step if you can measure the before-documentation and after-documentation results
  
  
• Don’t give up after one ‘no.’ Startups and other companies with the above objection are moving fast, so a no today just means 'no right now.' Revisit the topic in a few months, perhaps after gathering more support and data about the benefits.
  
  

Money Objection: “It takes time away from value-add or revenue-generating work.” 

To respond to this objection, educate them on the long-term benefits of documenting

• “Documentation will help us do the revenue-generating work faster (efficiency), enabling us to earn more revenue.”
• “Documentation helps us do value-add work with fewer errors, reducing re-work time & and complaints from customers and internal teams.”
• “Having documentation will help with training new team members faster, so they can start earning revenue faster.” 
• “Documentation allows us to cross-train employees so anyone can solve customer or internal problems faster when certain team members are unavailable (such as people in other time zones).
• “Documentation reduces internal meeting time because there is less need to meet if people can self-serve answers. That will give us more time for value-add or revenue activities.”
  
  

Confidence Objection: “I am not qualified to create documentation; I am not an expert.”

Possible responses include:

• “We’re creating living documentation, it is never finished. We want to encourage continuous improvement as we learn more about the processes. So you don’t have to be afraid that your first draft is final forever.”
• “We have approvers or owners set up to help edit your documentation. You don’t have to worry about the whole team or company seeing it before you get feedback about improvements or corrections.”
• “That’s OK, we are all learning and improving. Just write a little at a time, every time you complete this process.” 
  • Explain ‘in progress’ sections to them

• “Think of documentation as sharing your knowledge or sharing what you learned with your teammates, saving them time, preventing mistakes, and preventing them from doing the same research and testing you’ve already done. It may not be the ‘best’ way to do something in the entire world, but if it’s the best way you’ve found so far, and no one else has done it or documented it, you’re helping your team by sharing what you’ve learned.”

 

Learn more in these blogs related to the objections of:

• Time
• Cost
• Unsure/Indifferent to the benefits
• Confidence

How to create a culture of documentation

Though parts of creating the culture were started during the system design phase, after overcoming the initial objections when you start to involve people in documentation, then you can start to build the culture more proactively.

Some of the building blocks of a culture of documentation include:

• Start small -- start with one topic or team
• Transparent communication -- documentation enables this and also requires this
• Emphasis on equal access to information -- everyone will see and learn how different parts of the company work
• Leadership buy-in and behavior modeling -- necessary to build any part of culture
• Say no to meetings without agendas or action items -- enhances this culture of writing
• Remind people, personally and through automation -- remind people of the benefits and that documentation exists

Keep reading for more details about building a culture.

Communication

If you haven't completed it yet when designing your system, then the first step is to set up communication channel(s) about documentation.

Use it to explain the benefits of documentation, to create a desire to change. Creating desire is part of change management.

Since documentation and other forms of transparent communication are not normal, average behaviors at companies, you'll need to make people aware there is a better way to work, and create a desire to change.

Make people aware of the current problems with the lack of documentation. Awareness is another step in change management. 

 

Bake documentation into many aspects of work

Normalize it as something everyone does by default, and make it easy:

• Add documentation duties, such as being a knowledge topic owner, into job descriptions
• Have many different people communicate and share documentation updates or news
• Add it to your project management system and processes
• Report on the results on a regular basis, sharing the successes from having useful documentation

Celebrate and reward people who do it

• Feature a “wiki of the week” or highlight the person making the most articles
• Publicly thank people for writing or editing documentation
• Ask your people ops team (if you have one) if they can expand any current company rewards programs or gamification
• Talk with HR about creating a new role level or requirement for being a knowledge topic owner, to have it tied to promotions

Teach new employees in onboarding 

• Use documentation to teach their basic onboarding tasks
• Have them review documentation before training calls and bring questions
• Show them the continuous improvement mindset by editing documentation live in the moment when they have questions during training
• Teach them to check for documentation first before asking, by including links to documentation in your answers to their questions
• Teach them about how the documentation system works and the benefits you’ve seen from the documentation efforts

Add documentation into all trainings for all teams

• Teaching them how their involvement in using, creating, and updating documentation will help them upskill and do their job more efficiently and effectively to help them promote
• Have them create documentation to run trainings for other team members or clients – as part of training to become a manager
• Managers can check or improve their team’s understanding of a process by having the team create documentation, thinking of it as training and learning
  
  

Create thought leadership about it 

Much like documentation itself, thought leadership is sharing knowledge! 

• Encourage all levels of team members to share their expertise and experience on LinkedIn, in communities, or at online events
  • They don’t have to be talking specifically about documentation
    • Sharing wins in general will lead people to ask, ‘How did you do that?’ 
    • They may answer, “We’ve been documenting our experiments and improving this one part of the process and discovered xyz that made us zzz% more successful”
  • It will show your company is open about communication and sharing knowledge which will attract people interested in working that way, creating a positive cycle to enhance your culture of documentation

 

Dive deeper into culture 

• See the worksheets for documentation culture building
• Read or watch a webinar from my previous boss about our culture of documentation
• Caity Cronkhite discusses Making the Business Case for Documentation on a webinar for Good Words and shares a documentation impact calculator
• Benjamin Hinson-Ekong writes about How to Build a Culture of Documentation
• Josephine Conneely writes about how process impacts your culture
• Keysa Yánez writes about feedback culture as a part of nature or something to nurture
• Daphnée Laforest writes about how async is a culture shift (and it requires documentation)

 

Conclusion

You've learned all the major steps for:

• Prioritizing and starting documentation
• Writing documentation
• Creating a system to continue creating and updating it
• Building a culture of documentation. 

You may be feeling overwhelmed by an overload of information and tasks to do!

Remember the #1 tip: Start small
Take it one step at a time.

Future you will thank you, once you've started your documentation journey.

 

Dive deeper about documentation in general

• Find the full workbook for the courses here
• I spoke with Travis Scott about documentation for success on the Demand & Ops Unboxed Podcast
• Trevor van Woerden and I discussed my courses and documentation in general, the need for more education, on the 3:44 Live Show
• Jakub "Kuba" Grajcar writes The Ultimate Guide to SOPs: Turn Your Business Into a Process-Driven Machine
• How to Build a Business Playbook -- Trainual
• Intelivate shares a long article on documenting processes
• Divio writes about the documentation system
• Whale blog shares 7 Ways to Strengthen Process (And Why You Shouldn’t Overlook It)
• RevOps Co-op shares a blog and webinar recording about how to Revolutionize Sales Enablement with Real-Time Tips for Process Adoption
• Maggie Kornahrens shares common processes to document (and to make project management task templates for)
• Tim Jordan writes about how to tackle a major knowledge base revamp
• Susan Fennema writes about Policy, Process, and Procedures
• Christopher Gwinn writes about The First Five SOPs To Document When Crafting Your Training Manual
• Trainual shares a guide for how to document a process
• Matt Stein writes about how good documentation is hard
• The Manual shares How to Craft the Best Knowledge Transfer Plan
• Elisa Reggiardo at Slite writes about Unlocking Your Startup's Growth Potential with Knowledge Management