Event Summary: Documenting Success from Demand and Ops Unboxed

Thank you to Travis Scott for inviting me to the Demand & Ops Unboxed podcast to talk about documenting your business processes! 

We tested a new recording process on LinkedIn Live, and then Travis published it on YouTube.

The show covers these topics (which link down to that section of the blog):

• Introduction

• How did you get interested in documentation and creating courses?

• How do you think growth would have gone had you not documented?

• What are the benefits of documentation?

• Documentation's benefits for solopreneurs and hiring
• Documentation as a recipe
• How do you start documenting your processes?
• Where should documentation be stored?
• How to structure your documentation project
• External customer-facing knowledge bases
• Biggest Takeaway
• Class information

We had a previous conversation that didn't record well, and I'm not great at talking so I have to prepare a lot. This means there are some bonus notes and more clearly defined answers for you in this blog! I incorporated my notes into the topics above to clarify some of the points we discussed. The notes I didn't use in the 30-minute podcast include:

• Transitioning from in-house work as an employee to working for myself
• Are there any common questions or hot topics related to documentation?
  
  • How to make time for it, accountability when it's not urgent
• Why do companies struggle with documentation?
• Should documentation skills be part of the criteria for hiring team members?
• What kinds of clients take your courses?
• What feedback have you gotten from your courses?
  
  

Watch the video below, or keep reading!

Introduction

Thank you for having me on the show, Travis! I think this is my first Linkedin Live!

My name is Jen Bergren, as you said, and I think the best title I have for myself right now is Operations Educator. I am working for myself, creating the educational resources I wish I had when I was helping build a new company, such as courses about process documentation. Hopefully, these resources will save you time and stress from trial and error, and prevent you from needing to start anything from scratch.

That 'new' company I mentioned is now called Remotish, a HubSpot WebOps and RevOps agency, though they recently merged with another HubSpot agency, Media Junction. I joined Remotish as kind of employee #1 and worked in a variety of roles, eventually as the head of operations.

HubSpot was one of the ways you and I connected, in the HubSpot community. I think we were also in a group of Pavilion members making Maven courses at the same time, and other similarities and overlaps such as Indiana University.

Now, I also currently work at a university evaluating student papers, co-created/co-teach the HubSpot Academy RevOps bootcamp, am writing a book about RevOps, and many other things. 

How did I get into operations?

My first degree was in graphic design and journalism, and my first career was designing magazines and catalogs.

Working with photographers made me interested in photography, so I started a photography business.

I enjoyed learning all about business and marketing for the first time. When that business didn't work out after about 5 years, I went back to school for marketing and business.

After graduation, I started working at Remotish in sort-of a marketing role. Eventually I moved into other, newly-created roles and managed the people in my previous roles, while building what I would later learn was the operations foundation for the business. That journey eventually led to an official operations manager role.

You can read more details of my career journey here.

How did you get interested in documentation and creating courses?

In all those roles I had at Remotish, documentation was a common theme. It was especially relevant for creating new roles and for training people to take on the existing roles, such as the roles I left. So we had a pretty robust knowledge base, task templates in our project management system, and so on. I just saw all the benefits of it, such as the mental health benefits of less stress, being able to take time off easier. 

We had a 30-hour work week program, for example, that would not have been possible if we didn't have documentation to cross train people and fill in when team members were using their time off.

After creating an employee onboarding program to double the size of the company in 2021, we needed a way to get people up to speed quickly about how to work well remotely, how to work at at an agency, and how to do their specific work. Having documentation was helpful for me as well when I was creating the program, for knowing what to train people on. Building that program was really interesting, thinking about the order of when and how to learn things to be successful in a job. 

I think Nicole, my CEO, gave me the task of creating the onboarding program. That would make sense after seeing my interest in other training efforts, such as building internship programs, creating promotion plans, and other people ops work. Besides her, I was also the person with the most legacy knowledge to share to teach people how the business ran and how every piece worked together.

I heard a lot of the new team members talk about how their previous companies didn't have documentation and how helpful it was for them here.  I thought I should talk about this topic, so I spoke at some events/webinars and wrote a few articles about process documentation.

