26 ms·

> the dysfunctional bureaucracy of IT I am not here to talk about management-bureaucracy, of which IT depts; same as all other branches one can find in establi

> the dysfunctional bureaucracy of IT I am not here to talk about management-bureaucracy, of which IT depts; same as all other branches one can find in established corporate culture, have more than enough. I am talking about the perceived "bureaucracy" of us tech guys here, aka. following established procedures to ensure smooth running of mission critical systems. Yes, I want things to run through code reviews. Why? Because these things go to a production system that our customers (and thus the companies income) depend on. Yes, I want authentication standards. Why? Because there are a gazillion cryptolockers, and worse, out there, who would love nothing more than to run rampant on a nice and juicy production database.

dalyons 3y ago
Do you have a customer focus? Are you trying to unblock people as fast as possible to solve their legitimate business need? Or are you using these as excuses to effectively say no to anything anyone proposes? If yes to the first, you’re a unicorn in an ocean of IT departments that do nothing but block.
- usrbinbash 3y ago
  > Do you have a customer focus? Indeed I have a customer focus. My customers are the people and businesses who rely on the fact that the production servers run smoothly. And I serve their legitimate business needs, among other things, by not allowing some gung-ho hacked-together unvetted magic spreadsheet to kill runtime performance by performing a blocking query with deep joins that forces the DB server into running a full scan over 10E9's of records. Again, as I said elsewhere, I have nothing against non-IT departments building their own private software. I do the same. But as soon as this software wants to touch the prod-server, or any other part of the infrastructure I am responsible for, it is my job to ensure they meet the same standards as everything else in the stack. And yes, saying "No." when it is appropriate, is part of that job.
  - dalyons 3y ago
    The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve? is there another way we can help you solve for it? Maybe a cheap replica would work for you?" And look, i have nothing to go off but the justifications and choice of words in your replies. But in my experience this attitude of "high priest protecting the gates of production from barbarians(company staff)" is strongly correlated with obstructionist IT departments that everyone resents and tries to work around, and chokes the company. Resulting in the creation of the shadow IT mentioned in many other replies - because IT doesnt serve the customer needs of the employees. You might not care , or see that as your job, but thats exactly the problem that so many threads on this post are discussing.
    - usrbinbash 3y ago
      > The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve? That's the answer that I give immediately after the "No." Look, I get what you are saying. I am not trying to keep people away from the capabilities they need to improve how the whole show works. The problem is, what people in my business "guard" are often complex, critical systems, which themselves don't always meet the standards that their "guardians" would like to implement (just ask about legacy software :D). We have to say "No." and we have to enforce standards and procedures. Because there are a lot of really clever people around in tech, and clever people love to tinker. And that's wonderful! That's the entire spirit that got me into this biz! Take a problem, and build a solution. But things have to work. And they have to work tomorrow, and 2 years from now. And they have to be safe, they have to be compliant with a gazillion regulations, they have to pass audits. They have to be patched, they have to be maintained. And all that still needs to happen even after the guy who built them leaves the company. And they have to work for many many many people who are not tinkerers, who just want to click a button on their phones, and rightfully expect the whole shebang behind that button to "just work". That's why there have to be people who say "No." from time to time. If that happens indiscriminately, and without a care about why these clever people tinker up their solutions, then that's not good, I fully agree.
      - 3y ago
- rockooooo 3y ago
  When I started work at a higher-level IT job where I can start saying yes or no like this, I wanted to say yes to everyone and never be that guy blocking people. I still end up saying no very frequently because people will not want to think about anything not relevant to their specific use case at all (how are you authenticating/who controls the app/what happens when you/the owner leave?/is there a project plan?). I can't count the number of integrations/projects I've already dropped because I asked a few follow-up questions and never got a response. Any business that actually wants to follow the law and reduce the risk of massive data loss or other embarrassing cyber event needs to screen things, ask questions, and sometimes prevent one very smart person from setting up an undocumented rube goldberg machine that will drag down an entire team if they leave and it breaks.

dalyons 3y ago

Do you have a customer focus? Are you trying to unblock people as fast as possible to solve their legitimate business need? Or are you using these as excuses to effectively say no to anything anyone proposes? If yes to the first, you’re a unicorn in an ocean of IT departments that do nothing but block.

usrbinbash 3y ago
> Do you have a customer focus? Indeed I have a customer focus. My customers are the people and businesses who rely on the fact that the production servers run smoothly. And I serve their legitimate business needs, among other things, by not allowing some gung-ho hacked-together unvetted magic spreadsheet to kill runtime performance by performing a blocking query with deep joins that forces the DB server into running a full scan over 10E9's of records. Again, as I said elsewhere, I have nothing against non-IT departments building their own private software. I do the same. But as soon as this software wants to touch the prod-server, or any other part of the infrastructure I am responsible for, it is my job to ensure they meet the same standards as everything else in the stack. And yes, saying "No." when it is appropriate, is part of that job.
- dalyons 3y ago
  The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve? is there another way we can help you solve for it? Maybe a cheap replica would work for you?" And look, i have nothing to go off but the justifications and choice of words in your replies. But in my experience this attitude of "high priest protecting the gates of production from barbarians(company staff)" is strongly correlated with obstructionist IT departments that everyone resents and tries to work around, and chokes the company. Resulting in the creation of the shadow IT mentioned in many other replies - because IT doesnt serve the customer needs of the employees. You might not care , or see that as your job, but thats exactly the problem that so many threads on this post are discussing.
  - usrbinbash 3y ago
    > The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve? That's the answer that I give immediately after the "No." Look, I get what you are saying. I am not trying to keep people away from the capabilities they need to improve how the whole show works. The problem is, what people in my business "guard" are often complex, critical systems, which themselves don't always meet the standards that their "guardians" would like to implement (just ask about legacy software :D). We have to say "No." and we have to enforce standards and procedures. Because there are a lot of really clever people around in tech, and clever people love to tinker. And that's wonderful! That's the entire spirit that got me into this biz! Take a problem, and build a solution. But things have to work. And they have to work tomorrow, and 2 years from now. And they have to be safe, they have to be compliant with a gazillion regulations, they have to pass audits. They have to be patched, they have to be maintained. And all that still needs to happen even after the guy who built them leaves the company. And they have to work for many many many people who are not tinkerers, who just want to click a button on their phones, and rightfully expect the whole shebang behind that button to "just work". That's why there have to be people who say "No." from time to time. If that happens indiscriminately, and without a care about why these clever people tinker up their solutions, then that's not good, I fully agree.
    - 3y ago
rockooooo 3y ago
When I started work at a higher-level IT job where I can start saying yes or no like this, I wanted to say yes to everyone and never be that guy blocking people. I still end up saying no very frequently because people will not want to think about anything not relevant to their specific use case at all (how are you authenticating/who controls the app/what happens when you/the owner leave?/is there a project plan?). I can't count the number of integrations/projects I've already dropped because I asked a few follow-up questions and never got a response. Any business that actually wants to follow the law and reduce the risk of massive data loss or other embarrassing cyber event needs to screen things, ask questions, and sometimes prevent one very smart person from setting up an undocumented rube goldberg machine that will drag down an entire team if they leave and it breaks.