White hat social engineering: How to become an admin of a system
Warning: Half-satire, half-truth
A colleague asked me recently how I got to be an admin of our Jira at work.
He has been trying to become an admin for a while since a lot of his work is related to Jira, but the other Jira admins kept insisting that he either create a change request ticket for every request, or sit with them and do the work together.
All the existing admins, including me, typically respond this way to prevent a slippery slope where there are dozens of admins and no oversight over Jira management. We each have our own domain that the others respect, and whenever we need to change something in another admin’s domain or a shared setting we make sure to clearly communicate what we’re changing. This only works if there’s complete trust between the admins and if they all know each other.
So, how did I manage to get into this “admin clique” while my colleague isn’t able to?
Over the past few years, I’ve managed to consistently become an admin of systems that I care about. Partly, this was because I joined the company early - but then most other early employees aren’t currently admins. Other early employees that were admins for various reasons: they either were part of the selection team for the system, or they asked for it before we had clear policies set, or someone made them an admin by mistake in those early days. Eventually, most lost their admin privileges when we started cleaning up our act as a company.
I thought back and compiled this eight-point plan to become and remain an admin of a system at your work:
Find a problem with the system or its configuration that the busiest (or laziest) admin wants to fix but doesn’t want to handle on their own. Note: this shouldn’t be something that you care about, but something that they care about.
Convince the admin that you can fix the problem and that you’re responsible enough.
Become an admin! But wait, this is temporary: you’ll lose your access on the next cleanup.
Start making good changes to fix people’s complaints. Still to non-controversial actions so no one tries to revoke your access. Make sure to follow up with people who request changes so that they know you were the one who helped them.
Declare that there are too many admins and that there needs to be a stricter policy to define who can be an admin.
Take it on yourself to define (or redefine) that policy and present it to the system owner in your organization. Make sure you fit the new definition and make sure that staple admins are also included. Staple admins are those who are either actually doing important work as admins or people who will make a lot of noise if you try to kick them out. Noise means chaos - which means it’s you who might end up on the outside.
No one remembers why you’re an admin, but you’re setting the rules now so no one can dispute it. Victory!
Make sure to keep helping out anyone who wants to fix problems with the system. If you become a roadblocker, you will allow someone else to do step #1 and you might lose your access when that person reaches step #6.
This sounds like an evil plan for world domination so make sure to remember:
You’re doing this because you care, not because you want control.
Leave the system better than you found it: more convenient for users, more secure, and easier to maintain.
Create trust among admins, and between admins and users, in every step of the process.