Creating the onboarding training and other training types of programs made me interested in instructional design so I took an instructional design certification. Then I enrolled in an accelerator program for making cohort courses from maven.com. For that program, I had to pick a theme for what my cohort course was going be about. I thought that I've been talking about documentation for while, I have all this content from presentations and blogs, I think that might be a good topic for a course.

I've never seen a course about documentation, and wish I had access to one when I was creating all the knowledge management at my job, so that is how that came about. The story of starting to create courses and why documentation is the first course topic.

How do you think growth would have gone if you not documented?

I think there would have been less company growth and more up and down, fluctuating results in the business without documentation. We didn't have a lot of employee turnover the first few years but in a small company, every time any person  leaves, a big percentage of the company's knowledge disappears unless you documented it. When hiring and training a new person, you'd have to start from scratch with your training, and they'd have to go through a lot of stressful trial and error. They would be repeating past mistakes of problems that were already solved, just to get to the baseline of the previous person, if there is no documentation.

Travis talked about small companies that grow from a few people without documentation, with all the knowledge stuck in their heads. Then the business complexity changes as headcount increases, and documentation becomes even more important.

How does not having documentation impact how fast a business can grow?

At a certain point in growth, the managers won't be able to answer their team's questions, there are just too many people.

And as more people hired, the more often the same questions will be asked.

Managers don’t have time to just answer questions on Slack all day, or jump on a meeting every time someone repeats a question.

In a company with documentation, the managers can point to the documentation and people can self serve, train themselves, in order to answer or prevent common questions.

Documentation can reduce the need for meetings, especially these on-demand meetings, which is a big benefit.

It could help start that writing culture in the company, like the joke about 'this meeting could have been an email.' Making documents or videos, storing them in a central location, and then asynchronous communicating their existence and importance can prevent a meeting on that topic.

Also with a writing culture, requiring agendas and shared notes for any meeting can help reduce meetings. This includes reductions from people who don't want to write agendas so don't schedule a meeting, and from people who realize the agenda is enough information to communicate by itself without a meeting. It also reduces time for people to view meeting recordings because reading meeting notes is generally a lot faster than listening to or viewing a meeting or recording.

Freeing up people's time from unnecessary meetings, to give them more focus time to work on big projects that achieve company goals, also affects how fast a business can grow. Which all relates to documentation!

Travis and I have a good time when we chat about documentation and more!

What are the benefits of documentation?

Travis said that onboarding is huge for growth. It's hard to grow if you can't get people onboarded and up to speed as quickly as possible. What are some of the other benefits of documentation?

There are so many benefits! I'll focus this answer on the individual/personal level, because a lot of people don’t talk about these benefits.

• Less stress, resulting from: 
  • Not relying on memory. You don't have to keep all the information in your brain. This is especially hard if you're at a small company and you're doing  10 roles at once. Maybe there's a task you only do once a month, for example. You're not expected to remember all of that information, you can refer to the documentation.
  • Saving brain space and energy for “creating” or “improving” work, not just repeating existing processes 
  • Not worrying about missing any steps in the process
  • Less worrying about potential errors
  • Easier delegating, reducing workload stress
  • Easier to learn new tasks, new roles if they are documented
  • Easier to take time off 

See more reasons why documentation is important here, and read from additional expert contributors on this blog. 

How does documentation help people be less afraid to take time off?

Some people think they can never take time off because no one knows how to do their job, so they are going to come home from vacation to a mountain of work because no one filled in for them. No one could fill in, since there was no documentation for them to use to complete the work.

Of course, you also have to put together a backup plan, a cross-training process to define who's responsible and when, but documentation enables it because people can learn how to do those parts of your job while you're gone.

Travis noticed I had a Freudian slip of of saying 'come back home' when you might come back to work.

I do work from home so it is all mixed together!

Travis mentioned if you don't have your processes documented, then your work is going to become your home because you're never going to get away. You're not as efficient. Documentation speeds things up so much, especially repeatable tasks.

