Event Summary: Operations Nation Documentation ConversatiON with Jen Bergren

Operations Nation (ON), a community-powered knowledge hub for operations leaders, hosted a ConversatiON with Co-founder Charlene Chen and me about how to set up your company for success by getting the right documentation systems in place.

The video is available below on YouTube, and a combination of transcript and interview answers I prepared are below the video. You can watch or read according to your preferred learning style. There were more prepared answers than we had time for in our discussion, so the text has a bit of extra content.

• Getting to know Jen
• What is documentation
• What makes a good documentation process and system and how does that help the company?
• Whose job should documentation be?
• Building a documentation system from scratch 
• Improving an existing documentation system
• How do you influence people to change their habits? -- some of this wasn't covered in the video

• Addressing objections and pitching the value proposition -- not in the video

• Creating a long-term culture of documentation -- not in the video

• Resources to learn more
• Rapid fire questions
  
  

Getting to know Jen 

How did you get to where you are right now? What has been your professional journey?

I am one of the people who wished they knew what operations was earlier in my career journey. Like many people, I fell into it,

My first career was in print graphic design, including a daily newspaper and weekly magazine. It was fast-paced, high-volume work. These jobs all had tight non-movable deadlines with the printers and mailing subscription schedules with big consequences, which required a lot of project management, creating and using templates and other tool/tech efficiencies, streamlining approval processes, and quick problem-solving. Looking back on it, it was a lot of ops for someone with an art degree, but I really thrived in those areas of the job. Getting things done on time and on budget.

While working at design jobs, directing photo shoots made me interested in photography. Long story short, my second career was starting a photography art business, which involved creating, documenting, and running all the processes a business needs. It all had to be efficient since it was only me.

My favorite part of that job was learning about business and marketing, so a few years later, I went back to school for an MBA. I love learning and I also wanted to build more foundational business knowledge about companies larger than one person.

I thought my third career would be marketing, but after grad school, I started working at a HubSpot agency which is now called Remotish. It was their second month in business, so I ended up helping build the business, as one of the first employees. Looking back on that time, it was building the operations foundation of the agency through a variety of client-facing job titles and then management roles.

After about two years, we split off Operations into its own role and department, giving me an official operations title. All ops were mine!  Internal operations at an ops agency, so a lot of ops!

At the end of October 2022, I left that job to further pursue instructional design and other educational content creation. This was inspired by the work I did at Remotish, building an onboarding program and knowledge base, different types of content to help people at a larger scale than training or coaching 1-1, which I think we’ll talk a bit more in a moment.

A common thread in all those careers was having an ops mindset related to repeatable processes, efficiencies,
problem solving, documentation, being super curious and wanting to know how everything ties together, discovering how everything works... but I didn’t know that just doing those things could be a career path on its own until recently.

You can read more in-depth about my career journey in this Linkedin article.

You describe yourself as an Operational Educator - what does that mean to you? 

Operation Educator is the best title I’ve been able to think of to describe what I am doing right now. 

It involves a few things:

• Helping educate operations professionals because it is hard to find courses and other educational content about our work. For example, operations is not just supply chain management, which was the topic of the one operations course in my fairly recent MBA. 
• Giving operations professionals more skills and knowledge to be successful to advance their careers
• Educating the public about what operations does, to elevate it as a profession and get more respect and understanding 
• Helping people pursue operations with more intention earlier in their careers, instead of falling into it like so many of us do
• Teaching non-ops people the operations tactics, such as documentation, that they can use to succeed in any role – ops skills are useful skills to advance in many kinds of careers.

I haven’t seen a lot of education on ops topics other than project management, for example, so there seems to be a need for this educational content, which I think relates to a mission shared with Operations Nation.

See the Operations Nations course for aspiring and first-time Chief Operating Officers (COOs)

What are some of the biggest lessons you have learned during your career?

