Episode #4: How to Create a Knowledge Base
Episode #4: How to Create a Knowledge Base
Sharing all my documentation tips and tricks in under 10 minutes.
I’m incredibly (absurdly? ridiculously?) enthusiastic about documentation.
Part of that is just my personality, but it’s also because I’ve seen what a game-changer good documentation can be.
This first hit home when I started consulting. It was incredibly stressful (in the very early days) to work on poorly documented projects. They were filled with assumptions, misunderstandings, client disappointment, and re-work.
We quickly improved our documentation game, and it was transformative. We now had a clear source of truth for what each project should be, approved by the client before we started building. It also created space to think things through in more detail.
However, each doc existed in isolation. We never had the mandate or scope to create a complete knowledge base for any one client.
Creating the Knowledge Base of My Dreams
When I started my next in-house job and we began a company-wide Confluence implementation, I finally had the chance to go beyond disconnected documentation and build a true RevOps knowledge base.
This video shares everything I’ve learned, including a screen-share walk-through of my team’s knowledge base and tips for overcoming the time deficit that every team faces when trying to create docs.
Why Documentation Is Mission Critical
I shared a bit recently on why docs are so important, and I wanted to expand on it here.
It’s easy to feel that documentation is a nice-to-have, or something we can tackle later, or that someone is pedantic or fussy if they insist on thorough documentation.
This misses the bigger picture.
As knowledge workers, information is core to everything we do. And any one individual is limited in how much information they can have in active memory at any one time.
What happens when this information is no longer immediately accessible to the person that needs it?
They make mistakes: The impacts of these mistakes can be small or catastrophic.
They’re less efficient: A person may still figure out how to complete their task, but perhaps in a way that takes longer. Or they’ll waste a lot of time rediscovering something, potentially interrupting many other people along the way, wasting their time as well.
The company wastes money: All this wasted time costs money, not to mention the opportunity cost of the inefficiency.
In a more extreme case, a company may need to completely rip and replace an entire system, simply because this is cleaner and more efficient than trying to reverse engineer the undocumented work that no one now understands. I’ve seen it many times.People feel frustrated: Let’s not forget the emotional impact of all this. It’s draining and frustrating to work in an environment where everything feels confusing and unnecessarily complex. You never reach that flow state, where things are moving like a well-oiled machine. And I think, for most people, that is intrinsically where they want to be.
You can’t scale: in a small team, it works OK to have one mad scientist who knows how everything works and who can basically do it all. Things may be chaotic, but it’s their chaos. Like a messy room that may seem baffling to an outsider, but the person living in it knows exactly where everything is.
This model rapidly disintegrates once the team grows, and no one else can do anything. You can’t structure a team around individual idiosyncrasies.
The Problem of Time
Now all this being said, most ops professionals need no convincing about the importance of documentation. They get it.
BUT, they are also chronically short on time, and documentation is generally the thing that’s easiest to de-prioritize. Because typically, no one else cares.
In the video, I give a few tips for solving the time deficit. Most of them involve creating documentation in the flow of work.
Answer a question with a document: If someone asks a question, and that knowledge is important, it probably takes only a few minutes longer to create a doc vs. simply writing an email or a Slack message. So invest the extra few minutes each time, and your knowledge base is going to grow quickly.
You’ll also get the incredible satisfaction of sending someone a link to a document when they ask a question. It takes two seconds for you, your colleagues are thrilled, and you look like a pro who has their act together.Make documentation part of the process: Another key factor is to make the documentation part of the design and enablement stages for any new initiatives. This means you document as you go, or very soon after you build something, and don’t consider a project complete unless it’s documented.
Be opportunistic: One of the big obstacles when documenting legacy systems is the intimidation factor. It takes effort to transform complexity into comprehension and then write it down.
But you can also be opportunistic here and bundle it into a project where you need to work on that system anyways.
For example, let’s say you need to make a change to your lead scoring model and want to document it. While you’re in that headspace, you can also document the model as a whole, because the big picture is clear and sharp for you at that moment.
To me this is akin to a home reno. “While I’ve ripped off the drywall, I might us well update that old plumbing…”
Share Your Knowledge Base
If you’ve got an awesome setup at your company, I’d love to see it! Feel free to shoot me a screenshot or video or drop it in the comments.