Also, you can improve your processes if you can actually see them, but if everyone's doing something a different way, it is pretty hard to improve because you don't know what's going on right now. How do you improve that mystery?

Travis asked if I've ever been in a situation where people have been afraid to take time off. If I had to kind of talk them off the ledge because we have the documentation, to help them realize they could take the time off.

I don't remember a specific example, but I know that was a general feeling working at other companies without documentation or back up processes. Everyone, including myself, was weighing the benefits of taking time off with the stress of knowing you'll have even more work when you return.

Documentation's benefits for solopreneurs and hiring

Travis and I have talked about benefits for a very small business, for founders like us.

Travis said as a solo consultant agency thinking about 2024, he really wants to grow his business. The biggest rock to move is around documentation, because to grow and build the business beyond himself, it means he has to hire people. "If I have to hire people {spend the time to hire] and if I'm already busy enough to need to hire, I don't have time to to do anything. I don't have time to train, I don't have time to bring them on and take them under my wing and say, 'Here's how we do this,' because we just don't have the time," he said.

Very true!  

It's really hard to train contractors, interns, or first team members as a one-person business, especially without any documentation. 

That would take a lot of 1-1 phone calls, Slack messages, answering questions, correcting people…instead of getting your own work done.

It's also critical for one-person businesses to document for business continuity in case of emergencies and to allow for taking time off. The negative way to frame that is 'What if you're hit by a bus?' or more positively, "What if you win the lottery or take a month-long vacation? How will the business continue without you?"

You need to be able to hand the keys over people know what to do when you’re gone, to keep the business running and to keep yourself from worrying.

We talked about how we started businesses to have freedom, but to be able to be truly free and grow, you need that instruction manual to be able to work on the business instead of in the business.

Documentation as a recipe

Travis said, "I know that I need to have everything I do documented, especially the HubSpot onboardings and implementations, to have that stuff laid out almost like a recipe. Is that kind of how you would think about documentation, as an instruction manual or a recipe?"

Yes, I like the recipe example because it's more approachable. It helps people be a little less scared or stressed when either making or using the documentation. So that's a great example.

Travis said unless someone has an aversion to cooking and it just stresses them out, cooking with all the exact measurements. Like if it says quarter cup...shaking the cup, making sure it's flat and not heaping. "Sometimes I'll just pour it in, I won't even measure it, so I think you need to stick to the specifics in your business's documentation.

Don't allow people just to dump the sugar in," he said.

Travis said when you start to do it over and over, and you have it documented, at some point you probably don't need the documentation for yourself but then it's always there if you or someone else needs it.

 It also helps you learn things faster, if you have it documented, he said.

I agree, documentation definitely helps you learn faster. There's less trial and error, and less guessing what might be going on with the business or process.

How do you start documenting your processes?

Travis asked: If someone has grown their company to a handful of employees and they realize they need to start this, how would you recommend they start? It seems like a huge thing,  you've got all of these processes, where do you even start? How do you advise people who are in that situation on how to get started?

I know he didn't tee me up for this, but I do have a free resource about how to get started and how to prioritize your documentation.

Think about what your roadblock is to starting documentation.

The three main roadblocks are overwhelm, fear of not getting leadership buy-in, and fear of the documentation not being adopted by the team. The second two are longer term, "will this time and effort be worth it," type of mental roadblocks.

From your question and scenario, it seems like overwhelm is the roadblock here. There is so much to do, so many processes, aside from all the other day-to-day work of the small business owner.

If you're the business owner, you probably don't need to get leadership buy-in because you are the leadership. So that's probably not your roadblock. The third roadblock about adoption may not be as relevant for you in this case. If you're the CEO, people might be more likely to listen to you compared to another team member starting a documentation initiative.

If overwhelm is your concern, start your documentation with a small task that you do often. The process of creating a recurring meeting agenda, for example. Just start with some less stressful pieces of documentation in order to get in the habit. Also think about documenting processes that you can measure and repeat often, to see if you need to make improvements to the documentation formatting for example, or use a different structure. 

