A Beginner's Life

3 Tips For Creating a Megatome

4 min read

Team growth presents a whole ton of challenges. One of them is the sharing of institutional knowledge – how to get the stuff that used to exist in one person’s head into many?

There is no place where this is more crucial than in support. Even for a relatively simple product like ours, there are dozens, maybe even hundreds, of potential support scenarios. Training new folks to handle these scenarios is a herculean task.

Some companies, like MailChimp, solve this with full training programs for new support folks. This is awesome, but we’re still too small for that to work.

When Jordan was first coming on, I was pretty worried about getting him up to speed. I really didn’t want to spend weeks hand holding, to be honest. We hired Jordan because we thought he would succeed in a totally self-directed environment, and would be bored and uncomfortable in a hand-holding, micromanaging environment.

So I started saving some common support questions, and the meat of the answers, into a document. A support tome, I was calling it. After a few days, the content volume grew, and I started to group the questions into categories with their own files.

“We got the Megatome & we are the smartest #sworcery”

With some help with my naming compatriot Max, the name evolved to the Moreau Doctrine (a marriage of two of my favorite things, science fiction and political policy).

Today our support team (myself, Max, Jordan, and Mercer) contribute to the Moreau Doctrine frequently, and new people can get up to speed quickly by referring to it.

I’ve seen lots of guides, internal knowledge bases, and wikis that act like ghost towns – they are lonely places with out-of-date info and stale language. Almost a year in, ours is still fun and vibrant godmode. Here are some of the lessons I learned in the development of an epic internal knowledge megatome.

Go Bare Bones

Don’t save your exact responses in a support email doc. The idea is to transfer the knowledge, not to create canned responses for future emails. I want to empower new folks to respond to emails, not to force them to adopt my voice & tone.

The test I use is, are these guidelines, or directions?

If there is only one correct way for something to get done (i.e. setting up a local version of an app) then of course write up the exact steps.

But if it is something that would benefit from a personal touch (like a support conversation, blanket customer email, social media interactions) then don’t get too nitty-gritty. Communicate your thinking and reasoning, and leave the detailed execution for someone else. Things will almost certainly be different by the time someone references your megatome, trust them to do the right thing.

Make it Fun

The biggest problem I’ve experienced with building a megatome is when it’s there, and it’s useful, but no one wants to use it!

For the love of the children, make sure it’s fun to contribute to. We did this originally by writing the Moreau Doctrine in markdown (which is a really easy way to write text) and tracking it via git. New Customer Champions would be able to learn git while contributing to the doc, which was a fun challenge and they loved using new technology. Double win.

How else can you make it fun? Make sure the contribution process is as easy as possible, track & reward contributions, and, if you build a tool, use the most team-appropriate language possible. Contributing to the Moreau Doctrine sounds a lot cooler than contributing to the Support Communications Knowledge Repository.

Put it in a High-Traffic Area

Make sure your megatome gets contributed to by making sure it gets used. How many times have you dumped important information into a Google Doc, only to see it get lost in the shuffle?

The Moreau Doctrine benefited from being in our Github account – everyone could see it and knew what it was. It also existed as markdown files on our computers, which were easy enough to keep open while we answered support emails.

Now, we’ve even taken it a step further, with Goose, a super-simple Wiki editor Brendan built. He’s been moving towards open-sourcing it, and when he does I recommend using something like that for editing.

So that’s it, that’s all I know. Looking back, most of this advice is pretty simple and perhaps even obvious. But even the obvious stuff has to be fought for sometimes. It’s too easy to fall into the trap of “just throw it together” for tough growing pains like sharing internal knowledge. A little advance planning (and building in fun) will go a long way.

top image credit
pretty much all of this post was inspired by superbrothers: sword & sworcery. If you haven’t played it yet, you should.

P.S. Every week, I send out a short newsletter with links to my favorite articles. When I write a new essay, that will be included as well. Sign up to get your copy.