Governance Gone Wild

I've written in the past about change control processes and how they relate to agility. Taking things to the next level, there's a bigger issue that needs to be addressed.

There are essentially two radically divided camps on what value IT Governance provides for enterprise software. These camps are: #1 the business camp which is tired of hearing excuses about why they are losing millions of dollars of business because IT cannot deliver a solution in a timely manner and #2 The IT camp that is tired of the business camp requesting crazy stuff and causing millions of dollars of unnecessary support costs. Camp #1 thinks governance is an excuse for IT/process wonks to slow things down or foot drag instead of delivering solutions. Camp #2 thinks governance is a way to reign in the business folks who believe that unicorns and pixie dust cause fully configured computers and network infrastructure to magically appear over night.

I hope its obvious that both camps are spectacularly wrong. While they both have arguably good reasons for what they're trying to do, I can attest to the fact that it's really (REALLY) hard to see that in the middle of a heated discussion between the two. Governance has often taken on a negative connotation to many because the ivory tower thinkers at many consulting companies treat it like a one size fits all religion where some ultimate authority is in sole possession of knowledge about what "the right thing to do" actually is. In reality, creating an agile, lean, and effective IT governance process is not about finding the right enlightened group with unique insight, but more about communicating vision and verifying that everybody is making decisions in line with that vision.

I feel one problem is that of the word "governance" itself. While wikipedia has a pretty good definition, to most folks, it implies active control. I contend the real goal is inculcating corporate goals to the culture and building transparency into the decision making process. Instead of doing this, though, organizations often relegate the decision making process to "czars", "councils", or "review boards" with the implication that they are somehow more knowledgable about what needs to happen. This is a sure fire way to slow things down, create an overly bureaucratic system, and ultimately get nothing done. It is better to let people do what they think is necessary to further the corporate goals, but develop a system to detect when things are going the wrong way as well as correct and avoid inappropriate activities.

A small example of such a problem would be in typical software change review process. Often, the "controlling" model ends up with a goal to restrict changes or make them difficult with the desired effect of limiting the amount of "bad" changes or "mistakes" someone might make. This can mean things like restricting access to the SCM tool and/or requiring multiple approvers to make a change, it also might mean only certain people can contribute to certain areas and all the administrative access problems this entails. To make matters worse, the approvers/reviewers in this model are often the more/most senior folks in the organization or people who actually don't have any working knowledge to understand what the change actually does. An example would be when a "change review board" consisting of managers/VPs is supposed to review java code changes. In my experience, there is typically no way they can have the time to actually comprehend what the change actually is. This has the effect of demotivating contributors because no matter how hard/fast they work, they can never be better/faster than the reviewer(s). It also implies that the reviewers somehow are smarter or have more knowledge about what is actually supposed to happen. The more obvious problem is that while the process limits "bad" changes, it also limits "good" changes.

A better way to handle this is to make the review process a little more democratic. While there might still need to be a senior person to resolve conflict, developers should be able to review/approve each other's solutions... this could even be done "after the fact", namely, developers can contribute code and move on, letting the review process "just happen" without their involvement (unless there is a question). It also puts responsibility for changes in the hands of people who SHOULD BE most informed about the goals of the change. Put another way, if the VP of Operations (or architecture) has a better understanding of business value of a change than the developer... the system is broken.

The ultimate problem with command and control style governance is that it often ends up turning into a "not my problem" situation. That is, the perception becomes that knowledge of "what is right" becomes reserved to a small group of people and they become gatekeepers whose objective ultimately becomes trying to restrict changes instead of facilitating proper change. People then lose sight of their personal contribution to the success of the organization and it becomes a downward spiral of ineffectiveness.