Working Within the System: Notes from a Sysadmin
I’ve been doing this work long enough to watch the same pattern play out over and over. An admin gets handed a problem, sees a cleaner way to solve it, and instead of working the problem inside the structure they were hired into, they go around it. Sometimes that means downloading a tool the company hasn’t vetted, or it means buying a license on a personal card and expensing it later. Sometimes, in the worst cases I’ve seen, it means using the helpdesk team as leverage against management or escalating to outside lawyers to force a policy change.
I want to talk about why that approach is wrong most of the time, when it might be right, and what working inside the system actually looks like day to day.
The job, as I understand it
Our role as system admins is to support the company and grow it. That’s the whole thing. We aren’t here to force the company to our will. We’re here to make the tools work, keep the lights on, and give end users a stable place to do their jobs. When we forget that, the work goes sideways fast.
I see new admins get this backward all the time. They come in with strong opinions about how things should be configured, what the right MDM is, which ticketing system is correct, and they start treating disagreement with management as a problem to route around. It isn’t. Disagreement is normal. The question is what you do with it.
Making changes inside the structure
Most of the meaningful improvements I’ve made for end users happened inside Intune, inside Group Policy, inside the existing licensing. Not by bringing in something new.
Example. A few months back the helpdesk was drowning in BitLocker recovery tickets because users were getting prompted after firmware updates and nobody had documented the recovery key location for them. I didn’t need a new tool. I needed an Intune configuration profile that pinned the recovery key to a self-service portal the user already had access to, and a one-page doc the helpdesk could send. Ticket volume on that issue dropped by about 80% in two weeks. Management was happy. The helpdesk was happy. I didn’t have to fight anyone.
Another one. Printer deployment was a mess. Users were calling in to get drivers installed every time they moved desks. Instead of pitching a third-party print management product (which is what the previous admin had been pushing for, unsuccessfully, for a year), I built out Universal Print through the existing M365 licensing the company already paid for. It wasn’t perfect. It had some quirks. But it was inside what we already owned, so the approval conversation was short.
The pattern is the same in both cases. Find the pain point. Look at what you already have. Configure your way out of the problem before you try to buy your way out. When you do have to buy something, you’ve already shown management you exhaust the existing options first, which makes the next ask credible.
When management gives you a bad instruction
This is the part most admins get wrong, and I’ve gotten it wrong myself more than once.
Sometimes you get an instruction that’s going to cause harm. Maybe it’s a policy that’s going to flood the helpdesk with tickets they can’t resolve, or it’s a security setting that’s going to lock out a department that needs the access. Maybe it’s a rollout timeline that’s not survivable.
The wrong move is to weaponize the helpdesk. I’ve seen admins quietly tell their team to “just follow the policy and let the tickets pile up so management sees the impact.” That’s using your own people as pawns. They get the angry phone calls, they take the heat, and you get to say I told you so at the next staff meeting. It’s cowardly and it damages the team’s trust in you, which you can’t easily get back.
The right move, in my experience, is to push back through the channels the company gives you.
- Bring it to management directly, in writing if you can. Lay out the technical reasoning, the expected impact on the helpdesk, and what you’d recommend instead.
- If management chooses to continue, ask whether you can take it up the line. Most companies have an escalation path, even if it’s informal. Use it.
- If the company doesn’t allow further escalation, or the answer comes back the same, then you implement the instruction.
That last step is the one people choke on. But here’s the thing. If you’ve done steps 1 and 2 honestly, and management has made the call with full information, your job is to execute. You don’t get to overrule the company because you think you know better. That’s not what the role is.
Minimize harm, plan for the recovery
If you do end up implementing something you flagged as harmful, that doesn’t mean you implement it dumbly. You minimize the blast radius, phase the rollout and pre-stage your rollback. You write the helpdesk a runbook before the tickets start coming in, not after.
And you have a backup plan ready for when the issue surfaces. Because it will. And when it does, the person who said here’s what we tried, here’s what happened, here’s how we fix it now is in a very different position than the person who said I told you so. The first one gets trusted with bigger problems. The second one gets quietly worked around.
I’m not saying document everything to cover yourself, exactly. I mean, do that too. But the real reason to document the pushback and the plan is so that when the company is ready to course-correct, you’re the one ready to drive it.
The line
There’s a line, and I want to be clear about where I think it sits.
If you’re being asked to do something illegal, something that violates compliance in a way that puts the company or its customers at real risk, something that’s clearly unethical, you don’t quietly implement it and plan the recovery. You refuse, you document the refusal, and you escalate to legal, compliance, or HR. If those paths don’t exist or are compromised, then yes, external options become real. Whistleblowing exists for a reason. So do regulatory bodies.
But that’s the extreme case. I’ve seen admins reach for outside legal action because management wouldn’t approve a tool they wanted, or because a coworker got a promotion they thought they deserved. That isn’t the line. That’s using legal leverage as a weapon to force the company to do what you want, which is the same failure mode as using the helpdesk as pawns, just with bigger stakes.
The line isn’t I disagree with this decision. The line is this decision causes harm that the company itself, fully informed, would not sanction. Those are very different bars.
What bad actors look like
I want to flag this because I’ve watched it happen. There are people in this field who enjoy the leverage the role gives them, and they look for engineers they can use to do harm to a company they’re frustrated with. They’ll frame sabotage as principled resistance. They’ll talk about “making management feel it” or “letting things break so they learn.” Finally, they will pitch you on going around the structure because the structure isn’t fair.
Some of that frustration is legitimate. Companies do treat IT badly sometimes. Management does make decisions without input that should have been gathered. None of that justifies using your access to cause harm, and none of it justifies pulling your team into a fight they didn’t sign up for.
If someone is pushing you in that direction, they aren’t an ally. They’re a liability, and probably a future legal problem.
The boring conclusion
Most of the time, the job is patient. You configure what you can configure. Ask for what you need to ask for. You document the things you disagreed with so they’re available later when the conversation comes back around. You support the company you work for, even on days when you’d rather not.
It isn’t dramatic. It doesn’t make for good war stories. But over a career, the admins I’ve watched do this consistently are the ones who end up with the authority to actually change things. The ones who tried to force it usually ended up somewhere else, telling a different story about why their last company didn’t appreciate them.