Why Digital Documentation Works in Your Favor (And How to Do it Right)
To document or not to document, that is the question.
If you’ve ever managed a large team or complex project, you’ve probably wondered about this as well.
While there are some obvious perks to documentation (which we’ll cover below), it also creates its own work. Hours that can otherwise be spent on creating deliverables get wasted creating documentation that often no one reads.
This can prompt one to think: is digitally documenting all work really important?
In this post, I’m going to analyze this issue in detail. I’ll discuss the pros, the cons, and show you why despite the additional work, digitally documenting discussions works in your favor.
Table of Contents
- The Documentation Pitfall
- Why Documentation Still Matters
- 1. Gather knowledge for future projects
- 2. “Own” your knowledge
- 3. Improve training and hiring
- 4. Reduce redundancies and improve automation
- How to Excel at Documentation
- 1. Make documentation accessible across the organization
- 2. Create documentation for your documentation
- 3. Follow the “Why-What-How” priority scale
- Over to You
The Documentation Pitfall
Documentation has always been considered a best practice, especially if you deal with software or design. The argument in its favor is that it creates a record for posterity and helps keep track of issues.
But excessive documentation also has a major pitfall: it slows the pace of development.
Every time your engineers, designers, and project managers document issues, it means that they have to stop their productive work. An hour spent documenting is an hour you can’t bill for.
The problem is particularly acute in organizations where different teams iterate at different rates. Within a software team, for instance, the developers might be able to iterate at a much faster rate than designers. The latter have to document user interviews, run surveys, and iterate based on best practices. The developers, on the other hand, only have to bring the designs to life.
This difference in the pace of iteration means that work often gets stalled while the slower team spends its time in documentation.
Besides being economically inefficient, this asynchronous pace also means that you can’t implement new ideas fast enough. If design lags behind development (or vice-versa), ideas can get stuck in queues.
The result?
Less revenue and slower innovation.
Not to mention that few, if any, end-users actually care about documentation. If you’re running an agency, your clients will care about the deliverables, not the work you produced to get there. You can fill reams upon reams with your concept sketches and user interviews, but your clients will only want the final designs at the end.
This makes documentation a futile exercise, at least when seen in isolation.
So does this mean you should skip documentation altogether?
Not quite…
Why Documentation Still Matters
The perspective that documentation is redundant can be true, but only in two cases:
- If the project is a one-off and no knowledge from it will be used again
- If the organization will be disbanded in a few years
Most businesses, of course, don’t fall into these categories. If you intend to last longer than a few months in business, you need to invest in making documentation.
Here’s why:
1. Gather knowledge for future projects
It’s an extremely rare business that works on a one-off, isolated projects.
In most cases, you’ll share parts and insight across multiple projects. A software development company might share bits of code across projects. A design firm might use the same framework for multiple clients. And so on.
In the absence of documentation, you have to essentially create everything from scratch. Knowledge remains siloed within a single project team instead of being shared across the organization.
But if you have proper documentation – of ideas, discussions, deliverables, etc. – you have a repository of knowledge to draw from. Instead of making something anew, your team can refer to the work already done before and find solutions. You can create project dashboards that refer to existing knowledge or use automation and templates to simplify repetitive work.
The impact on the pace of development and waste reduction is massive.
2. “Own” your knowledge
Knowledge-based work is tricky in that a business pays an employee to produce knowledge (i.e. intellectual property – IP). While the business might nominally “own” this knowledge, it doesn’t actually control it unless and until it is recorded for posterity.
Think of an employee who knows the critical inner workings of your product. If this employee suddenly quits the company, two things can happen:
- He can take his knowledge to a rival
- The product will start failing since you don’t know how it works
While there are legal protections for the first case, there really isn’t much you can do for the second.
Unless you’ve invested in doing documentation.
Documenting work gets knowledge out of your employees’ heads and into a system that you own and control. It not only gets you real ownership over your IP, but it also safeguards you against employees leaving or switching to different roles.
If a key employee leaves, someone else can refer to the documentation to slot into their place.
This kind of modularity is crucial for any business that wants to scale.
3. Improve training and hiring
Every role you hire has a set of “visible” duties.
But in any sufficiently complex organization, each role also has a lot of unstated, “invisible” duties.
Think of a designer who tweaks an image’s format to be compatible with the CMS before it goes live. Or a PM who changes a report’s formatting to suit a stakeholder’s requirements just before sharing it.
These kinds of tasks are learned through experience and seldom captured in a work log. In project management speak, this kind of knowledge is called “implicit” or “institutional knowledge”.
Hiring and training without understanding the implicit knowledge associated with a role is a recipe for disaster. Implicit knowledge is often the glue that binds well-functioning organizations together. If it’s not passed on to a new hire, existing systems can easily start to fail.
The right way to capture this implicit knowledge, of course, is thorough documentation.
Documenting discussions and work lets you institutionalize your implicit knowledge. Once documented, you can transform it into a process or framework that can be used by new hires. This helps you hire at scale without disrupting your existing systems. It also de-risks your business since you’re no longer dependent on the implicit knowledge acquired by a long-term employee.
4. Reduce redundancies and improve automation
When you start digitally documenting discussions and technical work, you’ll start noticing patterns. Some tasks might be repeated across projects. Some discussions might be the same across multiple clients. And some knowledge is applicable to different parts of the business.
Spotting these patterns and automating or templatizing them is an easy way to improve your efficiency. By creating frameworks and templates, you can also reduce redundancies across projects.
For instance, if all your projects use the same initiation process, you can easily create a “project initiation framework” that includes dedicated templates and tools.
Any organization that deals with a large number of projects or clients can benefit a great deal from such documentation-enabled efficiencies.
The question now is, how do you excel at the documentation process?
I’ll share a few quick tips below.
How to Excel at Documentation
Documentation can be a slippery slope. You can easily get so involved in it that the documentation process takes over your actual work.
It’s also incredibly easy to “over-document” and record issues that no one really cares about.
So if you want to excel at documentation, there are a few things you need to follow:
1. Make documentation accessible across the organization
Your business can’t learn from its documentation if it can’t access the documentation.
Your first priority, thus, should be to create a knowledge management system that’s available across the organization. This can be in the form of an internal Wiki, an internal blog, or even a Dropbox account with Word documents.
Ideally, you should be able to cordon off parts of the documentation based on user roles (you might not want a junior employee to access docs meant for C-suite execs). But a much bigger priority is to ensure that the documentation is both available and accessible to all.
2. Create documentation for your documentation
Yes, you read that right – your documentation process needs its own documentation as well.
As it often happens in any large business, every person has their own subjective standards, layouts, and formatting idiosyncrasies when it comes to recording insight. Over time, this can become a minefield of different fonts, formats, and styles, making it impossible to follow anything.
Which is why you need a detailed process for all your documentation. This should include:
- Templates
- Style guide, including permissible fonts, font sizes, and colors
- Frameworks for capturing and storing documentation
A simple process can help you standardize your documentation, which can make it much easier to follow. It can also encourage employees to share their knowledge by removing technical hurdles (such as creating templates from scratch).
3. Follow the “Why-What-How” priority scale
Instead of documenting everything, adopt the “Why-What-How” priority scale. As per this scale, you would document things in the following order:
- Why action was performed. This helps you understand the context behind the action.
- What was performed? This tells other readers the specifics about the action.
- How it was performed. This gives readers step-by-step instructions on how to replicate the action.
At the very least, you should aim to record the why of any action. The what and the how are both optional. You can record them if you have the time, but if you don’t, then why should give you enough context to understand the documentation in the future.
For example, if you’re documenting your code, focusing on the Why tells other coders the reason behind your exact coding steps. Even if the What and How are missing, other coders can still understand your code.
This helps in keeping your documentation manageable without compromising its utility.
Over to You
Digitally documenting discussions, tasks, and issues is a fantastic way to deal with the problems of scale that affect every growing company. It also helps you future-proof your work, spot redundancies, and get true ownership of your knowledge.
Follow the guidelines above to get help with the documentation process. Once you get the hang of it, you’ll find that it completely transforms your business!
Some of the link on this post may have affiliate links attached. Read the FTC Disclaimer.