Ask HN: How to Deal with IT Gatekeepers?

[beams_of_light]

At a few F500 companies now, I've sought to automate repetitive tasks, which often requires access to APIs and/or databases. When I submit requests, I'm often either rebuffed by an outright rejection of the request, or a lengthy conversation questioning why I want or need to do something. Once I provide the reasons for why I want to do something, the conversation typically turns into a matter of compute resource protectiveness or IT saying they're working on similar automation, which never comes. It's like a flow chart in which options lead to a rejection.

How have you handled this sort of bureaucracy?

[ned_at_codomain]

I have done four things in the past when working at / with big companies:

1. [Usually the best option] You escalate to your manager. If they're unsuccessful, they can escalate to sufficiently high layers of management that bureaucracy doesn't apply. You can't always do this, because it requires getting other people to care. It's also kind of expensive -- you only get so many social capital points to spend.

2. [Second-best option] You don't take the first 'no' as the final answer. Most people go away after getting rebuffed once, but if you keep pestering people, they might give in. Again, have to be careful with how you spend social capital.

3. [Not always applicable] If your ask involves an external vendor, this is exactly the scenario where enterprise sales representatives become really valuable. Good ones know how to climb the management ladder and build cases for change.

4. [Generally not advisable] You can sometimes just 'break the rules' and accept some risk of consequences. Some rules are real and inviolable. Others can be nonsense bureaucracy. Need to be sure which you're dealing with and whether your reputation would carry you through if you got in trouble.

[fuzzfactor]

Seems to me that any company that existed before "IT departments", especially those that had stellar computing abilities, only adopted modern IT bureaucracy when it was already too late in more ways than one.

Sometimes too late to make a positive contribution, but usually an overworked IT layer from the get-go who can't make any progress at all themselves without everything conforming to an imaginary "best practice" 100%. Where progress toward the achievement of an idyllic IT operation must be tangible before anybody else gets anything they want ever. Those that lament the company that could accomplish way more before computers than afterward, they move on, or age out and retire, and all that's left is those that accept the BS for some reason or another.

Then you get "modern" companies formed after show-stopping IT was already very common, and they perceive the "best practice" as imitating the bigger, more well-established failures, for lack of any truly shining examples.

I was in a small company imitating a big one and the right move for me was to prioritize something simple that anybody could physically do, like running an ethernet wire to an additional location so the same laptop could be utilized from either desk. Requiring no server action or behind-the-scenes effort from any IT employee whatsoever. After IT proved incapable of timely performance the site manager then justified the relatively negligible cost of more cables, which we ran ourselves to a dozen PC's that had no benefit from being on the internet, since they were not "office machines" in any way. Got this little network air-gapped less than a year before IT got hacked and we came out smelling like a rose. After that we could do anything we wanted on the isolated network, IT only procured the hardware and software we wanted and it was not at their company-wide expense, so they came out ahead and our small profit center could absorb the full cost easily.

[PaulHoule]

You are an ordinary employee of the company and not a vendor or consultant, right?

[beams_of_light]

That's correct.

[PaulHoule]

My take.

The best reason for IT to want to keep a lid on things is to protect personally identifiable information. My employer was an early adopter of "data breaches" because a developer had a copy of our database of staff, faculty and students on their laptop which got stolen. Since a data breach can affect your company, its customers, employees, vendors and the rest of society, you should be sensitive to these concerns.

I don't know about your case, perhaps it is not a concern, but I think the modern IT organization should be thinking systematically about PII and data breaches and one of the best ways to prevent data from being misused is to keep it under wraps.

That said, I see two angles.

(1) Politics. Other people have talked about it, but it is a deep art. I can't give you answers that work for every organization other than you really have to know your organization and all the people in it.

Central IT at my employer used to be terribly disorganized and if you were in some other unit and needed them to do things your odds were about 50-50 of getting good results going through "the process" so I had to develop a new process of "vendor management" which mostly involved getting the names of many people in Central IT who I would call and say "so-and-so (somebody who used to work there who was super respected) said that I should ask you if you can help me" and then if they can't "do you have any idea of who can help me?" and then repeat.

20 years later (which I didn't all spend at this place) they did a total reorg and now if you put a ticket in the ticket system they will really get to it. If you want to get faster results and try my old tactic they would probably call your boss and your boss would tell you to knock it off.

I can't tell you what the official process for your organization is and what the process that really works is, you have to figure that out for yourself!

(2) Technology. I'll note that if you have a web application you don't really need an API. Actually when a web site adds an API they are often doing it to take something away or take something from you. For instance I have a webcrawler for image-based web sites that I made for Flickr that I found worked on Wikimedia Commons without any changes and that I can often make work for a new site by changing a few CSS rules. All these sites have different APIs and it might be more work to write API clients for them. Between web crawling of HTML-based sites and the fact that modern SPA sites often have an internal JSON API you can often script a web application pretty easily. The same can be true for desktop applications which can be scripted through accessibility APIs and such.

Of course you have to consider your responsibility and the politics if you do that.

[jarule]

You're going to break shit. People don't get raises or recognition for having to clean up after you.