• Always be learning, no matter what to job is, seek to learn more
• Working at startups or starting your own business is a great place to learn a LOT quickly. I recommend people do both of those things at least once in their career, especially people in operations since we usually need that broad generalist knowledge of how the whole business works
• The biggest companies with recognizable names aren’t always the best companies to work for. At smaller companies, you can learn more and sometimes promote faster.
• Doing a great job probably won't get you a promotion by itself. You also have to advocate for yourself – create documentation for your career and communicate that success. Don’t expect managers or other people to keep track of your wins! Keep track of your own wins so you can make a case for a promotion or new job.
• Leave jobs on a positive note, when possible. Leave documentation so your manager can train and enable other people. For example, in my early design jobs, I was often the first person hired for a new role, a role created to relieve my manager's workload. I didn’t want that workload to shift back to her when I left for a new job, I wanted to help her -- always be helping!
• Remember that you’re working with people, so don’t expect them to behave like machines.
  • Provide different formats of communication to accommodate different learning styles -- visual, text, audio
  • It is not realistic to expect people to remember something they saw or heard one time. You will constantly need to repeat yourself in different formats for the message to get across and for people to respond and take action. As the person doing the communicating, you may get annoyed at having to repeat yourself so much, but remember we’re dealing with humans, not machines.
  • Don’t expect people to remember how to do every part of their job every day. Relying on memory is stressful and not realistic, which is one of the reasons I advocate for documentation.

Documentation 101

What is documentation? 

Documentation is recording who, what, where, when, why, and how to do everything in your company or role. 

And...

Storing that information in one place where other people can find it and use it.

Basically, documentation is any recorded information. Information that is not only located in someone’s head. 

If you need to have a meeting in order to get access to the information you need (by verbal communication) then that info is probably not documented, or the knowledge holder missed the “sharing” step.

Saving documentation where people know where to find it, plus communicating about changes and new items, is knowledge distribution and knowledge management. You are helping people find and use this helpful content.

What makes a good documentation process and system and how does that help the company?

This is a good question. I think the definition of a good documentation system is one that people actually use and keep updated. A system that helps or enables people to be successful in their roles and helps their company to be more successful. Helping people helps the company.

Some of the aspects of good documentation processes or systems include a common theme: remember that you’re not just dealing with documents, for any kind of system, you’re really dealing with people’s behavior.

People are the main component of a system, so it is important to have:

• Clear owners of information, who is responsible for what
• Clear responsibilities, such as when to update or when to create new documentation
• Clear organization of the documentation storage, and the documentation formatting itself, so people can find what they need easily
• Reminders about updating - automated reminders, recurring tasks - get it in front of people, don't make them remember they need to do it all on their own. Don’t make it hard.
• Frequent communication in several channels about new and updated documentation. Keep it top of mind.
• Early adoption by teaching people about using and creating/editing documentation since their first days of onboarding to the company

How does documentation help companies?

Documentation helps companies succeed in many ways!

• • Making sure that knowledge doesn’t leave the company when people leave, so other people can learn from past and present teammates’ efforts. This is related to efficiency, a big responsibility of operations.
  • Offer reduced workloads such as 30-hour workweeks due to efficiency, which helps attract and retain top talent 
  • Onboard new employees quickly, to increase productivity which could increase revenue faster
  • Easily see, agree on, and improve processes
  • Iterate and experiment more efficiently

These are all benefits I saw at my last role at Remotish, for example. Because we documented so much from Day 1, I was able to create a robust onboarding program in year 3 and double the company quickly from 10-20 people in 6 months. Those new team members said they felt supported since they had access to this documentation about how things worked. They didn’t have the burden of figuring it all out for themselves in their first month on the job. They didn’t have to wait for someone to be available to ask in real-time, which would be a bottleneck since we were remote and flex time in many different time zones. 

We also would not have been able to offer that reduced work 30-hour workweek benefit if we didn’t have our processes documented. Documentation enabled our small team of 10-20 people to cross-train and fill in for each other when co-workers were out of office or unavailable (due to only working 30 hours a week). Expecting someone to remember how to do everything in their job and someone else's job is not realistic. We’re humans, not machines.

Why is documentation a must-have?

Charlene talked about how sometimes scare tactics can also be important, what happens if there is not any documentation?

Not receiving all those benefits I just listed would be a problem for many companies.

