Before I moved into IT, I spent more than 13 years in the British Army.
It probably isn’t the background you’d expect to see on an IT support website, but looking back at how I work now, I can see quite a few things that came with me when I left.
The technology is obviously very different.
The way you approach responsibility, preparation, people and problems isn’t always quite so different.
Taking responsibility for what is in front of you#
One of the biggest things I took from the Army is that if something is your responsibility, you need to know what’s going on.
That doesn’t necessarily mean you have to be able to do everything yourself. It means you need to understand the situation, know what has been done and have a clear idea of what needs to happen next.
I’ve found myself working in much the same way in IT.
If I’m dealing with a complicated support issue, I want to understand what has actually happened rather than simply passing it somewhere else because it looks difficult.
If I’m the sole engineer on a customer site, I need to know what work is planned, what issues have appeared and what needs to be dealt with before I leave.
If something needs to be escalated, I want to make sure the next team has enough information to continue the investigation rather than simply receiving the same problem I was given.
That doesn’t mean I always own the final solution.
There are plenty of issues where another team is responsible for the technical fix. What I can control is the quality of the investigation I’ve done, the information I’ve gathered and how well I’ve communicated what I’ve found.
That way of thinking feels very familiar to me.
Preparation makes things easier when something goes wrong#
The Army put a lot of emphasis on preparation.
You don’t want to discover that something important is missing when you actually need it. You want to have thought about what you’re doing, what you might need and what could go wrong before you get there.
Obviously, IT isn’t the same environment.
But the principle has stuck with me.
Good preparation in IT might be making sure you have the right information before starting an investigation. It might be checking a device before a customer visit, understanding what work is planned or making sure documentation is available when someone needs it.
I’ve become particularly interested in this through the work I’ve done around documentation.
A process can be perfectly reasonable, but if the information someone needs to follow it is missing or out of date, they’re starting at a disadvantage.
I’ve seen this when working through existing documentation and finding that parts of it no longer reflected the environment.
The answer wasn’t necessarily to create something complicated.
It was to make sure the information was accurate and actually useful.
That distinction matters to me.
I don’t like documentation that exists simply because somebody decided there should be a document.
I’d rather have something that someone can actually use.
Accountability isn’t just keeping track of things#
A significant part of my Army experience involved equipment and logistics.
You need to know what you have, where it is, what condition it’s in and who is responsible for it.
That might sound a long way removed from IT, but I’ve found there are some obvious similarities.
In IT, there are devices, accounts, access, information and services that all need to be managed properly.
The details are different, but the basic idea of knowing what you have and understanding its status still matters.
I’ve worked with asset lists, device preparation, rebuilds and provisioning as part of my current role, and I think my previous experience has probably made me naturally conscious of the importance of accurate information.
If the records say one thing and reality says another, that’s worth investigating.
You can’t make good decisions about something you don’t properly understand.
Things don’t always go according to plan#
One thing you learn pretty quickly in any environment where you’re responsible for getting things done is that the plan is rarely the complete story.
Something changes.
Something doesn’t work.
Someone needs something you weren’t expecting.
You have to adapt.
I’ve experienced plenty of that in IT.
A ticket can start as a straightforward access issue and turn into an investigation involving sign-in activity, device state and Conditional Access.
A customer visit can have planned work, only for users to raise completely different issues once you’re there.
A piece of technical work can uncover something that needs another team involved.
I’ve found that the best response isn’t to immediately start changing things because the original plan no longer fits.
I try to work out what I know, what I don’t know and what information I need before deciding what to do next.
That sounds simple, but staying calm enough to actually do it is important.
Leadership isn’t always about the title#
During my Army career, I had responsibility for people and led teams of up to 10.
That experience taught me quite a lot about what leadership actually looks like when you’re responsible for getting a job done.
It isn’t just telling people what to do.
You need to make sure people understand what is expected, give them what they need to do the job, keep things moving and step in when something isn’t going to plan.
I’ve found some of that carries across into IT.
I don’t need to be someone’s manager to help them work through a difficult problem.
Sometimes a colleague just needs another person to talk through an investigation with.
What have you checked?
What does the evidence show?
What haven’t you ruled out?
Is there another angle worth looking at?
What does the next team actually need from you?
Sometimes helping someone structure a problem is more useful than taking the problem away from them.
That’s something I enjoy doing.
Documentation has always mattered to me#
This is probably one of the strongest connections between my Army experience and the way I work in IT.
When you’re responsible for equipment, people or tasks, accurate information matters.
You need to be able to trust the records you’re working from.
I’ve carried that into IT.
I’ve worked on knowledge articles and process documentation, and I’ve seen what happens when information becomes outdated or doesn’t reflect the way something is actually done.
It’s easy to think of documentation as something separate from the actual work.
I don’t really see it that way.
If the next person needs to complete a task, investigate an issue or understand a process, the information available to them is part of what allows them to do that properly.
I’ve also found that reviewing documentation can expose things that aren’t obvious when you’re simply following the process.
If the document says one thing but everyone is actually doing something else, that’s worth understanding.
It might be that the process has changed.
It might be that the documentation was never quite right.
Either way, you’ve found something worth looking at.
You learn to rely on the people around you#
Another thing the Army taught me is that you don’t get very far by trying to do everything yourself.
Different people have different responsibilities, skills and experience.
The important thing is knowing what you can deal with, when you need help and how to work effectively with the people around you.
That’s very relevant to IT.
There are plenty of problems where I can investigate the issue but eventually need another team to take it further.
That isn’t a failure.
The important thing is making sure the handover is useful and that I’ve done what I reasonably can before it gets there.
I’ve also found that working across an MSP environment means communicating with a lot of different people. Customers, users, service desk colleagues, resolver teams and project teams all have different perspectives on the same piece of work.
You have to be able to work with all of them.
The Army didn’t teach me how to do IT#
I think that’s probably the most important distinction.
The Army didn’t prepare me to troubleshoot Microsoft 365.
It didn’t teach me how Entra ID works, how to investigate an Intune compliance issue or how to understand a Conditional Access result.
Those are things I’ve had to learn since moving into IT.
What the Army did give me was a way of approaching work.
Take responsibility for what is in front of you.
Prepare properly.
Keep accurate information.
Look after the people around you.
Stay calm when something changes.
Ask questions when you don’t know.
And when something isn’t working, don’t just keep doing the same thing without trying to understand why.
Looking back, those habits have been useful#
When I first moved into IT, I was obviously focused on learning the technology.
I had a lot to learn, and I still do.
But as I’ve gained more experience, I’ve realised that knowing the technology is only part of being good at the job.
How you investigate something matters.
How you communicate matters.
How you document something matters.
How you work with other people matters.
Whether you take responsibility for an issue matters.
Those aren’t necessarily IT skills, but they’re skills that have helped me while I’ve been learning IT.
My career has changed quite a lot since I left the Army.
The environment is different, the problems are different and the technology is completely different.
But when I look at how I work today, I can still recognise quite a lot of the person who was there before I moved into IT.
The Army didn’t teach me IT.
It taught me a lot about how I approach the work.
The technology is different.
The way I approach the work isn’t quite so different.
And I think that’s been useful.