Embedded systems engineer here, and we have the same problems with lack of local admin access when it comes to getting hardware and software configured, although to be fair to our local IT team they do understand only too well the problems the "no local admin rights for anyone except IT" policy is causing for R&D users, but it's part of the IT requirements set by our parent organisation as a blanket policy across all the group companies so they've no choice but to go along with it.
Every evaluation board, devkit etc that has a USB connection wants to install its own vendor-specific driver, diagnostics cables might also then require you to tweak driver parameters to fine tune the cable performance to the needs of whatever it is they're connected to. And every so often you find yourself needing to use unsigned drivers - there was a period of time where I was having to do this so often during one particular bit of product development, that I ended up dusting off a spare W7 laptop from home just so I could run this particular setup without having to constantly jump through the crazy hoops required by W10.
Engineering software then often feels like it's stuck in a timewarp when it comes to installation processes, and that's just considering the stuff that's still in active development and could therefore have been brought up to date if the developers could only be bothered - where legacy product support is concerned, the need to run legacy design software (whether it be commercial such as a compiler, PCB design tool etc., or something in-house like a production test tool) often goes hand in hand. Then there's the older niche design tools you've been using for years/decades, which still do the job just fine and which you can use without giving them a second thought (none of this "oh look, it's a new version with yet another new UI redesign" crap that seems to be so in fashion these days), which you really don't want to have to do without or try to find a comparable alternative.
At a general, abstract, level I get why IT teams are keen to not dish out admin access to ordinary users, and in an ideal world I'd be only too happy if I could do my job effectively without ever needing to try and remember what the bloody admin password is, but when these policies come crashing up against the real world requirements of certain types of development environments and in turn prevent certain classes of user from being able to do their jobs effectively then there either needs to be an acceptance from whoever's setting these policies that there are some users outside of the IT team who may well need additional rights beyond the bare bones essentials given out to everyone, or an understanding from management generally that applying these policies without exception *will* lead to random reductions in productivity from those users as they wait for IT to configure something that they used to be able to do themselves, often at those times when you're expecting them to come up with results ASAP.
Biting the hand that feeds IT