Mainly, it will be very hard to grow a company past a certain point,  hard to scale, without documentation. 

One small example: At some point, it will be impossible for a manager to train new people and answer their team’s questions in real time, either through Slack or calls, because the team will be too large. 

Another example is your first hires will eventually leave, and if there is no documentation, the next people hired will take a LOT longer to ramp up and figure out what was happening in order to succeed in their role and be productive sooner.  Digging out from that documentation debt before they can begin to contribute more to the company.

And with the current state of people leaving jobs often (in late 2022/early 2023), you’ll constantly be in a training debt or knowledge debt and never be able to catch up to full productivity. Your current team will get burnt out from training people all the time and answering questions, instead of having enough time to get their own work done. 

I read an article about that recently, how this will create a broken cycle, and you’ll never reach the point of scale, that inflection point.

Something else to keep in mind is that though we (in the audience) are ops people and we're good at solving mysteries, untangling messes, inventing solutions...that’s not the strength of every role in the company or every person. Many people would appreciate having clear answers provided to them and not have to hunt down information and ask multiple people like a detective. And even for ops people, 

Solving mysteries or reinventing the wheel every day (due to no documentation) takes time, and solving the same problem more than once is the opposite of fun. And eventually even your ops people will leave the company, and the cycle will start all over again of new employees trying to figure out what was done before and why.

Charlene shared a story about a startup she was at, which had a high turnover for a few reasons. It was frustrating for all employees, especially ones there a long time, because they were spending all their time re-training new employees. Everyone was trying to move toward an OKR but felt like starting from scratch all the time just to get to baseline knowledge.

Whose job should it be? Who should be responsible for documentation?

At the 20-100 person companies that a lot of our audience here works at, the responsibility for getting it started, setting up the system, and overseeing it all would be a good choice for operations people, because of our skill set and also our work that spans horizontally, cross functionally, across the business.

But one of the keys to making sure documentation is kept up-to-date is NOT having ALL documentation responsibilities for the whole company resting on one person or one team forever.

So even if ops is responsible for creating a system that makes it easy for other people to be involved. and ops may be responsible for making sure the work happens, it's important to divide the responsibilities of creating, editing, and approving documentation among the teams who hold the knowledge. Empower them with "knowledge owners" for certain categories of documentation.

There re a few different ways people may be involved in documentation, roles in documentation:

• Using documentation - users
• Subject matter experts who are interviewed to create it
• Creating documentation - creators
• Editing documentation - editors
• Approving documentation - approvers
• Eventually, you should empower teams with owners/managers of certain categories of knowledge

This is a journey to get these roles into place, starting with yourself and then users, which is often the biggest hurdle, getting people to use the documentation. 

Don’t try to put all these roles in place at once.

There is an order I suggest to help you be more successful.

1. Users
   • Have a few beta testers of documentation to make sure the format and system you created is useful
   • Make adjustments based on their feedback
   • Expand to other teams as users
2. Subject matter experts
   • As an ops person, you have broad knowledge of many parts of how the business works. But you may not know the exact details of every process well enough to write instructions on how to do it. So you'll need to gather that info, interview the subject matter experts, in order to write the documentation.
   • Even if you do know everything about how to do every process, getting other people involved in the creation of documentation makes them more likely to use it, to adopt it, if you don’t just hand them documentation and say 'use this, do it this way.' If they feel involved in creating it, it will motivate them to use it.
   • For example, at my last role, my CEO needed to document some of her work to delegate to me and to the other new roles we were creating. But she was busy, and I wasn’t able to write them myself. So I would book a call with her, record it, and have her walk through the process. She'd talk about it while doing it, and I’d stop to ask her questions. Then I could write that first draft of documentation that she could edit, and then someone else on the team could test the documentation to make sure it was clear to them.
