Posts

Showing posts with the label office politics

The Poor Admin

In the last few years, some of the gains I've made toward making my role more focused on long-term efforts to continually improve and standardize our systems have been rolled back. The organizational details are boring and immaterial to the story; it boils down to the fact my team has less people to do more work, so much more of my time must be spent dealing with the churn of my team's daily duties. As a result, all parts of my job have suffered, and not just in obvious ways. My primary frustration with this situation is IT systems are entropic. They are constantly changing, and without clear and enforced policies, they get more chaotic as they grow. For a couple years, I felt like I was really making progress toward bringing my company's domains to an acceptable level of standardization, many of which we took over after their previous owners failed an audit or were essentially told to give us the reigns because we were better equipped for managing the services associated w...

This Is Why

Just like everyone else, I think it is very common for the contribution of my role to go underappreciated. I can't count the number of times I've been in a meeting with a business unit or other team within the company and heard some version of, "Do we really need to involve the Active Directory team? I mean, it's just managing a few service accounts and groups. I feel like we can take care of that." Because of our track record (and those of some of those business units), my team is pretty fortunate to mostly get auto-approval from management to manage directory resources now, even when those questions come up. A recent situation reminded me why. A little background: we have a business unit that was spun up as part of a DevOps initiative several years ago. In that spirit, they requested elevated access over significant portions of the domain they requested. I fought back against the request, but was overruled by a senior director who shied from conflict of that...

Case Numbers Are (Mostly) Meaningless

If you work in an operations center that receives or routes requests, your life is probably dominated by case numbers. You see them all day, and they likely represent the most granular version of a work task for you. They are invaluable to your job and allow you to quickly look up required information. Unfortunately, when you contact me (a systems administrator), only giving me a case number is almost worthless, especially when I may be away from my workstation. That made sound hyperbolic, but it's true. Whereas that number represents a completed task to you (transferred to a queue), it doesn't help me do any part of my job or tell me if I can even help the person who put in the case. It's just a random number. It never ceases to amuse and annoy me when someone from our operations center calls me (especially off hours), tells me they've routed a case to my queue, only gives me the number, then seems prepared to hang up, thinking they've done their job. Here ar...

A Day in the Life: The Code

A while back, my team was asked to take over a domain from a business unit that had built one, then realized it was more difficult/complex than they thought. I was asked to do an urgent reorganization, ripping out directory access and forcing them to use the least permissions principle. We barely made the deadline, and even though I did my best to explain to them the fact that they would no longer have carte blanche in the domain, they were surprised and annoyed to find they couldn't create service accounts or do other customer onboarding tasks. Just like I've done dozens of times before, I worked with them to define their undocumented processes, focusing on the ones for which my team would be responsible going forward. During this process, I noticed they were using a very simplistic naming scheme for their customer resources, including a 3-character alpha identifier for service accounts and groups. After asking, I was told this code was based on a single physical location of...