Twenty years.
One recurring thought.

Wrong Turn, Right Instinct

Started out studying something entirely unrelated to networks — the kind of degree that seemed sensible at the time. It wasn't. What was sensible, it turned out, was the internet. Somewhere in that transition, a direction was set. Not planned. Just followed.

Within a year it was clear: a career counting other people's money was not the plan. The plan was this. Whatever this was going to become.

Learning the Internet from the Inside

The first job was at an ISP. Not the glamorous engineering role — the phones. Someone's internet is slow. Someone's connection drops at exactly dinner time. Someone is convinced their provider has personally wronged them, and they want to discuss this at length.

This was, unexpectedly, an education. Not in troubleshooting flowcharts, but in how the internet actually works when real people are depending on it. Every call taught something. You learn patience. You learn how to diagnose a problem from three fragments of information and one angry tone of voice. You learn that most problems have simpler causes than anyone expects, and a few have causes that shouldn't be possible but somehow are.

Eventually the calls gave way to the NOC — the network operations center, where you stop answering questions and start finding answers. Monitoring, diagnosing, fixing. At all hours. On weekends. Without warning. This is where the instinct for how networks behave starts to feel less like knowledge and more like intuition.

Eight Years in the Engine Room

Joined a global telecom and stayed for eight years. That doesn't happen by accident. It happens because the problems keep getting bigger, the infrastructure keeps getting more interesting, and because at a company that size, "3rd line support" means you are the last line before an outage becomes someone's very bad week in the press.

Global network monitoring. Infrastructure deployments across continents. Incident response for failures affecting thousands of business customers simultaneously. The kind of environment where calm is not a personality trait — it is a professional requirement, developed through enough situations where the alternative wasn't useful.

By year two, the network felt less like a technical system and more like a living thing with predictable moods. By year eight, it felt like a language — one with very unforgiving syntax, but a language nonetheless. Eight years is long enough to see patterns. Long enough to notice that most outages share the same root cause: humans doing repetitive things under pressure. Long enough to start thinking, seriously, that there had to be a better way.

The First Script That Changed Everything

Moved into an IP engineering role. Building internet infrastructure from scratch, managing transit at scale. Solid work with concrete results. But there were too many steps in every process. Too many things done by hand that didn't require human judgment — only human execution. Which is exactly where humans make mistakes.

Wrote the first automation scripts. Not elegant. Not production-ready at first. But they worked. Hours of manual work reduced to minutes. Mistakes that used to happen quietly, caught before they reached the network. Something clicked.

The idea — that infrastructure should manage itself wherever possible, and humans should focus on the decisions only humans can actually make — became less of an idea and more of a conviction. It never went away after that.

Designing for Scale

Joined a global internet service provider as a senior engineer and, eventually, an architect. The scope was large: data centers, global ISP infrastructure, EMEA operations, enterprise customers who needed things to work and didn't want to hear about why they didn't.

The migrations were the part worth remembering. Moving entire infrastructure platforms — the kind of thing that in theory should take hours of downtime and a lot of apologetic emails — with less than five minutes of actual customer impact. That number didn't happen by luck. It happened because of meticulous preparation, because automation removed the steps where human error liked to hide, and because of enough accumulated incident experience to design specifically around the points where things go wrong.

Automation became the thread running through everything here. Not as a side project, not as an experiment, but as a fundamental part of how the work was done. Every repetitive process was a candidate. Every manual step was a risk waiting to materialize at the worst possible moment.

Led SD-WAN transformations for organizations that had been promised the technology would simplify their lives. Made sure it actually did.

Built from Nothing

Joined a mission-critical engineering team with one job: build a cloud infrastructure platform from the ground up. No existing system to work from, no legacy to untangle, no "how we've always done it." Just requirements, a deadline, and the words "mission critical" attached to everything.

Designed the architecture, automated the deployments, integrated the components, led the design decisions throughout. The goal in environments like that is for nothing interesting to happen in production. It was an uneventful launch — which is the highest possible compliment you can receive in that line of work.

All the Hats

Moved into consulting. Technical project lead: client requirements in, architecture out, delivery managed end to end. Fourth-line engineer when escalations came in that nobody else could close. Architect when clients needed someone to think further ahead than the current quarter.

It was the year that confirmed something important: the part of the work that is most satisfying is not the technology itself. It is watching an organization move from chaos to clarity. From "we don't really know what we have" to "we have a system, and it works, and we understand why."

That realization was the beginning of what came next.

Automating the Unamovable

The biggest and most complex project so far: lead NetDevOps at a large Dutch government organization. Critical infrastructure. Thousands of dependencies. The kind of environment where the phrase "we'll fix it in production" is not an option, and where the word "automated" makes procurement teams nervous until you show them exactly what it means.

The mission was to take a massive, business-critical network fabric and make it fully automated — without breaking anything that people across the country depended on, without causing incidents, and with the kind of discipline that government-scale infrastructure demands.

Built the automation framework from scratch. Designed how changes would be validated before they touched the network. Built the pipelines, the safety checks, the deployment controls, the logging. Turned processes that previously required careful manual coordination — the kind where one missed step causes an outage — into repeatable, audited, automated runs that anyone on the team could execute confidently.

Led the team building the next generation of tooling. Watched engineers who started the project cautiously end it with the kind of confidence that only comes from having shipped something real in a hard environment. That part was quietly one of the most satisfying things in the whole twenty years.