When I first moved into IT support, a lot of the job seemed fairly straightforward in my head.
Something was broken.
Find out why. Fix it. Move on to the next one.
That’s still a big part of what I do.
If someone’s laptop isn’t working, they need their laptop working. If they can’t access something they need for work, that needs sorting. If Outlook has stopped behaving, they aren’t particularly interested in my thoughts on service management.
They need Outlook working.
That’s the reality of support, and restoring service matters.
But I’ve started thinking a little more about what happens after the immediate problem has been fixed.
What if it keeps happening?#
This is where things get more interesting for me. If I fix something once, that’s useful.
If I fix the same thing three times, I start wondering whether there is something else going on.
Maybe the underlying technical issue hasn’t really been addressed. Maybe the process around it is causing the problem. Maybe the documentation isn’t clear. Maybe the same mistake keeps being made. Maybe there is a dependency that nobody has documented.
There are plenty of possibilities, and I don’t think you can assume you know the answer straight away.
The important part is noticing the pattern. If something keeps coming back, the individual ticket is telling you something.
Documentation was one of the things that changed my thinking#
I’ve worked on documentation where the written process no longer matched what was actually happening.
At first glance, that can seem like a fairly minor problem. But if someone is following an outdated process, they can waste time, follow steps that no longer apply or create another problem further down the line.
I’ve seen this particularly through work on Joiner, Mover and Leaver documentation, where I helped remove legacy steps that no longer reflected the way the environment was actually being managed.
The immediate task was updating the documentation.
But there was something bigger behind it.
The information people rely on is part of the process. If it’s wrong, the process isn’t working as well as it should.
That made me think differently about documentation. It’s not just something you write down after the work is finished. It can directly affect how the work gets done.
This is one of the reasons I’ve enjoyed studying ITIL v5 alongside working in support.
I was already noticing recurring issues, documentation gaps and processes that didn’t always match reality. The courses gave me a way of understanding those observations.
There is obviously a place for restoring service and dealing with the immediate incident. But there is also value in stepping back and asking whether something needs to improve.
I don’t think that means turning every ticket into a formal problem-management exercise.
Sometimes noticing something and raising it with the right person is enough. Sometimes the improvement is simply updating a document. Sometimes there is nothing worth changing at all.
For me, the useful part is having the mindset to recognise the difference.
I’ve started seeing more of the service around the ticket#
This is probably the biggest change in how I think about support.
A ticket doesn’t exist on its own. There is a person raising it.
There is a process behind it.
There might be a team responsible for the service.
There might be another team responsible for part of the technology.
There are systems, information, policies and dependencies involved.
The technical fault is only one part of the picture.
Working in an MSP environment has probably reinforced that for me because I’ve seen a lot of different customer environments and different ways of working.
The same type of technical problem can have a completely different context depending on the customer, the users affected and the service involved.
You have to understand the environment you’re actually dealing with. That has also changed the way I think about the work I do myself.
If I’m investigating an issue, I’m not only thinking about what will make the error disappear. I’m also thinking about whether the information I’m leaving behind will help the next person, whether the issue is likely to return and whether there is anything about the process that is making the problem harder than it needs to be.
I’m not always going to find something that needs changing.
But I’m more likely to notice it now.
I don’t think every problem needs a big answer#
This is important because it’s easy to take the idea too far.
Sometimes the answer really is:
Fix the thing and move on.
Not everything needs a process review. Not every repeat issue needs a project. Not every documentation gap needs a new system.
Sometimes you just need to update a page, improve a knowledge article or tell someone what happened.
The point isn’t to make everything bigger.
It’s to recognise when there is an opportunity to make something better and decide whether that improvement is actually worth doing.
I’ve found that to be a much more practical way of looking at continual improvement.
You don’t need to improve everything. You need to notice what could be improved and make a sensible decision about it.
I’m still a technical support engineer#
This hasn’t changed.
I still troubleshoot devices. I still investigate Microsoft 365 issues. I still work with Entra ID and Intune.
I still deal with printers, access problems, applications and all the other things that turn up during a normal week.
I’m not trying to move away from the practical side of IT.
That practical experience is the foundation for everything else I’m learning.
What has changed is that I’m increasingly interested in what sits around the technical problem.
Why does this keep happening? Could we make this clearer? Is the process actually helping? What information are we missing? Could the service work better?
Those are questions I probably wouldn’t have thought about in quite the same way when I first moved into IT.
Now I find myself asking them more often. And I think that’s a good thing.
I’m still fixing the problem in front of me.
I’m just getting more interested in understanding what happens around it.