Definitely have team members checking the first or second draft of the documentation to see if it is useful and have them suggest changes for clarity. Don't go too far into it without having someone checking to see if the steps are clear. That will really help you get a good start and get over the fear/perfectionism. Documentation will never be perfect since it is always changing and updating along with your processes.

More tactical advice on getting documentation started:

Shameless plug - take one of my classes. :)  

• Having that time on your calendar creates accountability for starting and doing work, which is one of the main benefits of a live course
• Kickoff that documentation habit or get back into the groove of documenting regularly

Aside from that, how I’ve seen people start and succeed:

• Block you calendar, make a task, etc whatever works for you to reserve time for perhaps 2 hours a week
• Start small
  • Documenting your own tasks or processes, since involving other people can be challenging to start with 
    • Documenting other people’s processes can cause roadblocks and not set you up for that small win of getting the first documentation articles done and starting the habit
• Prioritize 1-2 pieces of documentation to start 
  • I have a prioritization blog here to help you
• Then start a first, messy draft of the process steps 
  • Getting the info out of your head, it doesn't need to be perfect
  • If writing is hard for you, you can use a screenshare tool and talk, or just a Zoom meeting and talk to record yourself. Then transcribe it. 
  • There are some fancy tools that record your clicks to make those into steps of gifs or videos.. but I caution against looking into fancy tools first before writing anything at all. 
    • Tool research can be a form of procrastination, so try to start with the tools you have first, to get some documentation written.
• Then improve the document each time you run the process, maybe 1-2 more times, adding or clarifying steps
• Then have another person test the document to see if they could run the process using it
• Continue to add, iterate, improve from there

You can read more about writing documentation in this blog.

Where should documentation be stored? 

Travis asked about storing documentation,. What is the best place to start? Is there a place to graduate to eventually as you get more complex? Should it be searchable somehow?

That's a great question. I would say for starting, if you have zero documentation, start with a tool that you already have, even Google Docs. It may not be the best long-term solution but it's enough to just to help get you started, to get in the habit of creating and using documentation. It's somewhat searchable (though not perfect because of all the other messy things in Google Drive -- encourage your team to use navigation instead of search). You can have one folder that everyone knows where to go. Project management systems that have a documentation area built-in can also be good choices to start with...if you actually use your documentation system every day.

As you grow and have more documentation and get more people involved, you'll want to have something more like a knowledge base where you can have categories, tags, archiving and other features for better organization and search.

HubSpot's Knowledge Base tool

Travis asked about HubSpot's knowledge base tool in Service Hub and also HubSpot's external-facing knowledge base for product documentation for HubSpot customers.

At Remotish, we used the HubSpot knowledge base tool to create our documentation knowledge base, with privacy settings for internal articles based on a list of employees, and also a few customer-facing public articles with different privacy settings.

I believe now HubSpot has an ability to create multiple knowledge bases in one portal so that can be a cleaner and safer way to split the internal knowledge and customer-facing knowledge.

Since that feature didn't exist at my last job, I had to make sure the part of the wiki (documentation) article about creating documentation was very specific about which permissions to use to save the article, so private information wasn't public and so the team could access it using the wiki site and not just searching internally inside of the HubSpot portal.

If most of your team is using HubSpot every day, then that could be a good choice fo your documentation storage. Wherever your team is doing their work every day is a good place to store or integrate your documentation, such as integrating with Slack for companies who use Slack all day. I call this the team's "home base." Don't make the team leave their home base.

You can read more about documentation systems here.

Common question: What tool should I use for documentation?

So as a human-centered operations leader, that means I put people and process before tech. Buying software, by itself, is rarely going to solve a problem. 

My advice is that this should not be your first question when you're thinking of starting documentation. A tool is not the place to start. Don’t get stuck in tool research mode which is actually procrastination in disguise. 

Use the tools you already have to create your first 10 or so pieces of documentation.

• Even Google Docs, most people have access to those
• If writing is hard for you, start by using Loom or Zoom or whatever tool you have to record yourself and transcribe it

