Frank
Nearly 17 years at the same organization. Twenty-eight years in enterprise IT total. I have troubleshot Exchange (Microsoft Exchange Server) hybrid routing at 2 AM, rebuilt Active Directory (AD) objects that someone deleted thinking they were cleaning up, and explained distribution list nesting logic to people whose eyes glazed over in the first thirty seconds. None of that was ever the hard part.
The hard part has always been people. Specifically, navigating the gap between how enterprise IT is supposed to work and how human beings actually behave inside of it. That gap is where the real work happens. And nobody trains you for it.
The Ticket Is Never Actually About the Ticket
Here is a thing that took me a long time to understand: the stated problem is rarely the real problem.
Someone submits a ticket because their email isn’t working. You investigate. Exchange is fine, mail flow is fine, the connector is healthy. Turns out they changed their password three days ago and their phone still has the old one cached, hammering the account into lockout every forty-five minutes. That is a five-minute fix.
But then you find out they didn’t submit a ticket for three days because they were worried IT would judge them for not knowing how to update their phone. So they forwarded everything through a personal Gmail account instead, which is an actual security problem, not a hypothetical one. Plus, we block Gmail, so they are not getting their email, twice.
The technical issue was a lockout. The real issue was someone too embarrassed to ask for help, working around the system in a way that created genuine risk and still didn’t help. No amount of Exchange expertise fixes that. What fixes it is making people feel like they can ask dumb questions without getting a sigh on the other end of the phone.
You can’t patch human fear of looking incompetent. Believe me, I’ve tried to find the setting for it.
The Ghost in the Change Management Process
Change management exists for good reason. In an environment the size of Advocate Health, supporting something like 162,000 employees across a hybrid infrastructure, an uncoordinated change can take down services that touch patient care. That is not a small thing.
But here is what nobody tells you about change management: it only works if the humans running it are honest inside of it. And a surprising number of them aren’t, not out of malice, but out of self-preservation.
Someone makes a change that breaks something. The instinct, for a lot of people, is to downplay it in the post-incident review. To frame it in a way that distributes the blame or obscures the sequence. Not lying exactly, more like strategic ambiguity. And when that becomes the culture, you lose the entire point of the process. You’re just doing paperwork theater.
I have been in rooms where we spent more time wordsmithing a root cause document than we spent actually solving the underlying gap that caused the outage. That is a people problem. The technology told us exactly what happened. The logs were clear. What was murky was the human politics around who was going to own it.
No monitoring tool alerts you to that. No runbook covers it.
The Tribal Knowledge Trap
This one is specifically insidious in long-tenure environments, and I say this as someone with nearly 17 years at the same place.
Over time, certain people become the holders of critical institutional knowledge. How a specific legacy system actually works. Why that one distribution list is structured the weird way it is. What the real reason was behind a configuration decision made eight years ago that now looks completely arbitrary.
That knowledge lives in people’s heads. Not in documentation, not in wikis, not in ticketing systems. In heads.
And as long as those people are available and cooperative, everything runs fine. The moment they leave, retire, or just decide they’re tired of being the one everyone calls, you find out exactly how fragile the system really is.
I have a notes app on my phone that is half brilliant ideas and half cryptic fragments that mean nothing to me three weeks later. Imagine that problem at enterprise scale. That is what undocumented tribal knowledge looks like. A sprawling, partially-deciphered collection of things that someone understood completely at the time and nobody else can reconstruct.
The technology is documented. The protocols have RFCs (Request for Comments). The human reasoning behind every deviation from those protocols? That’s somewhere between someone’s memory and a retirement party.
Priority Collisions Nobody Officially Acknowledges
Enterprise IT has a formal priority structure. P1 (Priority 1) is the building is on fire. P2 is significant impact. And so on down the line. Clean, logical, defined.
What the priority structure does not account for is the VP whose assistant put in a P4 ticket that the VP personally expects to be treated as a P1 because of who the VP is. Or the department head who has a direct relationship with someone in IT leadership and doesn’t use the ticket queue at all, they just text directly, which means their requests exist outside every SLA (Service Level Agreement) metric and capacity planning model you have.
These aren’t edge cases. They’re constant. And how you navigate them has nothing to do with your technical skill set. It has everything to do with reading the room, understanding where organizational power actually lives versus where it officially lives, and figuring out how to keep the real work moving without turning every informal escalation into a political incident.
I have opened a tab to check one quick thing and surfaced forty minutes later with seventeen browser tabs and a half-written email I didn’t send because I couldn’t figure out how to say “this isn’t actually how prioritization works” without it becoming a thing. That calculation, the cost of saying the true thing versus the cost of absorbing the interruption, that’s a human math problem. The technology has no opinion about it.
What Actually Makes a Senior IT Person Valuable
It is not certifications, though certifications matter. It is not speed, though speed matters too. It is not even depth of technical knowledge, though you need that foundation or nothing else works.
What makes a genuinely senior IT person valuable in an enterprise environment is the ability to manage the human layer without losing their mind or their integrity.
That means reading when someone is embarrassed versus when they’re actually hostile. Knowing which relationships smooth the path for legitimate work and which ones are just political theater. Understanding that sometimes the right technical answer is not the answer that will actually get implemented, and deciding whether to push or to adapt based on what actually serves the environment long-term. Knowing when to document the hell out of something because the person responsible for it is clearly heading for the door.
None of that shows up in a job description. It accumulates through years of getting it wrong and paying attention when you did.
The technology, honestly, is the solvable part. Given enough time, documentation, and the right tools, most technical problems have a clear path to resolution. People don’t come with documentation. They don’t have known error databases. And they do not respond well to being rebooted.
After nearly three decades of this work, that is the thing I would tell anyone coming into enterprise IT. Get your technical fundamentals locked in tight, because they are the price of admission. But understand that what you are actually doing, most days, is managing the space between what the system is designed to do and what people are actually doing inside of it.
That space is infinite. And it never stops needing attention.
