Good Process, Bad Process

May 1, 2019

Foreword

As a fun exercise to reflect on how I feel about process, I put together "Good Process/Bad Process." It's written in a similar vein to Ben Horowitz's classic Good Product Manager/Bad Product Manager and Marty Cagan's subsequent Good Product Team/Bad Product Team.

For many companies, attacking complexity can result in a 15%–30% reduction in costs in significant portions of their business. But few companies have earnestly tackled the issue of complexity costs. They may view their complexity as an intractable problem. Many do not fully appreciate the size of the prize that can be won by engaging in this war and most are lacking the battle strategies critical to identifying and removing complexity costs, such as we describe in our book Waging War on Complexity Costs (McGraw-Hill, 2009).

—American Management Association

Good Process/Bad Process

  • A good process enables teams to move faster, by automating manual tasks and communications. A bad process "only takes another five minutes" and slows teams down by adding yet another check box to prove—scout's honor—that tasks are done and communications are sent out.

  • A good process is lean and easily shown to be better than no process at all. A bad process is expensive to implement, overly complex for handling the task at hand, and relies on anecdotal evidence to support its effectiveness. (One incident? Two incidents? Over how many years? How much development time will this take?) This is where the joke comes from: "A programmer is a person who spends five hours automating a task that takes five minutes."

  • A good process has clear steps and is itself a clear step in a larger process that provides value to customers. A bad process is standalone and has little or no relation to the generation of value for customers.

  • A good process is context-aware in the sense that it is usability tested from end-to-end, with every new hire. A bad process feels completely disconnected from all other processes—it is not clear where or when it should begin and where or when it ends.

  • A good process shepherds you through the complexity from start to finish. A bad process requires a sherpa to guide you along the path of what feels like Mount Everest.

  • A good process documents the expected deliverables, thereby providing an easy to follow and easy to search paper trail. A bad process scatters bullet points of questionable integrity into a frothing sea of boilerplate.

  • A good process reduces individual overhead by leveraging data from existing systems and abstracting away problems. A bad process encourages copying and pasting of data from one system to another and puts low-level concerns front and center.

  • A good process is opinionated enough to encourage standardization that can be leveraged for gathering metrics and making data-driven decisions. A bad process values flexibility over standardization and turns meaningful analysis into a natural language processing problem.

  • A good process' raison d'être is self-evident and often has a self-descriptive name like an oil change or a haircut. A bad process has a vague, abbreviated, or esoteric name, like Whipple surgery, BEND-WIMP, or de-frobnicate.

  • A good process has nothing left to optimize or delete. A bad process requires a new process to make process improvements. I wish I were joking.

  • A good process guides us in making safe and intelligent decisions with defaults. A bad process requires an intimate knowledge of underlying systems in order to successfully utilize.

  • A good process is dependable, repeatable, and changes somewhat infrequently. A bad process is impossible to learn because it's never done the same way twice. Is it even a process at this point? When "We're constantly iterating on process improvement!" it's because we still haven't figured it out.

  • A good process draws from the experience of others in the industry who have shared similar experiences, and encourages best practices. A bad process is totally customized, based on unique tooling, and mandates breaking tenets of The 12-Factor App.

  • A good process has information and practices that are well understood and easy to Google. A bad process is confusing and impossible to independently research. "Why are we running into problems that literally no one on StackOverflow has ever encountered?"

  • A good process doesn't solve everything. It is purpose-built for delivering output. A bad process tries to solve every problem and in doing so becomes a Frankensteinian mess: initially well-intentioned, but in the end, a difficult to understand monster.

In closing

The new methods were invented to manage a level of complexity that is completely foreign to me and my work. It was easy to back away from most of this new stuff when I realized I have alternate ways of managing complexity. Instead of changing my tools or workflow, I change my design. It’s like designing a house so it’s easy to build, instead of setting up cranes typically used for skyscrapers.

—Frank Chimero,
Everything Easy Is Hard Again

Process does provide real value, but in any sufficiently sophisticated environment, there is a propensity for this problem of increased complexity and additional processes to snowball.

Scaling communications, reduction in human error, safety, security, time-savings, and maintainability are all tangible benefits to be weighed against development time, complexity, and velocity costs.

When we plan to refactor, outsource, avoid old processes, or introduce new processes, we should take a hard look at what that process is trying to solve, what we value in our processes, and most importantly, what our customers value.