Once you actually have some documentation, it’s not just a dream about documentation, you can think about what tool the entire team is most likely to use.

• Ideally one they are already using, or one that integrates with a tool they use daily 
• A project management system, CRM, or tool that integrates with Slack, for example 
• Don't make people learn how to use a new tool on top of this new habit, Tool adoption is difficult so don't make it harder for yourself to get documentation habits adopted.

The habit of creating, using, and updating documentation is more important than having the fanciest, trendy tool. 

Because – this is important – you can always migrate, copy/paste, your documentation into a new system later if needed. 

You can even delegate that migrating work. But it is much harder or maybe even impossible to delegate getting that process information out of your head. 

Write first, tools later.

If you like doing tool research, maybe that is your reward for getting 10 pieces of documentation written. You can then spend 1 hour on tool research for the next phase of your initiative.

Or once you have some documentation, the person you delegate to can do the research about the next best tool you can use for documentation. :) 

I am not an expert in the specific documentation software and I don't talk a lot about specific tools, since the tool companies themselves create content that is findable about tool benefits and comparisons. You can find that info online, I don't need to recreate it. The software companies have entire marketing departments of people paid to write about it. I don't work for a software company so I try to focus on the people & process side, the human side of documentation.

How to structure your documentation project

How important is it to to have a well-thought-out organizational structure?

I think that's very important when you HAVE documentation already, but don't stress about that at the beginning when you have no documentation. That's going to be a roadblock. Just get started writing your first few pieces.

If you're working improving your existing documentation system, the structure is definitely something to audit. And don't just improve it yourself with only your own ideas. Survey your team and do other user research to see what makes sense to your team. They might use different words for the process that they're searching for and those search words won't come up with any results because you didn't make tags for them. Or they might think a process should be in a different category. Or if you have sections of documentation separated by permissions by teams, and multiple teams might need to use the same article, that is something to consider.

There's definitely a lot of thought that needs to go into that, but not immediately, so don't let that stop you from starting your documentation initiative.

Travis asked another question about structure later, for people who like building folders and structure first before starting anything.

I would say if the person has a dedicated role to documentation or a dedicated quarter of the year where that's their main activity, then deciding on a structure first makes sense. If it is part of a big project of doing a lot of documentation across the whole company or many categories all at once. 

But that's rarely that's the case in real life.

Documentation efforts usually start by building a couple pieces here and there for a few months or delegating out a few pieces here and there depending on what you need. This just-in-time documentation is a more common place to begin.

Then you start that habit where you make a new process and immediately document it, you'll start building it into your  regular routine. Any time you do a new project, you make sure the documentation exists and/or is updated as you go along.

So it will be probably less of a focused effort, not planning out all 100 articles in advance, because that is just not very realistic with the time that most people have for the documentation.

Once you have some documentation, I do recommend doing a quarterly review of each category, which is a good point in time to identify and make tasks for missing articles that would be helpful to create, and other improvements.

External customer-facing knowledge bases

Travis talked about how HubSpot has done a great job with their external-facing knowledge base for product documentation and asked:

How important is it to to develop an external facing knowledge base?

Are there some businesses that it it it's better for than than others?

I  would say it is important to have customer-facing documentation, so customers can answer their own questions.

Even for service businesses, there could be articles about how do you get started working with your company, what happens after you sign a contract or make a first payment.  We had an article on that topic that was externally-facing at the agency I worked for,  so new customers in the gap between when they sign an agreement and when they're onboarding can see what's next.  Sometimes there was a gap in time when we were waiting for that first payment from the client. Then they don't need giant emails about the topic, just emails with a link that they can forward to others on their team.

We had a few other customer-facing articles, such as how to review website development work using a specific tool for submitting comments to us.

Starting a customer-facing knowledge base for a services agency

Travis later asked how did we start deciding to have customer-facing articles in your knowledge base, what the catalyst was.

