Admin facepalm

4 awful IT admin styles to avoid emulating

Being an IT admin- there’s no question that it is as stressful as it is rewarding. If you’re not careful, however,  you can end up with a perception by your peers and leaders that you never wanted. Here is a tongue-in-cheek look at 4 awful IT admins that you should strive to NOT be like. This handy identification guide will help you recognize these IT admins in the wild, and show you how to avoid becoming one.

The Bro-Admin

The Bro-Admin is our first archetype- which is less backwards baseball caps and more backwards practices. You can identify a Bro-Admin when you see these traits:

  • Ignores change control processes and makes random changes on production systems
  • Executes scripts and commands that that THINK will work
  • Can tell you exactly what the problem is and how to solve it with letting you finish the description
  • Is always attempting to win the one-up game when talking about some technology
  • Doesn’t care about politics or unofficial decision making structures
  • Confuses “it works” with “it’s done correctly and is well documented”

Bro-Admins can be very dangerous to an IT environment, because they play fast and loose, and they think it’s all theirs.

To avoid being a Bro-Admin, make sure you remember to stay humble, listen to others and try to understand before offering a solution. Also, work within the framework of your team and organization, and, unless you’re the only person in IT, try to get peer review or major or production changes.

(Special thanks to Reddit user /u/almostamishmafia for the Bro-Admin info)

Bro admin
A Bro-Admin in the wild

The Jaded Help Desk Tech

While it’s not glamorous, I have a soft spot for Help Desk and Desktop Support. It’s where I, like many IT people, got started. User support roles like this are advantageous because you become highly visible within the organization. However, only getting called when there are problems can take a toll. A Jaded Help Desk Tech will look like this:

  • Deep, brooding sighs when the phone, IM, or ticket queue rings
  • Muting the user, then telling their neighbor how much of an idiot the user is
  • Not taking the time to properly document fixes for future use
  • Speaking to the user in jargon to purposely obscure, confuse, or show superiority
  • Assigning tickets to the next level of support with no notes or supporting documentation

To keep from becoming jaded, it’s important to remember that the user is just a person, too. They are (hopefully) competent or even an expert in their domain, just not in IT.

Remember to show empathy to users- like by calling instead of IM when you don’t understand the issue or feel annoyed (trust me, this works). Your senior team members are there to back you up and instruct you when you need it. Don’t be afraid to go to them, but make sure you give a good try (use the knowledge base and Google) before you come to them.

The Grumpy Programmer

The Grumpy Programmer (ok, not an admin, but same thing) is one of the oldest stereotypes in IT- and it used to be acceptable, to a degree. These days, however, everyone in the software development stack must be user-friendly. You know you’ve spotted a Grumpy Programmer in the wild when you find a coder who:

  • Doesn’t document or discuss code changes
  • Isn’t familiar with the whole application, just their module
  • Doesn’t jump in to own code mistakes- just blame it on the infrastructure guys
  • Specs out and demands a specific product or solution with no collaboration
  • Doesn’t share well outside their team or reveal programming methods

While a Grumpy Programmer is certainly a cliche, becoming one is not a foregone conclusion. Instead, make communication the cornerstone of your work. Sure, it’s great to be a rad solo programmer, but in big environments, letting others know what is happening goes a long way.

grumpy programmer admin
Grumpy Programmer is grumpy

And know this: the SysAdmins are not out to get you. We’ll communicate, and even if we don’t, be the example by being as open as possible on what you are up to. Over-communicate if you need to. Also- it’s best to tell us the end result you want in a server or platform, not the process. This allows us to build you a stable solution to showcase your code.

Be familiar with how the entire application works together. Get your lead or manager involved if you have to. Having a solid understanding of the app is crucial.

The Apprehensive Admin

The Apprehensive Admin is well meaning, but borders on being too timid  to take the needed actions to keep the environment going. They’re the opposite of the Bro-admin, but in all the bad ways, like:

  • Follows rules and procedures to the point of fanaticism
  • Is afraid to make changes of any kind
  • Delays action because of the fear of being wrong
  • Doesn’t speak up, even when they have the answer to a problem
  • Dooms projects to death-by-over-research

To be successful as an IT admin, you have to take some (calculated) risks. You can mitigate these by taking backups and snapshots and getting peer review of changes you want to make (you’ve already researched them by now). Make sure that if somethings bothering you, verbally say (out loud) what it is that’s making you concerned.

To be successful, your projects and tasks must move forward. As Seth Godin says, “Shipped is done.” Your change or project is no good unless it gets implemented. Researching is important, but if you put systems in place to help you, you will be able to act as well. The best thing here is to get changes into your change control, then tell someone else to look at it.

Do you see yourself slipping into one of these 4 awful admin archetypes? You don’t have to.

Most of being a great admin is involving other people- it’s not something you do alone. Keep vigilant, stay awesome, and do the occasional health check to make sure you stay that way.

Like what you see? I strive to help IT people (new and not-so-new) improve their IT careers! Make sure to subscribe at the top of the page to stay up to date!


Main Photo Credit : Sankt Andreas 


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.