The Tyranny of Process Worship Within IT

A recent posting of an internal Netflix guide on its Freedom and Responsibility Culture has generated quite a lot of attention. There are many gems in this 128-page document, from a very straightforward take on what to do with “adequate” performers:

…unlike many companies, we practice “adequate performance gets a generous severance package.”

(in other words, move them out now to make room for star performers), to the mature and enviable vacation policy:

We should focus on what people get done, not how many hours or days are worked. Just as we don’t have a 9-5 day policy, we don’t need a vacation policy.

One of the most thought-provoking views in the document is the treatment of Process, which is described as a necessary evil, to be tamed by an increasingly talented staff over time. Netflix states its goal for corporate culture as:

“…to increase employee freedom as we grow, rather than limit it…”

and within that goal, the organization’s view of Process is framed in terms of an ongoing struggle:

• As the organization grows and becomes more complex, chaos emerges
• Process usually emerges to stop the chaos
• However, the Process model drives more talent out – we can’t let this happen

The solution to this challenge is in increasing talent density faster than the complexity grows, with the end-state of:

“With the Right People, Instead of a Culture of Process Adherence; a Culture of Freedom and Responsibility, Innovation and Discipline”

In this model, Process is to be tolerated, and whenever possible, replaced by great performers who know what they are doing and can figure out how to get things done, without arbitrary rules getting in the way (I do not personally know any Netflix employees, so others will need to comment on whether this view of Process is accurate across their organization).

Contrast this model with that found in most IT organizations of any size. Process is not only accepted, it is celebrated. There is a complex process for everything, from the method for getting approval to build a piece of software, to requisitioning a new server, to the detailed accounting for every activity performed during the work day. One might even go further with the observation that in many organizations, processes are stacked over time, one on top of another, with few processes ever being retired.

Note that in this post I am not referring to BPM, the analysis, representation and improvement of an enterprise business processes, or specific software development methodologies such as Agile. Rather, I am referring to the dozens, perhaps hundreds of smaller, non-mission-critical processes that are created over time in an IT organization. These processes may become the de-facto Operating Model over time.

Peeling the Process onion within an organization may reveal layer upon layer, created over many years. An interview of staff might show that they have little idea why they are still performing certain process tasks. A snap judgement that the staff should have been questioning this waste of effort they were engaged in would be a mistake – in most cases you will find that they have been actively questioning the broken processes, and may have been fighting what they deemed to be wasteful efforts for many years, to no avail.

Seth Godin and others are right in the assertion that every employee is responsible for changing the culture and actions of their company, and need to take responsibility for it. That accountability only goes so far. A responsible employee may try once, or a few times to change a broken process. He may come expertly prepared with charts and graphs and make a formal pitch to try to affect change, or he may just send an informal email to a manager. He may try again later on with another leader, or at another level in the hierarchy. But he’s not going to keep pushing the issue forever, not in an economy where many of his friends don’t even have jobs. Better for him to just sit back and do the drill every day, hoping that the wizards in management will eventually come to the same realization he came to some time ago.

So, processes are seldom retired or removed from an organization, but are very easily added to.  Why?

• We start with an assumption that a process is good and necessary. Rather than looking to our people to fix a failure of service, we assume that a new process is probably needed. If a process really is required, we may assume that it needs to come from management rather than the staff most affected and expert in the operation under review.
• Each of us has a strong bias toward creation rather than destruction. Every new leader tasked with improving the status-quo thinks first about the processes we could build to improve efficiency or lower costs, rather than what needs to be stopped, or torn down.
• Tearing down or stopping an activity could be viewed as an admission that we were on the wrong track as a department, and becomes an opportunity for blame – the process in question may have been created by an individual still in management, and the politics of that attachment add complexity to the review effort.
• Although a particular process is considered outdated by the staff performing it, there may be process outputs, however trivial, that are now used by individuals downstream – a number for someone in finance, or a data element that is input into yet another system. This downstream dependency may create substantial push-back for any changes to the status-quo, even though effort is being wasted upstream by others.

So large-scale process change efforts are undertaken, meetings are held and PowerPoints are created. In the end, success may be defined as making a few tweaks around the edges, with a new layer of process added on to the existing set. Management may then move on to the next project, while the staff tasked with implementation of these new processes shrugs and goes back to work.

So what comes out of this sausage factory? Two similar software products with similar features and quality levels emerge from two different organizations, but one is burdened by a 50% process overhead “tax”. Is the consumer willing to pay a 50% premium for the same product from your company because of unnecessary processes behind the scenes that added no value? No, the only way this works (temporarily) for the process-laden company is to bring other assets to bear – an established brand, significant advertising dollars or a competitive moat of some sort.  Eventually the lean organizations and their products are bought up in the hope that they will be a positive influence for change in the larger, process-heavy enterprises.

Every leader carries around a legend or two about the staff member who was creating reports or dutifully filling out forms, for years, only to find that no one was reading those reports, or the forms were being thrown out with the trash right after completion.

We tell these stories to make the point that every member of our team should be questioning their own activities, and the value they are providing, and that’s certainly true.  But what is our culpability in this issue as leaders?  Did we create an environment where Process was worshipped, or a tool to be used sparingly, always subject to review, and torn down on occasion?  Is our environment one in which questioning the status quo is acceptable and rewarded, or one in which fear rules?  Have we decided as an organization, explicitly or not, that it is probably easier to pay less for staff while expecting less of them, with a plan to make up for it with an extra helping of process?

Do you think this view of Process is realistic?  Why or why not?

Update:  Many insightful comments were submitted for this post – please check them out below.

Your comments are welcome. If this post was helpful, you might like to subscribe to the RSS feed, sign up for weekly updates via email or follow me on Twitter.

Tagged as: Business Process Management