Want to improve IT? Stop saying no
I recently had a conversation with a CIO friend of mine. During the conversation he made the comment that his job was to be the gatekeeper and to tell his peers “No” when they made a request. He then went on to say that Rogue IT was a big problem for him. He seemed shocked when I pointed out that there was a pretty obvious connection. Maybe I should have been more tactful than saying “Well duh”.
It’s funny how many times this happens though. CIO’s, or IT, either are too busy with the day to day work and have a hard time getting to new projects, or are just set in their ways of doing things and don’t want to change. Either way it doesn’t just encourage departments to do it on their own, it almost forces them to do it. Even worse when they do it on their own, often times they will not think about certain things, like a standard architecture, security, authentication, program languages, or integration with other systems. Then when the project is “done” and it becomes critical, they throw it over the fence to IT anyway who then has to manage a system that they didn’t implement, doesn’t match their skillsets and has gaps.
It’s a lose/lose/lose and makes everyone look bad and causes friction between groups. It seems like a no way out scenario, but there is a way to break the cycle. I’ve seen several companies be able to get out of this trap by not saying no, at any level in IT and for any request. In fact the rule is “If the answer is ‘no’, only the CIO can say that. Now not saying no, isn’t the same as saying yes.
Let me give an example. One engineer wanted to create an open wireless network that had full access to our development lab. As he was explaining this I could see the security team, close to tears since this would basically allow anyone near the building to have full access to source code. Clearly not a desirable situation. When the engineer finished his request one of them asked him “why”, and “What are you trying to do with this?” Great questions and worded in a way to foster conversation, not to make the engineer feel stupid or defensive.
It turned out to be a very good reason and they were able to work out a different way, in fact a better way, to accomplish the same thing, using an existing VPN product they were already using. In fact the engineer loved since it allowed him to work on his project remotely and since it was a hot project and he was working weekends on it, he was happy to be able to at least be home instead of in the office.
But in a traditional IT organization, where the CIO thinks his job is to say no, it would have gone down a bit differently. In fact what would have happened is IT would have said no. The engineer who had to be able to get his project done, would have gone to BestBuy and bought a wireless access point and connected it on his own, with no security. Then he would have gotten a bad perception of IT and would never go back to them for anything again and the next time would have figured out how to do it without them too.
I know how hard it is to field every request from your company. In fact I’d be willing to bet it is probably impossible, but if you can have an open dialog and work together it’s almost guaranteed to come up with a workable solution by re-prioritizing some tasks, bringing in outside help, or utilizing existing reosurces in a new role. I’ve seen plenty of times where a finance intern can be trained to create custom reports, which frees up developers to develop. There are plenty of cases where spending some money on automation frees up system engineers from patching servers to implement single sign on. And everyone has a story of where spending some time training power users on something can reduce the amount of tickets, which then frees up someone else.
The great thing is there is always a way, if you start with yes, instead of no. You just don’t know what the way is yet.