Job Experience

National Defence College · Military service

Running the IT function of a facility for ten months

My compulsory military service was spent in the IT office of the National Defence College, responsible for the technology of the entire facility. I turned an ad-hoc support function into something with an intake queue, a triage model, a monitoring dashboard and a set of scripts.

Company

National Defence College

My role

IT & Network Administrator

Context

Compulsory military service

Timeline

Jan 2025 – Oct 2025

Scope

Whole-facility infrastructure & accounts

Operating model diagram: requests arrive, are logged and triaged in Jira, assigned to the team, and monitored on dashboards

Why this is on a product portfolio

This is not a product role and I would not present it as one. It is here because of what it required me to build: a way to see all the demand at once, decide what mattered first, distribute it across people, and account afterwards for where the time went.

Scope of the role

I was responsible for supporting all the technology infrastructure of the building, covering the networks, the hardware, and the software and data issues that came with them. In practice that meant network maintenance and development, hardware and software troubleshooting, Windows Server administration and network security with pfSense.

I also managed the team staffing that department. That is the part that changed how I work. When several people could do a given job, deciding who does it, and being able to account later for what everyone did, becomes essential.

Everything went through the queue

I logged every piece of work that needed doing in Jira and triaged it before assigning it: how many people or systems it affected, whether someone was already blocked by it, and how much effort it would take to clear, rather than working the queue in the order things arrived. Then I distributed it to the right person, including myself. That last detail is what made it work. A queue that the person running it exempts themselves from stops being an accurate picture of the workload within about a week.

With everything in one place, I kept dashboards updated with the corresponding data so the state of the infrastructure and the networks could be monitored immediately rather than discovered later. The purpose was not upward reporting. It was that a pattern in the queue becomes visible long before it turns into an outage.

Accounts, machines and documents under protocol

I managed the accounts of all personnel at the facility, which meant being responsible for the security of those accounts and of the computers behind them. Document transfer was part of the role as well, carried out under specific security protocols rather than at my own discretion.

Working somewhere the rules are non-negotiable is useful preparation for working somewhere the rules are legal rather than military. GDPR obligations on EzyFlat and an EU institution's compliance requirements at Netcompany both felt familiar because of this.

The most useful constraint

Military service gives you a fixed team, no budget and no ability to choose your tools. Every improvement had to come from reorganising what already existed. That is far better training for prioritisation than an environment where a problem can be solved by spending on it.

What I automated

Some of the work, mostly collecting and processing data, was repetitive, time-consuming and identical every time. Once we spotted that as an optimisation opportunity, I worked with the team to build the automation that fixed it, rather than writing it alone from scratch.

Nobody asked for it. It came out of the queue. When the same task appears every week in the same shape, the queue is telling you that the process is the bottleneck rather than the people. Noticing that pattern and acting on it is the same instinct product work relies on, with the difference that here the users I was unblocking were the team and myself.

What I carried forward

  • Repetition is a requirement in disguise. The tasks we ended up automating had been announcing themselves in the queue for months.
  • Instrument the thing before you are asked to report on it. The dashboards existed so we could act early, which is a different design goal from dashboards that exist to be shown.
  • Improvement under a hard constraint is a skill. With no budget and no choice of tools, the only lever left is how the work is organised, which turns out to be the biggest lever anyway.
Next role

Netcompany-Intrasoft: owning the backlog on a five-year EU programme

Read it