Phil Simon (@philsimon) tweeted a link to an article in the Harvard business review that talks about the dangers of being “overly tool standardized” within an organisation that I thought was very interesting.

Now, of course, standards are needed, and for a broad range of tools its counter productive (and horrifically expensive) to let everyone just use what they want. The cost of data centers, integration, etc. will be radically more if a company does not bring order to the chaos and the marginal advantages that a very specific or niche technology might have in one department is often obliterated by the increased support costs and integration issues globally.

But if a company looks at these savings that come from standardization, and extrapolates too far, they can fall off the other side of the benefits curve and find that they’re hurting, not helping.

In the article in Harvard business review, the researchers also throw around the term “bitsmith” to describe someone who has both subject knowledge, and the ability to wrangle software, and to even create GASP! custom software that does what the team needs to get done. In many companies, current information technology dogma does not leave much room for people that have the time to be a “bitsmith”.

In many companies “Custom software” is a four letter word. Well, I personally have used it, commissioned it and written it and know that often it can provide fantastic value- I’ve also seen people spend thousands of hours building something that never quite worked when an off the shelf tool a hundred times as good could be bought for a few thousand dollars. It’s a matter of being realistic and learning how to see the difference between a problem that is specific to your industry/situation that could really benefit from some custom code, compared to a problem that is huge, main stream, and solved hundreds of times over by existing software vendors.

What I think can happen is a pendulum swing, where a company goes from “no standards, a jungle of wasteful custom software” to “Thou shalt use/buy only software on the following list.”

The problem is, making a list that contains everything is just not possible. Things change. Stuff happens. It is possible that a single person might need a single piece of software that allows them to understand something, design something, communicate something that will make that software have a truly massive payback, justifying all sorts of pain and config on the part of technical resources and infrastructure.

The challenge, as always, is to have an open, working relationship between those entrusted with establishing and enforcing standards in terms of tools and those who are expected to use those tools to do business. As with so many things in governance, it’s about balance, clear goals, and processes that allow for brilliance, change and creativity while not letting that process become the loop-hole that undermines all those savings standardization brings.