Documenting Your Work - MAC005

One of the things that I often tell my team is "if you're the only one who can, you're the one who always will".  What I mean by that is that if you're a single point of knowledge, as a manager, I can't assign those tasks to anyone else and you'll always be expected to perform it.

For some, that will seem like job security, but when you are looking to advance in your career, it can be career limiting.  As a manager and leader, I am frequently looking for opportunities to assign someone on my team new responsibilities.  But if there is a task that can only be done by one person on my team, regardless of how mundane it is, I am unable to give that person new responsibilities because I need to be sure that they are available for the tasks that only they can perform.

In a pervious episode, I talked about taking on higher level tasks in order to exhibit more value to the organization.  Part of taking on higher level tasks is delegating lower level tasks to more junior team members.  Knowledge sharing sessions are useful, but when the delegate encounters an unknown situation, they must return to you for additional sessions -- which can be disruptive to your focus on other work.  Providing documentation and decision trees provides artifacts that the delegate can reference first before seeking answers from you.  And, when an undocumented situation is encountered, it provides an opportunity for updating those artifacts.  As the documentation is refined, it becomes the handbook for anyone and everyone performing those tasks.

Probably the best documents to start with are Troubleshooting Guides.  Given that the goal is to enable other team members to take on work that keeps you from being able to take on higher level tasks, the most obvious choice is documenting how to solve problems as they come up.  Each process that you own is bound to encounter some sort of problem that the owner (you) is likely the only person familiar enough with the nuances of the process to identify the root cause and quickly resolve.  By documenting what attributes you evaluate during the diagnostic process (reports, logs, etc.) and offering suggestions as to how to interpret them can go a long way in enabling others on the team to assist when problems arise.

Another type of document you might produce is a How-To document.  These are simple documents targeted at a single participant and a single action.  Often they include click-by-click navigation through software with screenshots and descriptions.  It's beyond the scope of the How-To document to identify whether or not the process detailed in the document applies in any given situation, but the document provides all of the details required to complete the action once it has been determined that it does apply.  Examples of these types of documents might be "how to create a user in the system" or "how to restart the automated process after it fails". 

A standard operating procedure (SOP) is different from a How-To in that the SOP is focused on a higher level process and sometimes involves multiple participants.  The SOP starts with a description of the overall goal of the process and then provides a sequence of tasks that must be performed -- often in the form of a checklist or a flowchart.  The specifics of each task is assumed to be understood and may be listed in a more generic fashion so that the SOP applies in more situations.  The SOP could also include steps involving approvals or escalations, depending on how complex the process is.  Additionally, each step in the SOP document could refer to an appropriate How-To document.  Example SOPs could be "Onboarding new employees" or "Process for posting new social media content" or "Process for initiating a new project".

As you start the process of creating these documents, you may choose to document things top down (starting with SOPs and then providing details in How-To documents) or you could choose to document things bottom up (starting with How-To documents and then aggregating them in an SOP).  Regardless of what documents you create and how you create them, they are only useful if they are organized and easy to find when needed.  One tool that may work for you to capture all of these documents is a Wiki.  Wikis can provide a centralized place to house the documents and allow documents to easily be linked from one document to another as well as providing search capabilities.  A Wiki also allows for multiple authors so that as process change or details are discovered anyone can update the documents.

By providing well organized documentation of the things you know, you can enable others on your team to perform them.  This will free you up for other, higher-value tasks which in the end sets you up for advancement.

Are you looking for a career coach? If you reach out to me via the contact form, I will arrange an introductory session where we can talk about your career goals and how I can help. If we're a good fit, we can schedule regular coaching sessions.