← Back

The Habit of Documenting Procedures

Simple procedures for recurring tasks prevent repeated research, reduce mistakes, and free up time for work that adds more value.

Good PracticesHabits

I don’t like repeating work or tedious tasks that have to be done over and over, especially when they can somehow be automated or, at the very least, documented as a sequence of steps. That way, next time you won’t waste so much time trying to remember how to do this or that. If you often find yourself in this situation, know that you can avoid it.

If we really should focus on work that adds value—on tasks that are genuinely creative and productive—then we need to find a way to stop reinventing the wheel. I’m not talking about tasks that simply have to be done (such as filling out a timesheet). I mean this in a general sense, not just from a software development perspective: do everything you can to make these tasks take as little time as possible and, above all, avoid having to repeatedly think about how to do them.

Here are a few examples:

  • The process of publishing a new article on a website: creating the content, choosing the right URL, reviewing the content, checking its structure, proofreading it, requesting approval if necessary, and so on. Yes, that’s several steps, but if you only do this once every few months, you’ll eventually forget and wonder: what was the right URL format again?
  • If you maintain several websites, as I do, and they’re all on Drupal, and you don’t update them constantly (module updates, design improvements, and so on), you may find that every time you update one, you have to investigate all over again how to do this or that: how and where to save a backup, how to tag the new website version in GIT or a similar system, how to check that the update hasn’t broken anything, how to deploy without leaving loose ends, how to check security, and so on.
  • I’ve been using Scrivener to write books for two years. Its compile process generates an eBook, PDF, DOCX, or other file. But after generating it, there are several things to check depending on your workflow and purpose. For example, if you’re generating an eBook for Kindle, you should check that the EPUB passes validation with a tool such as epubcheck. Then you should open it in Kindle Previewer and review it page by page—not to mention the process of publishing it on Amazon.

In short, these are tasks that involve several steps. Unless you have an extraordinary memory, every time you take one on, you’ll forget something.

The result? It won’t be done quite right, it will take longer, and it’s tedious to investigate something just because you’ve forgotten it… And if you look closely, you spend part of your time doing tasks that could easily be covered by a procedure.

For years, I’ve been proceduralizing these kinds of tasks and trying to establish a culture and habit of documenting procedures in the workplaces I’m part of.

At its core, creating a procedure simply means writing a short guide that sets out the steps for completing a task. I’m not talking about companies whose repository of procedures and rules is longer than The Lord of the Rings, but about simple guides you can create yourself to avoid having to remember the same things over and over, and to do them faster and more reliably.

This applies to any personal or professional setting. What would software configuration management be without a procedure that all the developers understand?

If you’re in marketing, you may have a process for documenting upcoming sales activities and their results (= procedures).

It’s surprising how much time you can save when you have simple, practical guides for carrying out tasks of varying complexity.

On the other hand, how could many people in an organization, large or small, work without following certain rules or ways of doing things (= procedures)?

Unfortunately, in many organizations you don’t learn how things are done by reading a welcome document or something similar. Instead, a colleague gets saddled with explaining everything to you—which also costs them productivity.

Here are some of the procedures I use most:

  • Generating and reviewing EPUB and PDF files for publication.
  • Creating content (like this article) on different websites and promoting it.
  • Using code repositories for the projects I work on.
  • Updating and maintaining my Drupal websites.
  • Developing new ideas and proposals.
  • And so on.

If your organization doesn’t have any kind of work procedures, that’s a bad sign. And if you don’t have them in your day-to-day work either—in the way you organize yourself or approach the different projects you work on—that’s even worse.

I’m convinced that the most successful people and best-functioning organizations have a strong culture of creating and using agile work procedures. Of course, overusing them can ultimately produce the opposite of the desired result.