Leading an IT team out of firefighting

An IT team can work hard all week and still feel as though nothing has moved. The tickets are real, the interruptions are real and people need help. But the projects that would reduce those interruptions keep getting pushed aside.

I’ve worked through that kind of environment. It’s tempting to assume the answer is a new service tool, a stronger process or simply more people. Any of those might help. First, though, I want to understand what is consuming the team and how decisions about its time are being made.

The aim is not to eliminate support work. Supporting the organisation is part of the job. The aim is to stop every incoming request from becoming an unplanned decision about everybody’s priorities.

Make the work visible before changing the structure

A ticket count is useful, but it doesn’t describe all the work. There are project commitments, supplier problems, access requests, security fixes, informal favours and the tasks that only one person knows how to do.

I’d start by putting those demands in one view. It doesn’t need to be a complicated system. For each piece of work, record who needs it, what happens if it waits, who owns the next step and what is blocking it.

Look for work arriving outside the agreed channels. A team member responding to messages all day may be carrying a large support load that never appears in the reporting. Telling that person to finish more project tasks will not fix the conflict.

This exercise is also a chance to check whether work is still needed. A request that has been sitting in a queue for months deserves a conversation with the requester, not an automatic place in the next plan.

Give “urgent” a meaning people can use

Everything can sound urgent when the only question is whether someone wants it soon. I prefer to ask what is affected and what changes if the team acts today rather than later.

A service outage affecting many staff is different from a useful feature requested for a meeting. A security issue with a credible exposure is different from a general improvement. The categories need enough detail that two people can reach roughly the same conclusion.

Consider a hypothetical week with a payroll access problem, a reporting enhancement and a planned security change. The decision is not simply which requester is most senior. It depends on the deadline, the operational impact, the risk and whether there is a workable alternative.

Explain the trade-off back to the business. “We can do this now, but it moves that delivery date” is much more useful than quietly accepting both and hoping the team finds the time.

Protect some time to fix recurring problems

A team cannot reduce repeat incidents if every available hour is spent responding to the next one.

Choose a small amount of improvement work and give it an owner and protected time. Be specific about when that time can be interrupted. A major incident may justify it; an ordinary request should usually follow the normal queue.

For example, repeated access issues might point to a joiner process that needs clearer ownership. Repeated reporting requests might point to an integration or a shared report. The useful question is whether the same underlying problem keeps creating demand.

Do not turn this into a second, invisible backlog. Review what the improvement changed. Did repeat incidents reduce? Is the workaround still needed? Are users having a different problem now? A completed task is not automatically a resolved problem.

Separate responsibilities without building walls

Service delivery, technical work and projects need different rhythms. A support queue changes throughout the day. A technical change may need preparation and a safe window. A project needs continuity and decisions from people outside IT.

Giving those responsibilities clearer homes can help. It doesn’t mean each group stops caring about the others.

The handovers matter. A project should not become a support problem on launch day because nobody wrote operating notes, agreed ownership or explained the change to staff. Equally, support needs a route to raise recurring issues that require engineering work rather than another temporary fix.

I’d define a few simple agreements: what a project must hand over, when support escalates an issue and how the team decides whether a recurring incident deserves planned work. The structure should make those conversations easier, not create more tickets between colleagues.

Notice when the leader is the queue

This is the uncomfortable part. I’ve had to recognise when I was the bottleneck.

If people need your approval for every decision, being responsive doesn’t solve the problem. You are still the dependency. When you are busy, everything waits; when you are available, everyone interrupts you.

Start with the decisions that can safely move closer to the work. Agree the boundaries: what someone can decide, what they should record and when they need to escalate. Give enough context that they understand the judgement involved, rather than just delegating the task.

A useful review question is, “Which decisions waited for me this week?” Look at whether your involvement changed the outcome. Where it did not, consider changing the authority or the information available to the person doing the work.

Use a review that changes the next week

A team meeting that only recites completed tickets is unlikely to fix the pressure. I want the review to answer a few practical questions:

• What is blocking someone, and who will remove that blocker?
• Which commitment is now at risk?
• What unexpected work arrived, and what did it displace?
• Which repeat problem should become planned improvement work?
• What are we explicitly not doing next week?

That last question matters. A plan without a stopping point can become a wish list. People should leave knowing the priorities and what they have permission to defer.

Use measures that help explain the work: time spent waiting, repeated incidents, ageing requests and whether agreed commitments were met. Avoid treating a rising ticket closure count as proof that the experience is improving. It can also mean the same problems keep returning.

Start with the next manageable change

I’d not begin with a large transformation programme. Pick one source of confusion and make it easier to handle. That might be a priority rule, a project handover checklist or a recurring problem that finally gets time to be fixed.

Tell people what is changing, try it and ask whether it helped. Keep what works. Change what creates extra effort without improving the result.

Leading a team out of firefighting is less about asking people to work harder than giving them a clearer way to decide, finish work and learn from it. The first sign of progress may be quite ordinary: fewer surprises, a commitment that stays a commitment, or someone making a good decision without waiting for you.