3. Creators and editors
   • After you’ve got user adoption fairly well figured out for your team, if you don’t already have one, create a document about how to create documentation and how to maintain documentation, and then start giving other people the responsibilities of creating and editing documentation, expanding your system to include them, to help them be successful.
   • Make sure you document people’s roles, in that maintenance document, so if someone has a question about a piece of documentation or a process, they know who to ask.
   • If you haven't already, make sure your documentation is clearly divided into categories by team, such as sales or marketing documentation, so the boundaries of responsibility are clear for these roles and beyond.
     • However, you may still need one company-wide category of documentation that applies to everyone at the company. You, as operations, may own that category in addition to the operations-specific role/task/process documentation for your own department. 
       • Example: At Remotish we called that general category “ops for everyone” since “general” doesn’t sound very important. If it doesn’t sound important, people are not likely to use it. We were also an operations agency so we were trying to encourage everyone to think of themselves as ops people. And then there was an 'ops for ops' category, to separate that ops-specific work from the general company-wide category. We also had subcategories within these which were more descriptive, like “project management,” for example.
4. Approvers 
   • You may not have detailed knowledge of every team's processes, so having the team's manager be the approver for their documentation makes sense, especially when changes to the process need approval.
   • Example: At Remotish I set up two levels of approvers -- the team manager for the subject matter accuracy and then me, ops, reviewing, to ensure consistency and standardization of the documentation formatting and usefulness.
5. Finally, once all of those roles running fairly well, you can assign knowledge owners for certain categories of knowledge. 
   • Example: At an agency, one person may be responsible for making sure there is enough useful and up-to-date documentation about servicing retainer clients and another person is responsible for documentation about servicing project clients. 
     • Though the services manager/leader would be responsible for holding those people accountable to getting the documentation work done, ideally everyone would be bought into documentation benefits and responsibilities at that point.
   •  At that point, you probably want to build those responsibilities into the job titles and potential promotion levels as well.

See more information in this documentation roles blog.

Building a documentation system from scratch  

Chelener said the audience said this sounds like a lot, how do you get started, especially at a small company?

Start small to overcome the overwhelm, start with yourself, building that system for yourself first before involving those other roles we discussed.

First, let’s talk about what a system is.
The Oxford dictionary defines it as

• 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.

By system of documentation, I don’t mean use Guru, use Notion, use Qatalog, which I know has done some nice partnerships with Operations Nation... I don't mean to use a specific tool.

I mean the people and process working together, that part of a system.

If you skip all the people and process set up, and go straight to choosing a tool and expecting the tool to work miracles all by itself, that is likely to fail. It would be nice if the tool did 100% of the work for you, but that is not realistic when we're working with humans and human behavior.

I suggest setting up this system for yourself first so you can test it to make sure it works for your company, make adjustments, and start to set a good example with proven benefits for other people to follow once you start getting them involved in documentation.

Time management:

Start your system with reserving time to create, use, and improve documentation.

Consider:

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

Charlene mentioned that if you don't make time for documentation, urgent will eat important for breakfast every day.

This can be the biggest hurdle, making time for it. When it is urgent, like you need to train someone before your vacation, there is often not enough time to get it done. So work on it when it is not urgent.

Task management:

• Current tasks in your project management system for building and/or improving documentation 
• Wishlist - “nice to have” documentation for the future, new or improvements
• Quarterly review & updates - recurring tasks, set aside time to go through whole categories to make sure edits were made in real time, hopefully, or make the changes now. Also identify bigger improvements to make tasks for, make sure everything is standardized

Standardization (a tangent during the event, to answer a question)

Set up a template for the pieces of documentation and set up naming conventions.

For naming conventions, I often recommend a question format such as "What it...?" or "How to..."

Test these out when you are making version 1.0 of your own documentation. 

When writing your first pieces of documentation I suggest writing about your own tasks and processes so you can better test the template, naming conventions, all the other things we’re talking about, before involving other people. It will also make it less of challenge to get started if you start documenting your own processes.

See another blog all about writing documentation.

The template (for sale) is available here. You can see it in the video below.

Communication (discussed in the maintenance question in the video)

Set up your communication cadence, channels, and the tools for communication about new or improved documentation or documentation needs and ideas.

• Pick one channel or method or tool to start this communication while you’re building your own documentation system. Test and see what people respond to. Then expand to other channels.
  • Consider a Slack related to processes and templates, or a section in a weekly meeting or internal newsletter. Get it in front of people numerous times, to know it exists and remember to make updates.
