Thank you to Ali Schwanke for inviting me to the Marketing Deconstructed podcast to discuss and deconstruct the counterintuitive or unsexy truth about how fast-moving marketing teams thrive because they prioritize documentation and building systems. We also talk about how to get buy-in and start with small steps to build the processes so your team can execute quickly.
Ali is the CEO and Founder of Simple Strat, a top HubSpot Consultant, and B2B marketing strategist working with clients worldwide, which creates HubSpot Hacks, the #1 unofficial YouTube channel for HubSpot Tutorials.
You can also listen on Spotify:
Documentation: An Overlooked Secret for Scaling Marketing Success
In the introduction, we previewed our later topic of comparing and contrasting when a company has a culture of not documenting vs. a culture of documentation (communication and transparency).
Ali kindly described me as "one of the people that I have in my back pocket whenever I'm thinking about how to get teams to move faster ... I think about you all the time [for how] systems and processes are what make us faster but they tend to be that unsexy truth behind it."
One quick tip to build documentation into your flow of work
I know we have a lot of marketing people in the audience, so you probably use a project management system.
Let your project management system do all the necessary reminding while you're building the habit of documentation.
- Put your documentation links in the details inside recurring tasks or in your task templates
- Add a step for documenting or editing documents to every big project that you do. Add it into that task template as a separate step or task near the end of the project.
When you're building habits, you need a lot of reminding before the actions become unconscious habits. So let that project management system do that reminding for you.
Ali said most of us have those project management tools, but we're usually using just a little bit of the power that it probably has.
The first step in building a culture of documentation
Ali spoke about how the executive team often wants us to move fast, so sometimes, we put off documentation because we just don't have time for it when we always need to get a campaign out the door. To start at the beginning, what is the first thing you would do when helping a company build a documentation culture?
The first thing I would do is see how you're doing things now and note where the inefficiencies are.
Those inefficiencies are usually:
- People reinventing the wheel every time they do something
- People relying on memory
- People making errors since all that rework takes time
- People not doing things consistently among the team
- Client offboarding and onboarding is usually a recurring and inconsistent process for agencies that many different people have to perform
Ali said the visual piece is very interesting because if you can't see it, you have a hard time knowing what's happening.
How do you choose the type of documentation to use?
Ali asked what's the difference between when you need a bulleted checklist of things and more of a visual depiction of how things should flow?
I like having multiple formats, but I don't recommend creating every format at once. If it's easier for you to start with the bulleted list, that's a great place to start. Maybe you're linking that bulleted list inside your more thorough piece of documentation where everything lives, such as the embedded videos, other visuals, all the step-by-step instructions, history, and context that makes sense.
How do you avoid over-documenting or documenting too many details?
Ali discussed two mistakes she's seen: over-documentation at the task list level, and executives not understanding how asking for "just a webpage" requires so many steps, but the person doing the work wants to communicate that there really are 50 steps to get that task completed.
I think continuing to ask the people who are using the documentation along the way is the answer. Ask the users or "doers" of the process if this is too much detail or not enough detail.
Also, as you're running the process, notice where mistakes are made. The mistakes might not be because of the documentation, it could be because of something else, but it's a good thing to check first. For example, do we not have enough detail here? Do we have too much detail, and people are glazing over it? Are there too many steps? Maybe the approval was a separate step or separate task, but maybe your approval becomes a comment on the task itself, that could be a place to streamline a process.
Ali talked about how they do have approval steps, and if the approval action is you have to have a comment before you can proceed, you can actually automate tasks to move forward and get unblocked by just having a comment on or a thumbs-up action.
You can probably figure out some sort of automation for a specific kind of comment, and quality control always should be a step somewhere, which may also be streamlined with this kind of process improvement.
Differences between having and not having a culture of documentation
Ali talked about when people aren't detail-oriented and resist the idea of documenting because they think it slows them down; how do you promote creating a culture of documentation?
A culture of not documenting:
-
People always say, 'Let's jump on a call' to solve problems and nobody writes down or shares the answerof the call or what happened in that call. Nobody knows except those two people
- Everyone's using direct messages, and no one's using public channels, so no one knows the answers to those questions except those two people in that private message
- People are answering the same questions over and over because of the above actions
- That is not a good use of time, especially if you're attempting to move fast
- In remote companies, this can lead to 24-hour or longer delays in answering questions and moving forward with work, bottlenecks depending on work time zones
- In remote companies, this can lead to 24-hour or longer delays in answering questions and moving forward with work, bottlenecks depending on work time zones
A culture of documentation (transparent communication):
- People feel empowered because they know how to find the answers
- They feel like they know what's going on in the company
- They understand how their role fits into other roles because they see all the information and can go find it
- For example, how marketing and sales work fit together and how the processes impact each other
- They are not asking the same questions, but they might be asking better questions to help you improve processes
- Not just 'How do we do this" which is answered in common documentation, but 'Why do we do it this way? Have we thought about xyz?" (which could also be good context to add in and improve your process documentation, what you've tried before and why)
How does a documentation culture help teams move faster?
Ali talked about how the documentation culture is not just having this whole saved folder with how we do things. There's that need for that, but then if we talk about what makes teams execute faster, it's:
- They're not trying to find the answer or wait for the answer.
- They don't approach the same obstacles in different ways
- It may be documented, so every time you approach the obstacle, here are the three ways we solve it
- They ask better questions about why and what they could do to improve, not simply 'how do I do' something
- Making a more proactive culture as opposed to spending time sifting for information for lack of by way to put it
- It makes planning faster since you know what's been tried before
- For example, as an agency coming in to help a client, if we want to move forward on a campaign or create a plan, and it turns out the reason that you can't move fast is because of something that's not documented.
Where do you put the information about what's been tried before?
I recommend having a history, context, changelog, or whatever you want to name it section in your documentation template. usually have a little section at the top of a documentation template where people can click to scroll down (the table of contents), so if they've read the history or context once, they probably don't read it again, so they can scroll down to the step section. That's probably a good place to put it so all the information's in one place.
How do you solve any roadblocks with "version" thinking or explain 'living' documentation?
Ali compared this history or content to developing a software program where you've got different versions of this and so you're almost doing version tracking as you're talking about the history of a process.
I think that's a good way to look at it, but not so much that it is a roadblock about how to make a new version. You can just add a note in that history section about a change to a step or add a note in the document. (Aside from any other change procedure at the company, if it's a major change.). Encourage people to think of this as a living document and not static and unchanging.
We also talked about encouraging people to not think that just because it didn't work in the past in this history, doesn't mean it can't work in the future. Ali talked about noting in a process about LinkedIn registrations for webinars, if things ever change in the future with the algorithm, what worked or didn't work in the past might be a thing to revisit.
How do you document experiments?
Making sure you document any testing and experiments is another good way to fight the objection of 'We move fast and break things." In those cultures, you're also doing a lot of testing and experiments. You don't want to repeat the same experiment that failed unless you change something to try to make it succeed. You won't know what to change because it wasn't documented, or maybe that person left the company (since there is high turnover at those companies).
Ali talked about a session at the Inbound conference a couple of years ago where a former growth marketer at HubSpot talked about his structure of experimentation. Ali did this with some content on our YouTube channel a few times about here's what we're testing, here's where we started, here's the screenshots ...
Ali asked if I have a structure for documenting experiments, and I don't yet, but maybe we will collaborate on creating a template!
How do you prioritize where to start documenting and what to work on right now?
Ali said prioritization is a hidden gem of a skill but if you can nail it, you can move fast.
A lot of the prioritization that I teach is usually for people who are either restarting their documentation or just starting for the first time or starting at a new company. A lot of times I try to tailor that advice for their roadblock, what has prevented them from documenting so far. Some of the common roadblocks are overwhelmed by too much to do, so when do you start? That's the most common fear. Other people not adopting the use or creation of documentation is another roadblock, thinking, why should I even do this work if no one's going to look at it? Then the fear of not getting leadership buy-in, being afraid of leadership saying, 'Hey, why are you spending time on this -- go make some campaigns, go get that email out.'
The prioritizing advice is tailored to those three roadblocks. For overwhelm, the advice is to start small, just to get into the habit of writing the documentation and get a system ready for yourself. For example, choose a small task you do yourself that you can measure the before and after state (time it took, errors, ROI of the process) so you have that data to convince other people that documentation is helpful. And if it's a repeated task, a weekly task, you can improve that documentation every time you run the process. So those are some things to look for in the first tasks that you're documenting.
I usually say document your own tasks first, don't go out and document other people's tasks first, because that is going to add a lot of complexity of like gathering information about how people do this, and every single person is going to be doing it differently, so how do you combine that into one document... that's a hard place to start with documentation. So I recommend starting small to get into the habit, getting your systems and habits set up.
What is a realistic amount of time to devote to documentation?
Ali asked about realistic goal setting, such as documenting one process a week, to build the snowball effect of momentum.
I think one process a week would be a good goal. Eventually after you have your personal system set up, like your reminders and the template that works best for you, then you can start expanding your system to other people and involving other roles. That's really where things start to snowball or scale. When people are not just using documentation and giving feedback about how to make it better, but people are editors, maybe they're also creators, maybe they're just approvers.
Spreading out those responsibilities because a system that relies on one person is not a good system. That will break if that one person is not available or leaves. And it's too much pressure on that person as the bottleneck. You'll need to spread out the responsibilities after testing, after creating maybe 10 pieces of documentation on your own.
Ali said it's like a lot of the work inside a marketing team or a modern organization is how everything if you look at it in totality, is just overwhelming, and so pick a very small place to start. It might be documenting your marketing and sales alignment. Have you agreed upon how many dates and times and whatever it takes to respond? Have you documented how your website forms work? So many times, her team has opened up a HubSpot portal where they've got a form for every page, and there's a bazillion pages, and the form responses sometimes went out to different people, and nobody really went through and said how we should do this. So you can't audit something until you know really what you want to build.
The benefits of a cohort live course vs. on-demand
Ali said I made a really good point about the difference between taking an on-demand course and being part of a live cohort related to the roadblocks of overwhelm, adoption, and fear of of leadership not buying it on. If you went to a cohort of 10 people and you all share those fears, you find out you're not alone.
I do hear about that benefit because documentation is so rarely talked about, so how do you know you're doing best practices or know what are other people doing? Nobody talks about it, everyone's talking about tool usage everywhere. Software information is pretty easy to find in communities and websites, but 'unsexy' topics like documentation are hard to find.
So the live cohort gives you some support and reassurance that you're doing all right, you're doing better than maybe you think you are, and you're not alone. Lots of people have the same problems.
What are some of the more helpful documentation tools?
My favorite tool advice is to use the tool you're already using if possible, especially if you have no documentation. Don't go out doing hours of tool research. That's really procrastinating. You don't need a special tool yet if you have no documentation. Do some writing first of the documentation, which will help you know your requirements of what you need in the tool, such as what kind of features.
Besides that advice, I would say, ideally, use a tool that is or integrates into what your team is already using as their daily place of work. A lot of times, that's Slack or project management tools. Choose a tool where you can either call up the documents by typing something into Slack or link documentation inside your project management system.
Making sure everything comes together so people don't have to go off to another tool that they don't normally use. Because they're not going to do that. They're not going to go off to some new place. Some compies have intranets, but unless that's a normal part of people's process, it's linked inside of emails where and when you need it, people are probably not going off to look in there.
Ali said there's been too many projects she's been part of in a past life where people thought the intranet was going to save the day and never once did she find a company's employees excited to go to the intranet to go find anything.
It takes a lot of work to get an intranet to be used, useful, and updated. it's such a huge thing, and it ends up most commonly not being very useful.
Ali suggested bookmarking something inside of a Slack Channel, like if it happens to be about a client, bookmark process or create consistent reminders within that channel, auto remind, or add shortcuts you know on your sidebar.
How do you get adoption of the documentation use?
Ali said the things we've mentioned so far are showing and telling what you're doing as opposed to having the leadership read your brain. How do you show that value because we're all judged on outputs? We're supposed to drive SQLs at the end, but we have to have processes to do that, so how do you link those two together so that you can tell that story?
I would say have your 'before state' documented, so document how many SQL you have now before documenting your processes. Then, documenting, getting input from everyone about what they are doing now, what's working, and what's not working. Then, once you have the process written, explain to each person what's in it for them. For example, it will help you not have to use memory, it will help you make fewer errors, so you won't have to spend as much time fixing mistakes, and it also will help give you input for improvements. You can't suggest improvements if you don't know what's happening now, or if everyone's doing different things
Then also, put this information somewhere so it's easy for them to access because that's a big roadblock of adoption when people don't know where to go, they don't know where to look.
Then measure the 'after state' of the process, such as how many SQLs you have in a certain time frame after the processes have been documented, adopted, and improved. I don't know how long that's going to be; it's going to depend on the process, but ideally, those numbers have improved.
Any strong correlation you can show between the effect on culture and what was driving that effect or that output would be interesting to leadership.
Ali talked about how, in elementary school, they to make peanut butter and jelly sandwich instructions, so the teacher was being funny, and they put it on both sides of the bread. Kids said no, only do one side. They put the sandwich together wrong. (Fun fact: There is a video of this exercise we watch in my course.)
Ali said that's so much of what we experience now, especially in asynchronous culture. In your mind, you have the way the process should work, but it's never really talked through and delivered. "We found that to be true as we're interviewing salespeople. We even have a diagram, and we'll talk about the process and ask: 'Tell me what it's like for you to follow up on leads?' And this person over here is doing something a little bit different, not enough different that the entire trajectory of the process ends up different, but the results are so much better than the rest of the team. But no one is actually taking the time to dig in and figure out why that is and then change the process for the better," Ali said.
Ali said people ask about documentation tools, and they assume tools are the issue, "but I think they also know if you don't naturally think like this, you just need someone to kick your butt into this direction. Because this is a necessity. You cannot get anywhere without a budget, and if you don't naturally budget, you need a financial adviser and a planner to help you. If you don't naturally document, you need something like this [class]."
My journey to teaching documentation
Ali said I probably didn't wake up after college and want to be a documentation expert, so what did I do along the way to get here?
Looking back on it, I could see where documentation fit in because I had a lot of jobs where I was the first person to have the job. I was taking over work from my manager for the first time, she was delegating work to me. So when I left those jobs, I didn't want to pile all the work back on her, so I would document everything to help train the next person.
Documentation also came into play when I was working a big corporate job. I had five manager changes in one year, so nobody knew what I was doing. I was young, I didn't know that was a problem related to getting promotions. I thought I was doing a good job since everyone was asking me for help. I was helping all these different departments, but nobody knew I was doing all of that. So, documenting all of my work to try to earn a promotion is another benefit and use of documenting.
Then, having my own business, where I'm the only person doing processes, and I don't want to have to remember how to do 10,000 things every day, some of them which I only do once a year, once a month, once a quarter. So documentation played a role.
Documentation really came to the forefront when I was working in my last regular job at a previous agency because I was one of the first employees and I knew that we would be building and hiring people and training them. So we really wanted to document it not only to make it just efficient for ourselves to improve the process and run it well but also for future people we would hire and delegate the work to build the company.
Ali said it sounded like I was the right person to take that job for what sounds like founder brain. A lot of founders have the effect of the messy genius, they are very fast, they break things, they make things happen by sheer will and chaos. But once you get that initial momentum or initial fire going, you have to figure out how to make sure that fire doesn't burn everything down. Ali likes that visual because if you look at engine combustion and the mechanics of how our world works, you do have to get a lot of stuff going to get an initial momentum and energy created. But then, if you don't contain and organize that energy, it can actually be your downfall.
Ali said it seems like I figured that out naturally and loves people's stories where they find themselves in a role just because they figured out that was what the world needed
I didn't even know what operations were until a few years ago; even my MBA only discussed operations as Supply Chain Management, which was not what I would want to do. But it ends up that operations are actually how my brain has worked all along, even in creative-sounding jobs.
Ali wrapped up the episode by stating that one of the first things you can do is make sure you're proving your value. That's key to promotions, and that's key to communication. It especially solves the issue of doing a billion things, and they're not showing up across the organization in the way this person sees it. One person sees this little bit, this person sees this little bit.
Also, documentation helps you, if you are overwhelmed, to make the case for hiring help. If you happen to be an entrepreneur, founder, or manager, make sure that you're asking your team for documentation because you might be missing exactly what's going on with your team when you don't have those systems in place.
Thanks again to Ali for inviting me to chat on the Marketing Deconstructed podcast!
Topics: Documentation, Event, Marketing