The Processes of Babel

The other day, a colleague suggested codifying and articulating a series of guidelines for us to follow at Highland. Guidelines around topics such as inclusivity, acceptance, technical quality, commitments, etcetera.

“Great idea!” I said, “Throw it up in a repo somewhere and open it to pull requests. I’ll help!”

He responded in the affirmative. A moment or two passed and he added, “We may want to use [redacted] instead. I like the collaboration tools in there better.”

“Hmm,” I responded, “On second thought, we may want to use [redacted]. We’ve committed to using that organizationally and we’re trying to get away from the tool spread.”

My first mistake was not suggesting the organizationally sanctioned tool.

My second mistake was inadvertently excluding half the team from participation by recommending my preferred tool (git).

Why do we create processes?

Simply put, processes codify the way to accomplish a tactical goal. They allow us to stave off decision fatigue by offloading cognitive energy. Processes allow us to to focus on the content and results of the work, not the means and methods of the work. On larger teams, processes can serve as a form of communal DNA by ensuring that best practices, tooling, and regulatory details are baked in and followed.

My favorite part about processes are all the decisions they replace. Making decisions takes energy. We shouldn’t have to do the same research, hold the same meetings, and make the same decisions over and over. When processes are well crafted and well maintained, the world sings in harmony. Work seems to do itself.

…and why are we so quick to break them?

When we consciously break a process, I’ve found it is usually for one of two reasons. Either the process is “more work than it is worth” or a crisis is afoot and “there’s no time to follow the process”.

If a process is ever “more work than it is worth”, to me it is an indicator that the process is out of date or out of touch with a more pragmatic reality. Consider revising it or scrapping it altogether. Processes are tools that should serve the people, not the other way around.

In times of crisis processes make for tempting corners to cut, but this is exactly the worst scenario to abandon them. When an emergency occurs, everyone is generally in a state of mild (or extreme) panic. In the early moments of a crisis, your team will have zero situational awareness. Everyone deciding to go rogue will only compound the problems. Slow down. Take a breath. Measure twice. Cut once. Remember that emergency processes should be designed to help you focus on what is important.

Counterpoint

As appealing as “offloading cognitive energy” may sound, it is can also be synonymous with “forfeiting critical thinking”. Overcommit to the idealism of processes and you will drown in a series of low-impact shell games. Chain multiple processes together and it gets even worse. What would have taken someone 5 minutes of focused work suddenly requires 15 minutes from each person on the team! If one person in the team can’t help today, suddenly the issue doesn’t get looked at until tomorrow.

No amount of processes will ever be able to replace a team of smart people working together on a problem. Nurture processes that foster communication between people. Automate the boring stuff, embrace the processes that serve you, and trash the processes that get in your way.