Process shouldn't be a dirty word

No matter where you work, if you utter the word “process” aloud, you’re likely to elicit groans. It doesn’t need to be this way, though. Process isn’t inherently bad, but the wrong process is absolutely terrible. Or, as Michael Lopp so eloquently stated, “Engineers don’t hate process. They hate process that can’t defend itself.” The problem is that there’s no such thing as a perfect process.

Wildbit has almost doubled in size in about a year and a half. So almost any semblance of process that existed before 2015 hasn’t held up. With the increased volume of communication, we’ve been going through all of the growing pains of needing to establish a bit more process to keep things running smoothly.

One of the most important changes we’ve made to support “processes” is to recognize much of what we do isn’t about tools or process per se but rather about discipline and focused communication. That isn’t to say that we haven’t had our fair share of discussions on tool selection, but most of our process conversations revolved around balancing communication and distractions. We’re simply too big for everyone to be involved in everything, but we still have the lingering effects of the team being used to helping out everywhere. But enough about Wildbit. Let’s talk process.

Just as too little process can lead to sloppy execution, so too can too much process lead to suffocation, slowdown, lack of innovation, and low morale.

The right process depends on the type of work you’re doing, the size of your team, whether that team is local or remote, whether they’re in distributed time zones, the experience levels of the team, their familiarity with each other, the skill sets of the individuals on the team, the technology and devices used by the team, and even the end users being served by whatever that team is doing or creating. There are a ton of variables.

Just as too little process can lead to sloppy execution, so too can too much process lead to suffocation, slowdown, lack of innovation, and low morale. Even the same team doing two different types of projects may benefit by varying the process. That versatility and adaptability prevent teams from getting stuck in a rut. Too often, when people change teams or companies, they try to fit their new team into their old familiar processes, and it doesn’t work. It might work, but there’s no guarantee. Just because one team was successful with an approach doesn’t mean the next will be.

Process is not one size fits all. A good way to think about this is to look at different sized boats. A single person in a kayak doesn’t need much process. Put two people in a kayak, and they need a little communication, but they’re probably going to be on the same page with little effort. Get a rowing team, and you need considerably more practice, coordination, and synchronization to be effective. Move on to some smaller boats for fishing commercially or even performing coastal rescue missions, and things change again. Get into cruise ships, and it’s a whole other world. They’re all just people on boats, but they have many different attributes that affect how they go about their day-to-day work.

There is no one process to rule them all. The goal is to focus on how to help enable a team to work on the right things as quickly as possible while minimizing mistakes.

Software, or any industry for that matter, is the same. The problems arise when a small team tries to adopt the more complex processes of a larger team or when a large team tries too hard to play it fast and loose with the processes that work for smaller teams. I’ve seen teams with tons of process get nowhere, and I’ve seen teams come together with no previous contact and work miracles in just a few days without any process. To use design terms, it’s not about high-fidelity or low-fidelity, it’s about right-fidelity. Context is everything

So how do you know what the right process is? The only way is to understand the team and the variables that go into choosing a good process. The important thing to understand is that process is a spectrum, and as a team changes, the process will too. There is no one process to rule them all. The goal is to focus on how to help enable a team to work on the right things as quickly as possible while minimizing mistakes. A great approach for this is to define an ideal process but make sure everyone understands that in some cases it’s alright to skip certain steps, depending on the needs of a project. That way, the process can adapt to the needs of a particular situation.

The best way to do this is to start simple, but consciously and deliberately evolve your process organically and adapt with the changes on your team. Some changes take discipline and time, but some changes may never work. If the process is constantly changing, it will never work. If it never changes, it will inevitably become stale. Finding the happy medium is the tricky part.

Ultimately, don’t fear process, but don’t bank on it. Make your process earn its keep. It takes conscious effort, but it should help more than it hurts. Process for the sake of process never ends well.