• Example of communicating about documentation: “the marketing email process document (link it) was updated with a new approval process”

Documentation Storage & Organization Tools (discussed later in the video)

Exact pros and cons of specific tools may be a good conversation for the Operations Nation community to hear more voices and experiences. 

My recommendations for your first stage or phase of creating version 1.0 documentation, documenting your own tasks and processes: Use the tool easiest for you. Get your documentation started, instead spending 100 hours researching a tool before you even have any documentation. Get the habit of writing, editing, and updating started for yourself first.

When you’re ready to expand your system to include other people, my #1 tip is to use a system your team is already using daily so you don't have to teach them a new tool IN ADDITION to teaching them new habits about creating, using, and updating documentation. Tool adoption is difficult, as many of you probably know from working in ops! Most of you probably have experienced this.

Consider what the team’s current “Home base” for their work.
Where do they currently spend most of their day?
Slack or a project management system may be common answers. It could be different for every company, which is why it's hard to give advice about specific tools.

Can you use that commonly used tool for documentation storage, or can you integrate the storage tool into that 'home base' system so people can access documentation in the place/tool where they already spend most of their time?

So they don’t have to switch to, or learn, a new tool to build the habit of using, creating, and updating documentation. 

After you've set up, tested, and improved the system yourself for a while, you’re going to start to bring in users to test and expand your system. Testing, iterating, and expanding the system in a constant cycle. 

When you bring on those other most active roles, make sure you train them and include them in all parts of the system. Give them what they need to succeed.

Improving an existing documentation system

A question from the audience was about companies with legacy documentation and you need to overhaul it to upgrade it. A lot of the documentation is outdated. Do you have advice of what to do that project to break as little as possible along the journey?

See my other blog about improving an existing documentation system, created from notes from this event.

Change Management

How do you influence people to change their habits? (partially covered in video)

When you are starting to get other people involved in documentation, such as users, think of rebranding documentation as knowledge sharing or enablement. Team members can think about documentation as preventing other team members from making the same mistakes or doing the same research and testing they already did. Thinking of documentation as helping people, not thinking of it as compliance or ruling with fear.

Charlene said sometimes ops is not just about the hard skills of what you do, it's all about emotional intelligence (EQ) and communicating to the rest of your business and influence. You may not be part of the sales team, but you are always selling, you are selling the documentation, you are selling the change and why. Sounds like sticks are not the right approach, so we should use carrots? Can we give "most valuable documenter" awards, have you been able to reward people for great documentation? (See answers below in the 'Reinforce' examples.)

One of the reasons why documentation is so hard  is that it combines interconnected difficult topics such as:

• Not getting stuck in the day-to-day reactive work and making time for long-term work, 
• New behaviors and habits
• Tool adoption (sometimes)

Most of which relate to change management. 

You want yourself and other people to change from what they are currently doing, change how they are working.

My friend Marliese Bartz, a change management expert, gave this simplified 5-step framework:

1. Create AWARENESS of the need to change
2. Move people to a DESIRE to make the change happen
3. Provide the KNOWLEDGE needed to be successful in the change 
4. Confirm that people have the ABILITY to make the change
5. REINFORCE the change to make sure it’s retained

Awareness: make sure everyone is aware there is a problem. Talk about the problem of not having documentation. more than once, In different formats.

Desire: Similar to marketing, you could make an internal campaign about your documentation benefits to help people desire to change 

Knowledge: Give your team the information about how the system works, templates, and everything you built to make this change as easy as possible for them or for the company as a whole. 

Ability: Testing out your system and adding people into it a few at a time, a team at a time, to confirm it works, and improve as needed.

Reinforce: You and managers overseeing everything, knowledge owners performing quarterly check-ins and other reinforcement built into the system, and positive reinforcement such as recognition and praise resulting from all the communication people are doing about documentation, or promotions related to documentation ownership.

• Example: Reward someone by featuring a "wiki of the week" with the names of the people involved, in your regular communication cadence or publically on social media.

