National Defence College, IT & Network Administrator

How this role relates to product work

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

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

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: if the person running a queue leaves their own work out of it, the queue stops reflecting the real 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 goal was to spot a pattern in the queue long before it turned into an outage, rather than to report upwards.

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, and that proved to be the most effective one.

Running the IT function of a facility for ten months