I have recounted the following story at various venues around the country. Each time I tell this story, someone asks me if the story is really true. Let me assure you, it is true. Not only true, it happened exactly the way I have described it below.

 

First the background. My very first IT leadership job was to replace a CIO that wanted IT to be a mystery to the business. To achieve this goal, the CIO and his staff had developed and promulgated a broad range of policies and procedures that were designed to obfuscate IT’s priorities. If someone outside of IT had an idea, there was a policy designed to kill the idea.

 

As I took over IT, one of my first tasks was to make IT more customer-friendly. At almost every turn, I ran into a legacy policy or procedure that we needed to simplify or eliminate. This was long, difficult work. The attitude I was trying to change is typified by the following, true, story:

 

Our standard naming convention for usernames was first initial, middle initial, and first four letters of the last name. For example, my username was nrnick@. . .

We hired a new marketing director by the name of Brad K. Buttars. Brad called me on his second day on the job and asked if we could make an exception to the username convention. He was about to order business cards and realized that the username bkbutt@ . . . might not be the ideal username to have on a business card. “Niel”, he told me, “until I saw it written on the business card order form, I didn’t realize that I really don’t want to be bkbutt.” He went on to explain much of his time would be spent outside the company (apparently, that is what some marketing people do) and was concerned that a username of bkbutt@ would reduce his credibility. I told him that I understood and would take care getting his username changed.

 

I called Ryan, my directory administrator and explained the situation and then asked,

“Ryan, will you please change Brad Buttars user name to bradb@ . . .?”

Ryan responded, “I can’t do that.”

“Why not?”

“It violates our policy.”

“I understand that it does but, in this case, we need to make an exception.”

“But if we make an exception in this case, I will get flooded with requests for exceptions.”

“Ryan, are there that many people that ask for an exception?”

“Well, no. But if they know they can get one, I am sure they will ask for one.”

“Ryan, I will support you in rejecting other requests but it seems to me that helping Brad avoid the username bkbutt is worth an exception.”

“I still won’t do it.”

“You what?”

“You are asking me to violate our policy and I just won’t do it.”

“Ryan, I hate to pull rank on you but I want you to set aside the policy in this one case.”

“I think I should report you for asking me to violate the policy.”

“Report me to whom? The policy police?”

“My boss.”

“Ryan, do I need to remind you that I am the boss of your boss? I feel as if I am on pretty solid ground when I tell you that you have two choices. Either change Brad’s username to bradb or stop being the directory admin.”

 

Ryan succumbed to my threats and made the change. He groused about it for a few months but eventually calmed down (perhaps when he did not get flooded with additional requests for username exceptions).

 

I think of Ryan when I encounter IT dogma and inflexibility. You know, the way we IT types sometimes hide behind policies and procedures in order to avoid meeting customer needs or dealing with market dynamics. I am not proposing that we abandon standards and embrace chaos. Rather, that we use procedures to improve, not discourage, service levels.

 

In our rapidly changing, customer service-centric environments, we need core capabilities of adaptability, flexibility, and innovation. If we hold fast to policies and policies that limit our adaptability, flexibility and innovation, I expect we are limiting our value.