If I remember right, we were trying to consolidate information. This is something we were always trying do so we didn't have to update the same information in multiple systems and documents. For example, having information in multiple places where we'd have to update it for sales, for service, on the website, or for company email templates. Instead, it would live in  the knowledge base documentation article/wiki, any other place that needed to refer to it could use a link to that article, then we just have to update that one wiki instead of multiple places. I think that previous example of the gap between contract, payment, and onboarding was one of the first articles, and the sales process in general may have been another one until we moved that to be even more transparent on our website.

Travis asked if we were basing some of the external documentation on questions that we were getting from customers, was it influenced by interactions with clients, or did we brainstorm and just build it piece by piece over time.

I think it was a mix of the two methods. It wasn't super extensive, we had at most 10 public articles because we were a small company with focused services. Those articles were essential things for customers to know so they weren't in the dark and so they weren't asking the same questions over and over. They articles may have been more proactive to prevent questions and problems that we could predict, not reactive about existing issues or questions.

HubSpot's external customer knowlege base

Travis said if you're a software company, you're probably going to have pretty extensive documentation on how to make it work best for that customer.

He asked if I know anything about HubSpot's documentation team for their external knowledge base because it's very impressive how much information is out there, they are the North Star if you want to build a customer-facing knowledge base. Any question you could possibly have is probably answered in the knowledge base and a lot of it is updated quite often, even though product releases happen every day.

Whereas he'll look at Google's knowledge base with a question about Google ads and their knowledge base is just going to be horribly outdated. It doesn't keep up with product releases so they are an example of how not to do it.

I do not know anything about their product documentation team or how those roles and responsibilities and processes for updates work but would be happy to talk to people about it for a future blog, if any are reading this. :)

My advice is: Don't get intimidated by HubSpot or other large established company's knowledge bases if you're just starting out building yours. Keep in mind they've probably been building both the articles and the update/infrastructure processes for 10+ years and likely have a whole team of people working on it, compared to the one person looking to start documentation at their company. 

More about product documentation

Product documentation is usually software documentation for customers to use, telling them how to use the software. 
Documentation in general doesn’t get much attention but any attention online goes to this kind. The few documentation conferences and communities I’ve found are about this type, the job title here is usually technical writer.

This type receives more resources, people and time devoted to it, in companies since it is customer-facing. 

Customers want to know how to use the product, they are searching for answers of how the product works, So product documentation has a clear benefit of reducing customer support ticket/chat time by providing answers either self-service or because the team working the live chat or email responses for your company can link to the information.

The documentation I talk about mainly is process documentation, which tells people how to do everything in your job or company.

Other thoughts on external product/service documentation vs. internal process documentation:

• Product documentation for customers can also do double duty for your internal teams on how the product or services work, for training the team
• Doing customer-facing documentation first can help you make the case for internal documentation if measure the benefits while getting your teams in the habit of creating it and using it
• Having both types of documentation and knowledge bases is very powerful combination

Biggest Takeaway

Choosing only one message is tough!

My big message to companies, or for people trying to make a case to start documentation at their company, is that you can’t scale without documentation.

You can’t make predictable, repeatable processes and forecast anything accurately if everyone is doing their work in a different way. If it's not consistent, then you cant improve anything, since you have no idea what is actually happening in the company. 

On the individual level, I do like to emphasize the stress-reduction benefits of documentation, such as being able to take time off more easily. Maybe even getting promoted because if you document your work, then you can improve the work and show that improvement to your manager.

Also, know that getting started, getting over that overwhelm, that is the hardest part. So once you get over that and actually take some action to get started, it's going to get easier from there.

Class information

Travis suggested that people take my classes to get started, they will help. He took one when he had a hard time starting documentation. "It's really hard just to get started, especially something so overwhelming as documentation of every process. If you think about what you do in the course of a day, every day, week by week, there's a lot to it. There's a lot you keep in your head," he said.

"Taking one of your courses actually got me started. It was that force function that I needed to get started so I highly recommend Jen's courses," he said.

 Thanks, Travis!

You can find all versions of my documentation courses here, including live, on-demand, and one-day workshops.

Additional Notes from prepping and from our first conversation

Transitioning from in-house work as an employee to working for myself

