The Ticket That Taught Me Everything About IT Leadership
Early in my career, I received a helpdesk ticket that read, in its entirety: "Computer is doing the thing again." There was no additional context. No previous ticket to reference. No follow-up when I asked for clarification. Just a user, somewhere in the building, whose computer was doing the thing, confident that this description was sufficient. It was not, technically speaking, a good ticket. It was, however, an extraordinary lesson in what happens when IT and the people IT serves don't share a common language, and whose job it is to bridge that gap.
The natural reaction for most IT professionals to a ticket like that is frustration, sometimes deserved, often misdirected. The user isn't being deliberately obtuse. They don't know what information is useful. They experience the computer as a tool that either works or doesn't, the same way most people experience their car. When your car makes a noise, you don't typically call the mechanic and describe which component of the drivetrain you suspect, you say "it's making a clunking sound when I turn left." The mechanic asks follow-up questions. The mechanic does not send back a terse reply asking why you didn't provide the OBD code. At some point in IT's evolution, we collectively decided users should know more than they do, and then we spent a lot of energy being annoyed that they didn't.
The shift from IT technician to IT leader requires a fundamental renegotiation of this relationship. Leadership isn't about knowing more than everyone else, though the technical depth matters. It's about translating between the business and the technology stack in both directions, fluently and without condescension in either. When a CFO says the system is "slow," they're not giving you a performance metric. They're telling you that something is impacting their work enough to mention it, and your job is to find out what "slow" means in measurable terms. When a department head asks for a "better way to do this," they're handing you an automation project if you're paying attention.
The tickets that taught me the most weren't the complex ones with fascinating technical root causes. They were the vague ones, the frustrated ones, the ones that arrived at 4:45 on a Friday with zero context and maximum urgency. Because those tickets were the ones that required every non-technical skill in the toolkit: communication, patience, prioritization, stakeholder management, and the judgment to know when to fix the immediate problem and when to fix the system that keeps generating it. The technical certification gets you in the room. The ability to handle the 4:45 Friday ticket with grace is what gets you promoted.
If you manage an IT team, look at your most recently closed tickets and ask yourself whether your team is solving problems or closing tickets. Those are not the same thing. A ticket gets closed when the immediate symptom is resolved. A problem gets solved when the root cause is addressed and the user walks away understanding what happened and why. The difference in time investment is measurable in minutes. The difference in user trust is measurable in years. That's the ticket worth logging.
