Some incidents earn the phrase “code red.” A storage array eating itself. A ransomware note with a countdown timer. A power outage that finds out your UPS batteries retired two years ago and nobody told you.
This was not one of those.
But it was declared one. Loudly. By the IT director himself.
The Escalation
It was mid-morning. The kind of mid-morning where you have finally sat down with a coffee and an honest intention to close three tickets before lunch.
Then the phone rang.
The IT director was calling our manager. Not emailing. Not opening a ticket like the rest of humanity. Calling, with the specific vocal tension of a man who has an important meeting in eleven minutes.
“I can’t join the meeting.”
Now, understand what those five words mean in an IT department when they come from the top of the org chart. They do not mean “I have a small problem.” They mean the organization is on fire and the smoke is currently in the executive corridor.
The protocol activated instantly. Not the written protocol, the real one, the one that lives in the collective spine of every IT team: send the best person, send them now, and do not come back without a fix.
I was, at that point, the most senior engineer on the floor. So I was dispatched.
I remember standing up and grabbing my notebook with a genuinely dramatic sense of purpose. Twenty-something years in, and you still get that little adrenaline hit. My brain was already running a checklist on the way to the elevator.
- Is it a network issue? Did the executive VLAN do something creative again?
- Is the conferencing service down globally? Should I check the status page?
- Is it a certificate problem? Those love to ambush senior people at the worst hour.
- Is it a firewall rule someone “tidied up” last night?
- Is it the client version? Audio drivers? Proxy authentication?
By the time the elevator doors opened, I had built a full mental fault tree. I was ready. I was, if I am honest, a little excited. This is the job. Big problem, short deadline, real stakes.
The Investigation
I arrive. The director is standing next to his desk the way people stand next to a car that will not start. Polite, stressed, apologetic. Good man, genuinely. Not one of those people who treat IT like furniture.
“The link doesn’t work,” he says.
Right. Let’s look.
The meeting invitation is there. The Skype link of that era is there, sitting in the email, perfectly innocent. I click it.
Nothing happens. Or rather, something happens, and it is not joining a meeting.
So I do what we all do. I start peeling layers. Is the client installed? Yes. Is it running? Sort of. Network? Fine, the man is on the same LAN as the rest of us and everyone else is happily in meetings. Proxy? Fine. DNS? Fine. I check the service status. Fine. I check the version. Fine.
Everything is fine, and the man still cannot join his meeting. Which is the exact moment every engineer starts to distrust the word “fine.”
Ten minutes in, I am deep in the weeds. I have opened settings menus I had not opened in months. I am mentally drafting the sentence “I may need to escalate this to the platform team” while knowing full well the meeting starts in four minutes.
And then I see it.
The application is not asking for a password. It is not asking for a retry. It is not showing an error.
It is showing a first-run welcome screen.
The kind with a friendly greeting and a button.
The button says: Create profile.
The Root Cause
I sat there for a second and let the truth arrive at its own pace.
The IT director had never opened this application. Not once. Not in the entire time it had been deployed to every machine in the company, including his. No profile. No sign-in. No first login. The software had been sitting on his desktop like an unopened appliance still in its box, quietly waiting for a day that had finally come.
The link worked perfectly. The network was flawless. The servers were healthy. The certificates were valid.
The system was waiting for him to press a button he had never pressed.
I want you to appreciate the full architecture of this moment. A code-red escalation. A direct call to a manager. The most senior engineer pulled off the floor and sent upstairs like a specialist flown in for surgery. A mental fault tree spanning seven layers of the OSI model and at least three enterprise systems.
All of it, the entire machinery of urgency, sprinting at full speed directly into a welcome screen.
I clicked the button. He entered his credentials. Thirty seconds later he was in his meeting, on time, saying good morning to people who would never know how close this had come to becoming a legend.
I walked back to my desk. My coffee was cold. My three tickets were still open. And I had a new favorite story.
Now the Part That Is Not Funny
Here is where I have to be fair, because the cheap version of this story is “look at the clueless boss,” and that version is both unkind and wrong.
This was the IT director. The person whose entire professional identity is built on technology. The person we looked to for decisions about platforms, budgets, roadmaps, and standards. The person who signed off on the very collaboration tool he had never opened.
And he was, by a considerable distance, the person in that building most disconnected from the technology itself.
That is not a character flaw. That is drift.
Nobody wakes up and decides to stop being technical. It happens quietly, one calendar invite at a time. First you stop doing the work and start reviewing the work. Then you stop reviewing the work and start reporting on the work. Then your week is budget cycles, vendor negotiations, headcount politics, steering committees, and a quarterly presentation that eats four evenings.
The keyboard does not leave you. You leave the keyboard, slowly, with excellent reasons every single time.
And then one morning you cannot join a meeting, and the version of you from ten years ago would have fixed it in nine seconds without looking up from the screen.
The scary part of that story was never the missing profile. It was that we were asking a man who had drifted out of the technology to make decisions about the technology.
Because that is where the real cost shows up. Not in a comedy sketch on the executive floor. It shows up when someone approves a migration timeline that is physically impossible. When someone cannot tell the difference between a team that is slow and a team that is drowning in technical debt. When someone buys a platform because of a slide deck instead of a pilot. When an engineer says “this will break in production” and nobody upstairs has enough muscle memory left to feel the weight of that sentence.
Hands-on experience is not about fixing things yourself. It is about calibration. It is the internal gauge that tells you whether an estimate is honest, whether a risk is real, whether your team is telling you the truth or telling you what you want to hear.
When that gauge goes out of calibration, leadership becomes guesswork wearing a nice jacket.
And Yes, I Ask Myself the Same Question
I tell this story with affection now, not superiority, and here is why.
I run a company. I have weeks where I look back on Friday and realize I did not touch a terminal once. Weeks of proposals, invoices, hiring conversations, client calls, and the special category of meetings that exist to schedule other meetings.
Twenty-six years in IT, and I still catch myself drifting. I have to actively choose to stay close to the work. I keep a lab. I still take tickets I could easily hand to someone else. Not because I am irreplaceable, I am very much not, but because the day I lose the feel for it is the day my advice starts being expensive and wrong.
So when I remember that director standing next to his desk, I do not laugh at him. I laugh at the situation, which was genuinely magnificent, and then I check my own calendar with a slightly uncomfortable feeling.
Because that could be me. On a long enough timeline, it could be any of us.
So Let Me Ask You
How hands-on should an IT leader stay?
Is the answer “solve one ticket a week, forever, no exceptions”? Is it “keep a lab and break things on purpose”? Or is leadership simply a different profession now, where the job is judgment and people, and expecting a director to remember command syntax is nostalgia dressed up as principle?
I genuinely do not have a clean answer. I lean toward “stay close enough to smell when something is wrong,” but I have also seen managers who insisted on staying technical and became the bottleneck for their entire team.
Tell me where you land. Especially if you are the one whose calendar has quietly eaten your keyboard time.
And if you have never opened that one application everybody assumes you use daily, maybe go press the button now. Before someone declares a code red.