In my first job out of University I worked in a small hardware manufacturing company in Sydney's Norwest Business Park. I can recall on my first day I was sat down next to my boss at a soldering station. He had just completed explaining a 20-or-so step process that I was to follow to test a bunch of wireless transmitters. There was a huge box of them next to me and I was eager to get started, but to my surprise, my boss asked that before I begin, I needed to write a step-by-step guide on how to do it, complete with photos, and check it off with him... whaaat?

Writing a manual on how to do something didn't seem like my idea of productivity, after all, there was real work testing all these devices to be done!

Several months later, with another 10 or so "how-to" documents resentfully written immediately after being given manual instructions, they hired a new person who needed to come up speed on the role. They were tasked with taking over a bunch of the jobs I was doing so I could spend more time on programming a new product for the company.

Expecting my next week to be written off to training one-on-one as had happened to my boss when I came along, I was surprised (yet again) when my boss said:

Just give them your training manuals and let them ask you if they get stuck. More importantly, give them the original Word Doc files and let them fix up any steps in the process that don't make sense.

Wow.

Having been through that experience so early in my career, I was sold on the values of up-to-date documentation. By putting in a little more effort up-front when all of this was still fresh in my mind, it was relatively quick and easy to write the documents. In addition, I couldn't believe how often I returned back to read my own documentation. The process of testing wireless transmitters on my first day, I didn't do again for 6 weeks, by the time that came around I couldn't remember where to begin, but my document could.

Early on in the process of building CartonCloud, I started to write documentation on how various parts of the system worked. Initially, these were purely technical. Guides written on how various objects and data models behaved that myself and our other developer at the time could refer back to. In time however, I began to produce documentation for our Drivers and Warehouse staff, initially in Word Documents, but this was then ported to the application Confluence so everyone could read, edit and maintain, at which point it became our Knowledge Base.

It's incredible how often we use our own Knowledge Base, and how frequently the topics are updated. While our users can see our Public Knowledge Base, we have other staff-only areas that contain guides on how to do all kinds of processes, from setting up a new developers computer, to HR policies around leave.

While some businesses focus on locking things down and ensuring that only a select few have the ability to make changes, we've focused on opening things up, allowing staff to make improvements to articles, but tracking those changes through page-history.

If your business doesn't have any kind of internal knowledge base, it's easier than you think to get started, just as my boss did.

Next time you're teaching someone how to do a certain task, finish the conversation by asking them to write down the steps. Save this file anywhere it can be shared. Google Drive, Dropbox, or use a tool like Confluence or Media Wiki. If you're asked how to do something that's written down, direct them to the guide and tell them to reach out if they get stuck - before long, you'll find your entire business operation is outlined in a series of manuals, and your staff will look there before coming to you!