Giant Hairballs of Corporate Bureaucracy: The Problem With Teams

One of my favorite books about creativity is Orbiting the Giant Hairball: A Corporate Fool's Guide to Surviving with Grace. For me, it's a great book about creativity under the corporate umbrella. The title of this post is an allusion to the book, but the issue that I'm writing about today doesn't directly relate.

Recently, I came across an interesting document. It was a process diagram, charting the workflow of a business process. As someone who has occasionally found myself wearing something like an IT hat, it's not unusual for me to have a hand in these kinds of things, but what struck me about this one was the process description. Within the process description, there were details like, "and then the form goes into the green folder". In all, there was a surprising level of detail mandating minor aspects of the process.

Several years ago, this process came under management scrutiny for taking way too long. As part of a reform effort, a team was formed to review the process and streamline it. After several weeks of study, review and effort, the team produced this multi-page flowchart diagramming the process. As for restructuring, they proposed adding a step with a pre-process screening to determine whether projects would go through a light version, a medium version, or the full version of the process.

The Myth of Collaborative Reform
This story is just one example of conventional wisdom that suggests that if you put a bunch of people together in a room with an overall objective, that those people will work together to achieve the objective. In the previous example of process reform, each of the members of the team were stakeholders and streamlining the process would mean losing some element or aspect that they had established -- letting go of their good idea.

Democracy. It's a great idea. But if "one man, one vote" holds true in process reform, then "the green folder" may hold the same importance as an actual processing step.

In the case of the process above, one of the key failures took place during the process mapping. Beyond the "what do you do" questions, they didn't effectively capture the why. How is the product of your step used? What are you trying to accomplish in this step? How is your step important in the overall process?

Often, an entrenched process starts out as a rule to achieve a specific objective. Then, over the course of time, the rule is taught to others who don't understand the objective but accept the rule as dogma. Eventually, the dogma of the rule becomes the objective. By this time, the the zealots and the process fundamentalists will argue the importance of adhering to the rule, even when the entire context for the rule has shifted. What happens when your culture is no longer a nomadic populace wandering the desert? More importantly, what happens to "the green folder" when the process becomes electronic?

I know it sounds crazy, but these are issues that you often have to deal with when you try to change things or "move the cheese." Questioning the "why" is a fundamental part of the design process. But often, people don't like to question the why, because explaining the why is a good way to show that you don't really know. It's the difference between learning and memorization. So questioning the why can be a threat to some people.

If you don't understand why, then you can't really reform. You can't simplify because you don't really know what is important -- whether it's process steps, product features, or sales collateral.