What would you rather have? Repeatable success or luck?

Understanding what makes you successful is hard.

The business world is full of people who had a good run until they abruptly ran out of cash. As the fine print on a mutual fund reminds us: “past performance does not guarantee future results”. Your success so far is not guaranteed to continue unless you understand it and can take actions to reproduce it.

Fortunately the repeatable part is quite simple! It’s also what enables you to learn about what makes you successful. In fact, the more consistent you can be in your organization, the easier it is to see the effect of trying something new. Essentially, you are conducting experiments against existing processes. But first, you have to get these processes in place.

There are three steps to having a process:

  1. Start with what you are currently doing
  2. Document it
  3. Make a process for improving the process

The first step is to write down what you currently do.

Don’t worry! The process you start with will not be perfect. But at first, don’t spend any time up front trying to fix it. The goal here is the consistent part – success comes later. Do your best to think through each step in as much detail as you can and write it down.

Once you have done this, add a procedure for amending the process – otherwise it will become a millstone, not a surfboard. The amendment process should include how changes can be proposed and how they can be ratified by the team.

If it isn’t documented, it is not a process

Having a documented process means that no permanent changes should take effect until the documentation changes.

This is where teams often run into trouble, because a lot of times employees or managers will want to make “little changes” without documenting them or updating the documentation on the change.  This makes sense from a human perspective, because updating the process is a bit more work. Also, changes in documentation mean co-workers will weigh in and discuss suggested changes.  Often the desire to make small changes without documenting them is a type of conflict aversion — and we humans certainly love to avoid conflicts!  Changing documentation for so-called “small changes” can become a sticking point. But stick with it.  Don’t fall into the trap of avoiding process documentation!

If at any point you are regularly doing something that was discussed but not incorporated into the official process documentation then you’re fooling yourself to think that you are following process as an organization. “I’ll get to it” are the famous last words that signal a lack of commitment to process as a concept.

This isn’t to say that no one will ever deviate from process. In fact, that will probably happen as you grow and encounter new situation. But it is important to retrospect these events and determine whether the cause is a process deficiency or simply a mistake. If you ignore process violations, you don’t have a viable process.

The one exception is experimenting to test proposed changes.  These should have a defined duration and criteria for what will constitute a successful test from the outset.  It is also critical to proactively communicate while experimenting and to run few experiments at one time.

How Radial puts processes to work

Here at Radial, we document processes on everything from how to hand off a project from one developer to another to how to work as a developer on a project.

While many of our projects follow similar processes for development, each one will have its own needs and quirks, so processes vary slightly. But having this documented means there’s a very minimal setup every time a developer starts on a new project, since they can pull up the process documentation and follow it to get up and going. This saves the project lead significant time, since most of the common questions new developers would ask are already answered — in the process document!

Radial now has a base of documented processes to iterate on as we continuously improve. It adds value and structure to our work day in and day out. The efficiencies we gain by rigorously documenting our processes make our lives as developers happier. That makes our clients happier too.

Stephanie Ogburn contributed to this article.

agile development code guidelines leadership product development senior software developer software project management