Leaving Remotish:

At the same time as making my documentation course, I was also starting to co-create the HubSpot RevOps bootcamp, this time last year [when the podcast was recorded].

So all these things combined with a full time job wasn’t going to be possible.

Also my CEO, Nicole, and I had been trying to figure out my next career step for probably a year before that. 

It was a small company, so there was no room for moving up further. Or that would have required managing people again, which takes too much energy for me as an introvert.

I learned that I can help more people, at a greater scale, through creating these learning products and programs like courses that anyone can benefit from, more so than I can help by being the manager of a few people. 

Or by helping a small company create what I call human-centered operation programs like knowledge management, onboarding, etc.

I was going to be able to help more people by offering this educational content on my own to multiple people in multiple companies.

That fueled my decision to leave my last regular full-time job.

Travis asked about the transition from working in-house to working for myself:

It wasn’t that much of a transition, my days looked very similar since i was working remote flex time at my last job.

I was still on Slack and LinkedIn a lot, though now the research and thought leadership was for myself and unrelated to another company. I stayed involved in the HubSpot community in all its locations because of my (volunteer) work with Hubspot Academy.

 So I felt connected to a lot of the same people, and I was doing a lot of the same types of daily activities. One good difference was that I didn’t feel that pressure to be available for other people’s questions to help my team all day, which was a nice relief. (Though I know they had documentation to answer most questions, I still wanted to be helpful…)

I’ve worked for myself before, I had my own business before Remotish, so that wasn’t new to me. I like creating and building so the practice of building a business is interesting to me. I’ve been improving on what I did last time when I had a business. 

Are there any common questions or hot topics related to documentation?

How to make time for it, accountability when it's not urgent

My first advice is to not feel bad, it is very common issue and common question. You're not alone in this struggle!

Think about what works for you to actually do other types of ongoing never-ending work like networking or learning. 

What works for you, to remember to make time for that? Think about that because documentation is similar, it is ongoing, not urgent. 

It's only urgent when you need to train someone on a specific process next week, or someone’s leaving the company and you need to get their processes documented first.. there are very few occasions of urgency.

My suggestions on how to make time for documentation are

• Set up a system for yourself to ensure you make the time for it - calendar blocking, recurring tasks in a project management systems, use reminders, notifications, maybe all these things combined
  • Don’t rely on memory or motivation, rely on a system
• Remind yourself WHY you want documentation to be done, what your future will look like 
  • Future you will thank you!
  • For you, Travis, it sounds like the why is delegating work to grow the business and have more time for yourself
• If you’re at a company larger than one person: Remind yourself that because of the communication habits and systems you’ll set up, other people are going to see you doing or not doing this work 
  • That can hold you accountable 
  • This is useful if you want other people to be involved in creating and using documentation, if you don’t want to do it all yourself forever
• Get leadership buy in, if the roadblock is your manager doesn’t want you to spend time on documentation 
  • That is a whole class session I have on overcoming objections by educating those people on the benefits of documentation, time spent now vs later. Look for a future blog sharing that information. 

Why do companies struggle with documentation?

Several reasons such as:

• It’s hard to measure and prove the benefits in numbers, especially if you’re not tracking time and other metrics in that “before documentation” state of working compared to "after documentation,' so you cant prove the benefits.
  • Especially those important mental health or culture benefits, those are hard to measure in numbers
  • So it can be hard to justify it as a revenue-generating activity 
  • Companies say they don't have time but they aren’t tracking their time, so how do they really know they don't have time…this argument drives me nuts but the time vs. the benefits is often not discussed very well
• It hasn’t been normalized as a normal thing most companies do
  • Some people may have never created documentation in their whole career
  • So the fear of the unknown, change management, all that is really difficult to get new habits into place across the company
  • It causes internal conflict from people resistant to change
  • People may be genuinely unaware of or not believe the benefits since they've never experienced them
