When IT says "No"

Raise your hand if you work in an organization with a dedicated IT department. Now lower your hand if you are part of that IT department. Given the make-up of my network, around 75% of the readers have their hands raised.

Now lower your hand if you have never asked something from IT to receive a resounding "No" as an answer.

My guess? Nobody lowered their hand at the last point, not even people who have just started their careers. This post is about the problems with this fact, and what could be done better - by both sides of the story. Due to my experiences and the typical readers in my network the below is mostly focused on use cases of quantitative people like data scientists, actuaries and quant analysts but I believe it can be beneficial for others as well.

Let's first start with what IT should be saying. They clearly should not say Yes automatically, either, that's the single strategy worse than the current one of saying No. IT rules are there for a purpose, and enforcing them is maybe the single most important responsibility of IT. Yes, you read that correctly, even more important than keeping customer-facing things running. Some outage will damage your business, a major leak may destroy it. IT has every right and even the mandate to deny some if not most of the requests they get.

So what should they say then? They should either say, "No, but" or they should say "No, because"

Let's start with No, but. This idea is applicable when IT has quite some understanding of what's driving the request and can readily offer an alternative. Example 1: can I install my own git solution? No, but we can give you access to a git repo in a dev environment. Example 2: can I install SQLite for playing around with SQL? No, but you can use MS Access on your PC or we can give you a user in a dev database server. See the difference? Instead of pushing the users to go ahead with their original request and create shadow IT (and don't even ask next time, just go ahead with shadow IT right away) IT can become the service provider it should be. As an added bonus IT can educate these users in more professional, IT supported tools and processes with minimal cost to themselves. Fun fact: these people then become ambassadors both for the better choice of tooling and for talking to IT instead of going behind their backs. I estimate a good 75% of cases will fall into this category and would be a game changer for most of the enterprises.

So, what if the conditions for the above are not met, i.e. IT doesn't know what's driving the request or cannot provide a readily available alternative? Well, IT should start trusting the intelligence of their non-IT colleagues and explain why they are saying no. This would achieve a couple of things: in the short term it would already reduce the unnecessary back and forth discussions and escalations, in the medium term it would allow the requester to investigate alternatives knowing which aspects to pay attention to and in the long run it would lead to much fewer occasions of asking for things that are not allowed. Notice that the short and the long term benefits are direct for IT, the medium term benefits the requester and all three benefit the enterprise as a whole.

OK, we have said all the bad things about IT there was to say, so what about the requester's side? Well, for starters, do your own research and see if there is some explicit IT policy on the topic of your request. Second, look around on google for the obvious candidates that would mandate IT to kill your request. Last but most important: respect your IT colleagues and instead of fighting, try to help them help you! Think about giving as many details as possible supporting your request so it likely falls into the first category and they can offer you alternatives, or better yet, approach them directly by asking for supported alternatives! If you get a "No, but" then appreciate the effort they have invested to provide you with that alternative. If you get a "No, because" then spend at least as much effort analyzing the reasons as they did in providing them. I know it's "not your job" but you are there to add value and so are the IT colleagues, so job description is secondary and solving the problem at hand should come first. Finally, if you IT colleagues do not happen to be in my network and haven't read this great advise, giving you a simple "No", then try to educate them instead of fighting them. You are much better off cooperating!