Charlene said that sometimes we promote people without giving them management training (a common problem) and we should also add rules about how you can't get promoted unless you're a great documenter. "That is powerful, I hadn't thought about that," she said. She's seen core competency and skills matrixes where to get to the next level it's not just about being the subject matter expert, it's about being able to pass that knowledge and expertise onto others. Documentation would be a really important lever for that.

Addressing objections and pitching the value proposition (not in the video because of time)

There are many objections people have to documentation, and they often relate to time.

Here's a common time objection from leadership, especially in startups:

• 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 or more volume of requests and need for that knowledge, as we hire and grow.
• If we document our experiments as we break things, it will help us not repeat the time & mistakes of past tests. We can use past knowledge for context for future improvements to iterate and move even faster.

Another common time objection:

“I don’t have time to create documentation or to ensure other people do it.”

Suggested responses to overcome it:

• Documentation reduces questions from others, giving them more time to do big work
• Documentation reduces the errors that cause reactive fire-fighting daily
• Documentation reduces the need for meetings (a huge amount of time)
• Documentation allows you to hire and onboard faster to relieve workloads
• Documentation allows you to coach and train more people in less time
• We’re setting up a system to make it easier to see if your team is using/creating it

Creating a long-term culture of documentation (not in the video because of time)

A lot of these efforts that we discussed in setting up the system will help build that culture, especially the communication part of it. All your efforts will tie together and build on each other.

What do you do first to build the culture of documentation?

• Set up communication channel(s) about documentation. Use that channel to explain the benefits of documentation, how you want to encourage knowledge sharing and learning, benefit from efficiency, improve processes, and how it helps them.
• Be specific. What are you starting to focus your documentation efforts on and WHY?  Make them aware of the current problem, which should be positioned as a process problem NOT a people problem. 
• Documentation and transparent communication are not normal, average behaviors at companies. People are not used to it. So make them aware there is a better way to work, and promote a desire to change. Solve the problems by eliminating those knowledge silos and information hoarding, getting out of reactive day-to-day roles, and get them thinking about a future of less stress and fewer working hours, for example.
  
  

Those are the first steps to get that culture started. A few more are:

• Baking documentation into many aspects of work -- job descriptions, project management templates, and more
• Celebrating and rewarding people who do it
• Teaching new employees in onboarding 
• Adding it into any new training for existing team members

What are resources you recommend for those who want to dig deeper?

• I have a documentation class, in a few formats, that goes deeper into these topics 
• Eventually, I will have a resources page or guide on my website (for now, I do have a lot of blogs)
• Be active in great communities like Operations Nation! I've seen some great documentation conversations in there, I know there are a lot of other experts out there.
• Follow Alicia Butler Pierre, she has a book and classes on business infrastructure
  
  

Rapid-Fire Questions Inspired by Brene Brown's Daring to Lead Podcast:

Learn more about Brene Brown :) 

What is one thing you’re deeply grateful for right now?

I am grateful for my friends and family, who I’ve been trying to stay in touch with more as I am entering this entrepreneurial journey again, including my friends in communities like this.

What is the one business tool/software you absolutely cannot live without?

My calendar and project management system for getting my daily work done, but I also have to say HubSpot. Though right now, the HubSpot community and HubSpot Academy education are more influential to me than the tool, for my new business.

Fill in the blank: Documentation is __________________

A secret weapon for growing or scaling businesses, and for making work less stressful because you know what to do in your own job and you know your team is enabled to do what they need to do in their jobs.

Charlene had a good summary of takeaways toward the end of the video:

• Start with yourself
• Start simple, even if it's just a Word doc
• Bring people along with you, help them understand the importance to themselves and to a company
• Continuously communicate, bring people along with the journey as you're going through the change management

Ops people are secret weapons that improve the lives of others, and documentation is one way to do that.

Thank you to Charlene and Operations Nation! See upcoming ON events here.

Most of this event's content is from my documentation class below!

Additional resources

• If you're not yet ready for a course, you can sign up for my weekly "3 things" documentation email here.
• I also created a guide to help make business process documentation easier for you.