• It takes time, it’s a long game to see results and many companies are focused on short-term goals like sales quota this quarter
• They don't realize the costs of not having documentation
  • Especially when team members leave and all that company information about how to do the work leaves with them
  • When the companies re-hires people to fil the role, it's going to take a new person a long time and lots of repeated trial and error to get to the same level of knowledge as the person who left, without documentation
• Overwhelm, the number one cause of not starting anything new
  • It's intimidating and there is a lack of information online about best practices and making it manageable – that's why I made the courses

Should documentation skills be part of the criteria for hiring team members?

Because documentation is not a normal habit at most companies, I wouldn't screen people out of the hiring process who hadn’t done it before, that would not be fair.

But I think what you're getting at is if people can be trained to be documentors, writers, sharers of knowledge, instead of information hoarders or secret keepers who keep all information in their brains...or instead of people who just don't know a better way to work yet... The answer is yes! Training people to use it, the benefits of it, and creating/editing it, it's all possible.

And good news if you’re hiring: it's much easier to learn new habits as you're onboarding to a new job compared to retraining people who’ve been at the same company for years.

What kinds of clients take your courses?

Who typically owns documentation efforts?

It varies a lot depending on company size, which makes my target persona hard to define. There are so few companies either doing it well or sharing that knowledge publicly.

Travis asked if the audience is constrained to ops and marketing or not, It is not!

It is useful for all people and departments across the business.

It’s still my first year or so in business so I’m still working to niche down more in who I am targeting.

Right now, my main products are about process documentation. This topic is relevant for all sizes of companies, even one person companies who want to spend less time working and have less stress about their work, can benefit from it.

Three main personas at the moment:

• Founder of smaller companies 
  • Maybe 20 people or less 
  • Who want to hire and train other people to take over their work reliably 
  •  Who want to spend more time working on the business not in the business  
  • Maybe they are making their first hire to relieve some of their huge workload
  • Maybe they are looking to sell their company
    • What exactly are you selling if you don’t have documentation of how everything in the company works? Just selling the name? Or the individual team members who could leave at any time? (I would love to hear more about this topic!)

• Founding team member, right hand to CEO, operations manager... 
  • There’s a lot of titles this person could have 
  • They are working to improve the company in a variety of ways, such as culture, communication, efficiency, training…all things documentation solves
  • This is like me in my last role
    
    
• Operations team managers at medium-size companies
  •  I don’t have an exact employee size or revenue size or startup/scaleup stage 
  • These managers are looking to help their own team be more efficient, to do more with less
  • Setting up documentation systems and habits for their own team, onboarding and training faster
  • They are less concerned with documentation across the whole company right now. That might be out of their control and influence.

And a lot of agency people because that is both my experience and network. 

Maybe after creating my next employee onboarding product topic in 2024, after that I may dig deeper into agency operations specialization topics. We’ll see what next year brings, what people want to learn about after learning documentation.

What feedback have you gotten from your courses?

Positive feedback!

• Especially since the live courses give:
  • time and templates for people to work on their actual documentation and plan their systems and do actual work during and/or between class sessions
  •  Breakout discussions to learn what peers are doing or struggling with
  •  Feedback from me 

Even if you are someone who feels fairly confident about your documentation, you have it started, you have some kind of a system in place to keep it going, people have found the classes helpful. 

The big thing is that documentation is NOT discussed much online, aside from product documentation, technical customer-facing documentation. 

The lack of findable, helpful content about documentation online is why most of what I did at Remotish was starting from scratch. It took a lot of frustrating and time-intensive trial and error, because it was very hard to find information online about best practices for process documentation. It was especially hard to find relevant info for a small, growing company and not a giant corporation with super fancy niche software like enterprise process mining software. That was the kind of thing I was finding when searching for information online about documentation, knowledge management, wikis, whatever words you want to use. 

So it's valuable to have a place to discuss this topic and to learn what other people are doing. That is something the live courses provide.

For my recorded course, later on, I’m planning to add stories from students who have taken the course about what they chose to document, why, struggles, what helped overcome it, so I can help share stories asynchronously.

Thank you, Travis, for this interview and for taking my course! 

You can read a guide that covers my documentation class topics here.