Experience

A different route into IT

My route into IT wasn’t exactly straightforward. Before moving into technology I spent more than 13 years in the British Army, working across Infantry and Logistics. Since then I’ve built my career in an MSP environment, supporting a broad range of customers, technologies and environments.

Along the way I’ve become just as interested in what sits around the technical problem as the problem itself - how services are delivered, how teams work together, whether documentation actually helps people, and what changes when something isn’t working as well as it should.

At a glance

IT Support Engineer, MSP

Working in an MSP has given me experience across a broad range of customer environments, technologies and support requirements. My day-to-day covers triage, investigation, resolution, escalation and closure across multiple customer environments, plus taking ownership of the more complex issues, supporting colleagues, and looking for ways to improve how the service operates.

Technical areas

I also work with printers, business applications, RemoteApp environments and other customer-specific systems.

On customer sites

A significant part of my role is supporting customers on-site, often as the sole engineer, taking responsibility for the support activity and coordinating what needs to happen. That covers:

• Triaging issues and floor-walking
• Supporting users and gathering evidence
• Device provisioning and asset validation
• Printer and network checks
• Coordinating escalations and keeping customer contacts updated

Being on-site gives a different view of the environment - you see how people are actually using the technology, and often find information that isn’t obvious from the original ticket. I’ve also acted as on-site support lead for larger change activity, including a migration covering more than 200 users.

Working with the wider team

My role isn’t limited to my own workload. I support colleagues with more technical investigations, take ownership of complex tickets when required, and try to make sure any handover to another team includes what actually matters - what happened, what’s been tested, and the logs, screenshots and configuration details needed to pick it up without starting over.

I’ve also identified documentation gaps and written knowledge articles to improve consistency, and raised wider service concerns where an issue looks like it’s recurring rather than one-off. Sometimes the useful question isn’t why did this happen, it’s why are we still seeing this.

How I approach the work

• Start with the evidence - find out what’s actually happening before deciding what the problem is
• Work through it properly - establish impact, gather information, test causes, don’t guess
• Take ownership - even when another team makes the change, make sure the investigation is useful
• Keep people informed - the technical fix is only part of the job
• Look beyond the individual problem - if something keeps happening, understand why
• Keep learning - there’s always another technology, process or framework worth understanding

Before IT: 13+ years in the British Army

A lot of how I work today came from those years - taking responsibility, planning properly, keeping track of things, and staying calm when something doesn’t go to plan.

Infantry (2009 - 2018) - working as part of structured teams, training and mentoring people, and maintaining equipment. I led and coordinated teams of up to 12, including delivering training to less experienced colleagues, and held responsibility for high-value equipment: its accountability, readiness and records. If something was your responsibility, you needed to know where it was and what condition it was in.

Logistics (2018 - 2022) - more focus on planning, operational readiness and coordination. I led teams of up to 12 across equipment readiness, asset tracking, maintenance schedules, resource allocation and liaising with external organisations and international partners. Most of it came down to having accurate information: what you have, where it is, and who’s responsible for it.

After leaving the Army I spent a short period in recruitment before moving into technology, which gave me a different perspective on communication and working in a commercial environment before I started building the technical side of my career.

Qualifications & learning

I want my learning to connect back to the work I actually do, not just sit as a certificate.

ITIL has helped me connect the day-to-day work - incident and request management, prioritisation, escalation, continual improvement - to the bigger picture of how a service actually fits together. ISO 27001 is a natural next step, given how much I’m drawn to the relationship between people, process, technology and risk.

Outside of work

Most of what’s left goes into my homelab - Proxmox, Docker, Linux, and enough self-hosted projects to keep learning without a client on the other end if I get something wrong. Full write-ups live on the Projects page.