Thank you to Carey Picklesimer and Danielle Balestra for inviting me to the One Question at a Time show to discuss one of the most common pain points in marketing operations: creating and maintaining documentation when you're already stretched thin. One Question at a Time showcases short, straightforward, and solution-focused conversations about marketing technology and more.
|
The episode covers these topics (which link down to that section of the blog): |
If you'd rather watch and listen than read the blog below, here is the audio and video:
Introduction
I've had many careers, but a common thread across them is noticing that most companies lack good (or any) process documentation. Documentation is very helpful, and I was usually creating it at many jobs without knowing what it was officially called. Eventually, I created classes on documentation because I saw a gap that wasn't being taught anywhere. I hope the classes help people to create documentation that reduces stress and helps people and companies achieve their goals.
How do you create a documentation habit when time and resources are limited?
Thinking about the part of the question about not having time for documentation, maybe reframing it to think about: what is the cost of not having documentation?
I think some of those costs are that more people will make more errors. This audience of ops people and problem solvers will probably spend more time correcting those errors and putting out fires that could have been prevented if someone had used the documentation. You could have been spending that time doing more strategic work to move goals forward. Instead, you're spending time fixing things that went wrong because you didn't have documentation, or people didn't use it.
Similarly, another time cost is all the time someone spends redoing or re-researching things somebody else has already done. Maybe that person left the company, and they didn't document this type of work.
Employee onboarding is a big process, and there will be extra time and stress on both sides if there's no documentation on how things work. The new people and the people already at the company will all spend more time asking and answering questions if there's no useful documentation.
Similarly, another cost is the frustration of one person having to answer the same question 23 times because documentation doesn't exist or people don't know it exists.
I think it's probably more important to create documentation when you have limited resources, so you're not wasting that precious time making errors, reinventing the wheel each time you do a process, or if team members aren't learning and sharing information with each other about their processes.
Jen's tips on how to reduce overwhelm
Danielle said that sometimes it feels like a huge task to start documentation, especially if it hasn't been done before. It's even scarier when you're that new person noticing things going wrong, and you can't find documentation. And that person who would have the answers is gone. How do you figure this out? And how do you make this process less overwhelming? Is there a way to start documentation and build on it so that there are a few "little wins" along the way? Then, further along the line, maybe at the end of the year, the documentation is complete? What is the timeline you're thinking of for getting good documentation in place? Should people be putting pressure on themselves to do it in a short period of time?
I think the timeline is going to vary so much that it's hard to put an end goal on that, depending on the size of your company, or how much of the company you're documenting for. Documentation is a continuous, never- ending project. That kind of sounds depressing, but think about it as an activity like networking. It's something that's always going to be happening.
I do have a couple of tips to try to reduce that overwhelm. Overwhelm is definitely a real thing I hear about a lot, related to documentation. I have it myself sometimes.
The first tip would be thinking about it as: you don't have to do it all at once. Don't think of it as one big project. You don't have to document all the company's processes at once. You don't even have to complete an entire document perfectly before it is useful. That would definitely be overwhelming. So stop thinking about it as if it's all or nothing.
Maybe you just start documenting one part of a process that you or other people keep forgetting, or something you're struggling with. And maybe you just document that piece of the process first to help people, and the rest of the document says, 'coming soon, we'll fill this in later.' Aiming to be helpful and not perfect because processes are always changing. It's never going to be perfect.
A second point is thinking about how you don't have to do it all yourself unless you're a one-person company, but I don't think we're talking about sole proprietors here; we're talking about maybe small teams. You can spread out documentation work by clearly defining roles so people know how they should be involved. Otherwise, it's a mystery, like: 'Should I make a document? Should I use a document? Should I be approving documents? I want to make a change, but no one knows who's doing what.'
Clearly defining users, creators, editors, approvers, and subject matter experts who might be reviewing the content, can help provide clarity and spread out the work of documentation. Not everyone's going to have every role.
Get out your fun RACI chart, which operations people like to use, for example. (RACI means responsible, accountable, consulted, and informed.)
Carey asked whether there was a preferred platform for this information, though you could do it in a Google Sheet.
I do not have a preferred way. I would say using tools you're already using, so you don't have to teach people to use a new tool on top of a new habit, because that's like two hard things to do at the same time.
One more note about overwhelm: you don't have to rely on memory to remember to do the documentation. The documentation is supposed to serve as your memory. But I suggest building a system to make it easier to know when to create and when to update documentation, so you don't have to rely on your memory. This makes creating and maintaining documentation more efficient.
And I know you just asked about software, but I'm not talking about buying a new fancy piece of software. I know many ops people love to do software research. I like to say software research is usually documentation procrastination. What I mean by system is that we can use our fun ops words of 'orchestrate' or 'architect' a system of continuous improvement that involves project management, time management (like calendar blocking), communication methods and cadences, and document storage.
Another intertwined tip you could put in place today that doesn't take much time to set up is to block some recurring time on your calendar quarterly for documentation improvements and maintenance. Maybe a few hours, one or two days a quarter. Or add recurring tasks for quarterly documentation time into your project management tool. Or if you work in sprints, set up a sprint for documentation creation, review, and improvement every quarter. Those are my not-so-quick tips for reducing your overwhelm.
Danielle and Carey's advice to overcome overwhelm
But I'd love to hear from both of you. What have you found helpful to reduce the overwhelm of documenting?
Carey liked what I said about it's not all or nothing, and to aim to be helpful, not perfect. As a consultant, Carey does a lot of documentation as she's building things. "Often, if I get to a point that I don't know how to document something, it's actually an indication not of the documentation, it's more about the process. So... if you're struggling with it, maybe the process is too complicated. The documentation itself is kind of a language about what you're doing, which can be really helpful in making something simpler and more streamlined," Carey said.
Carey continued to say the biggest issue is that it's hard to get back to it, to review or update. "Sometimes I document, and then it's like this nice little thing that lives on a shelf that I don't go back to."
Danielle talked about how documentation is helpful when you hand off the process or other work to your client, or when onboarding new employees, so they can look at the process with fresh eyes and ask questions. Danielle also talked about how many people document only the expected or usual process and forget to include what happens if something falls outside that normal operating procedure. "That's not [usually] documented. There's like an offside conversation that people manage. So, you should be documenting those pieces. You should document all aspects of how to operate and work together," Danielle said.
Danielle said there are probably different levels of documentation, such as standard operating procedures and technical documentation, which Carey and Danielle do a lot of when building software. Documenting how the program works, how to process it, and why they built things the way they did for it to achieve the outcomes that people are expecting. But there is that people process piece that everyone needs to be aware of.
For part of that people piece, one of the things they did at her last organization was that they didn't name specific individuals in the document because they might not be there in a couple of weeks, a couple of months, a couple of years. So it was always to the job title in the documentation for who does what and when.
Final thoughts on documentation
Carey then asked whether much of the documentation is actually in a document, like a Word document or Confluence, or if I do much of it in Lucidchart or another flowchart maker.
I think a flowchart is a good addition to the document's written steps, because there are different audiences for it. Some of the flowcharts might be more technical, but others might be more of an overview of the entire giant process. Maybe leadership just wants to see the general steps, but not how to do everything in all the tools, for example. So, I think those two things are good to combine, documents and flowcharts.
Something Danielle said triggered my memory about something I don't see often in average documentation, but it is super helpful. I include it in the template that I give people. Including a history or context section at the top of the document for that information that is helpful to people, such as: why did we start this process? What are the goals? What have we tried before that didn't work? Why are we doing it this way? Make a space to include things that aren't just the clear step-by-step how-to. Adding this section can also help reduce the number of questions you get about this process because people understand more context.
Danielle said that those are the best conversations when you start a new job, and they're like, "Historically, why do we do this? Historically, this is how this functions."
Carey said this has been a helpful conversation to make documentation less intimidating. So people don't feel like documentation is this other thing in addition to their job, another thing to do. It's really something to incorporate into your daily, weekly, or monthly processes or routines. "I think this idea is not getting overwhelmed or intimidated by creating this big, perfect document that is set in stone and can't be changed; that you have this living, breathing document, and people should feel comfortable diving in. Not having the barrier be some high expectation," Carey said.
Danielle said it is definitely worth creating that calendar reminder to check your documentation every quarter. That's an easy add. Everyone could do it today.
My final words would be that any kind of documentation is probably helpful. I would say to reduce the overwhelm, doing it as you're in the flow of work, as Carey and Danielle were talking about, that is super helpful. And if you get to a sticking point, add that 'in progress,' 'coming soon,' 'I'm still working on this part,' note to that process, and just keep going.