How to Fix a Broken IT Culture

When I joined my last company, IT was reactive. No triage, no ticket enforcement. We dropped everything for every request, regardless of urgency. (For context on the role I grew into while this was happening: The senior engineer I didn’t notice I’d become.) At first I didn’t know any better—I was new, and wanted to rise to expectations. So I responded to every single email in seconds, was always ready to run over to reboot someone’s printer or clear their cache. Users were satisfied by the quick responsiveness, but were entirely dependent. It also cost us in ways that gradually dawned on me: we never had time for projects, management thought we weren’t busy because we were always available and our ticket counts were low, and users had no ability to help themselves with anything.

Over the next several years I realized this had to change, and I had to be the one to change it.

Here’s how:

1. Stop firefighting first — or you’ll never have time do anything else

Before anything else, you have to buy yourself time. Not by being slower or less responsive, but by not treating every request as an emergency.

The instinct on a small team is to grab the easy problem that just came in and fix it. It feels and looks productive. But every minute spent on a low-stakes ticket is a minute you don’t spend on the things that would prevent ten more like it. And if you never break that loop, you stay stuck in it forever.

Start triaging. Decide, in your head, what’s actually blocking someone’s work right now versus what can wait an hour. Then act accordingly. Most “urgent” requests can wait an hour. Most users will be fine if you tell them you’ll be over after lunch.

2. Build a knowledgebase people will actually use

My company had very little end user documentation, so they contacted IT for everything. I watched my manager (who had been running solo before I joined) walk over to an employee’s desk, silently fix the problem, and walk away. At first, I did that too. Then I realized the problem described in step one, which led me to revamp our documentation.

Every single time I was contacted about a problem, I wrote an article on the fix. For “my keyboard isn’t working,” I included a list of the models someone might have, the most likely causes, and the steps to try in order. The goal was that a user could solve their own problem without making a ticket—if they were willing to read for two minutes.

If they did make a ticket, I would redirect them to the documentation first. “Here’s the article—try this; if it still doesn’t work, submit a ticket and I’ll come over.” Some people pushed back at first. Most didn’t, because the article actually answered their question.

3. Teach, don’t just fix

When I solved a problem, I started explaining what had happened and why. Not in a lecturing way—just a sentence or two while I was already at the desk. “This was because you were on the guest network. Make sure to connect to the corporate network, or you won’t have access.”

This had two important results. One, people started solving similar issues themselves the next time. Two, they felt respected because I was treating them as capable of understanding the answer, instead of just performing magic and leaving.

I also started hosting user enablement sessions on things like macOS power-user skills. People got genuinely excited. Someone learned the keyboard shortcuts for copy and paste. Others discovered Spotlight. It sounds small, but it was the first time a lot of them had thought of their computer as something they could be good at. And it made people much more productive.

4. Use the time you’ve freed up to talk to people, not just close tickets

Once we weren’t drowning in low-stakes requests anymore, I had room to meet with each department and ask what was actually slowing them down. Not “do you have any IT issues.” More like: walk me through how you do this thing, where does it get annoying, what do you wish was different?

A lot of the time the answer wasn’t a new tool. It was a workflow problem, or a feature in a tool we already had that nobody had set up. Sometimes someone would ask me to evaluate buying a new SaaS, and I’d dig into what they were actually trying to accomplish and find we already owned something that did it. I’d help them get set up. They got their problem solved without us onboarding a whole new platform.

That kind of work doesn’t show up on a ticket queue, but it’s where IT becomes useful instead of just available.

5. Get the data to tell the truth about your workload

When you fix everything quickly and quietly, your ticket data looks like you’re not doing much. Management makes resourcing decisions on that data. So if your data is wrong, you don’t get the headcount, and the cycle continues.

Once people were filing tickets instead of grabbing me in the hallway, the queue started reflecting reality. Even though the knowledgebase resulted in less support requests, ticket discipline led to more requests tracked. That’s what eventually made the case for a junior hire—and it’s what created room for the work I’d wanted to do for years: a SIEM build, endpoint hardening, compliance work that we desperately needed. None of that fits in a culture where you’re never not putting out a fire.

6. Pick your battles with leadership, and frame them in their language

This is adjacent but worth saying. When you push back on a plan from leadership, don’t lead with the technical detail. They don’t need the why behind the complexity—they need to trust that you do. Tell them what you can do, what the risk is if you rush, and give them a recommendation. Most of the time, that’s enough.

I came up against this most clearly during a company rebrand. Leadership wanted everything to change at once—website, email, SSO, the Microsoft tenant. The website is easy. The identity platform is not. Instead of explaining why, I framed it around what they’d feel if it went wrong: nobody can log in on launch day. We did the user-facing pieces first and the backend on a safer timeline. No drama.

The thing nobody tells you

I came into IT from teaching kindergarten. The patience and empathy I built there is still one of my biggest assets in support. People in IT roles often roll their eyes at users; I never have, because I know what it’s like to not know a thing and feel stupid asking. The cultural shift I described above was grounded in the skills I learned as an educator. You treat people as capable, you make it easy for them to help themselves, and you spend the time you save on the work that compounds.

I didn’t realize I had this power at first, and I’m proud that I was able to make these changes. It may be more “soft skills” than technical, but this is the version of IT I want to keep building.