CH·01

Before everything was connected

Early computing years

A home computer, a DOS prompt, analog phone lines — and a Linux CD that arrived by international post.

  1. Early computing years

    A computer at home

    It started with Windows 95 and Norton Commander: two blue panels, a keyboard, and a file system to explore. There was no internet to fall back on, so the operating system itself was the playground — install, break, reinstall, and slowly learn what a computer actually is.

    Every abstraction I would later depend on professionally was, at some point in those years, something I had to physically reinstall at 2 a.m.

    • Windows 95
    • Norton Commander
    • x86 hardware
  2. Early computing years

    Analog systems before digital ones

    Before digital networks, there were analog systems to understand — wiring, signals, the physical layer that everyone forgets once it works. Hands-on time with analog equipment taught me that every 'virtual' thing eventually touches something real.

    Twenty years later I still trace problems down the stack to the physical layer first. That instinct was built here.

    • Analog telephony
    • PSTN basics
    • Electrical wiring
  3. Artifact

    Early computing years

    The CD in the mail

    I filled in a web form on a borrowed connection and waited. Weeks later, an envelope from the Netherlands arrived with a pressed Ubuntu Linux CD inside — an operating system shipped across a border, free, by post. I installed it, and the command line became home.

    That disc was my first direct contact with the open-source world: strangers on another continent, mailing a stranger the tools to learn. Everything I've built since runs on what that envelope started.

    • Ubuntu Linux
    • CLI
    • Open source

CH·02

Voice over someone else's network

2007

VoIP administration at Tel4Tel: the moment telephony stopped being wires and became software.

  1. 2007

    VoIP Administrator — Voice becomes software

    Tel4Tel

    At Tel4Tel I administered VoIP systems: call flows, SIP trunks, codecs, gateways. Telephony — the century-old empire of copper and switches — was being rewritten as applications, and I was on the team doing the rewriting for real customers.

    This is where the two halves of my future met: the analog discipline of the phone network and the programmable logic of software. Voice stopped being physics and became configuration.

    • VoIP
    • SIP
    • Asterisk
    • Gateways
    • Codecs

CH·03

Under the cables at FCP

2011 – 2018

Technical support, network engineering, then VoIP expertise at FCP — learning the whole stack from ticket queue to trunk.

  1. 2011

    Technical Support / TSD — Learning by answering the phone

    FCP

    Joining FCP in technical support meant owning the moment when things break for real users. Every ticket was a lesson in how systems actually fail — and how people experience that failure.

    Support taught me the most durable engineering skill I know: reproduce, isolate, verify. It's also where I learned that reliability is a form of respect.

    • Ticketing systems
    • Networking
    • Windows / Linux
  2. 2012

    Network Engineer — Under the cables

    FCP

    A year later I moved into network engineering: routing, switching, firewalls, the paths packets take. From inside the network, 'the cloud' stopped being a marketing word and became routers, tables and failover plans.

    Networks are the nearest thing infrastructure has to a nervous system. Once you've traced a packet across one, every abstraction above feels earned.

    • Routing & switching
    • Firewalls
    • VPN
    • BGP
  3. 2012 – 2018

    VoIP Expert / Manager — From trunks to teams

    FCP

    At FCP I grew into VoIP expertise and eventually management of the VoIP function — NGN architecture, Cisco VoIP, PBX systems, and the people who kept them alive. Designing call platforms turned into designing how a team operates.

    The hardest scale-up was never the call volume; it was the coordination. Managing engineers taught me that most 'technical' problems are actually interface problems between humans.

    • Cisco VoIP
    • NGN
    • PBX
    • SIP trunking
    • Team leadership

CH·04

The abstraction ladder

2019 – 2022

Cloud engineering and support leadership at a global-scale cloud provider: from physical hosts to fleets, from fixing to coordinating.

  1. 2019

    Cloud Engineer / System Administrator — Into the datacenter era

    Global-scale cloud provider

    Moving to a global-scale cloud provider in 2019 meant living inside the abstraction ladder: physical hosts, virtualization, orchestration, automation. Systems I had administered one by one now existed as fleets with dashboards.

    The ladder — physical, virtual, cloud, cloud native — isn't marketing. Each rung changes what 'failure' means and who can fix it.

    • Virtualization
    • Linux at scale
    • Automation
    • Monitoring
  2. 2020

    Team Lead — Customer Service & Support — Leading the room where it never sleeps

    Global-scale cloud provider

    Leading the customer service and support function meant owning incidents end to end: the escalation paths, the runbooks, the handovers, and the humans at 3 a.m. In the year the world's traffic moved indoors, this was where the internet stayed up.

    Incident response is applied epistemology: what do we know, how do we know it, and who needs to know it next? Everything else is keyboard work.

    • Customer service design
    • Incident management
    • On-call
    • Runbooks

CH·05

Infrastructure as a product

2022 – present

Technical product management for services used by hundreds of thousands of people — turning reliability into something you can design.

  1. 2022 – present

    Technical Product Manager — Infrastructure as a product

    Global-scale cloud provider

    Since 2022 I've worked as a technical product manager on cloud services serving hundreds of thousands of users — deciding what gets built, for whom, and why, with the infrastructure discipline of the previous decade behind every choice.

    A product manager's job at infrastructure scale is translation: users' needs into architecture, architecture into roadmaps, roadmaps into promises the ops floor can keep.

    • Product strategy
    • Cloud services
    • Developer experience
    • Roadmapping

The Ubuntu CD, then and now

Then

A pressed CD in an envelope from the Netherlands, weeks of waiting, an install that had to work the first time — because reinstalling meant another postal round trip.

Now

terraform apply. Whole environments described in code, provisioned in minutes, torn down and rebuilt without fear. The operating system is the smallest part.

Same curiosity, different ladder. That span — from a postal CD to infrastructure-as-code — is the whole Journey in one artifact.

The abstraction ladder

The datacenter era is easiest to explain as a ladder. Each rung hides the one below it — and changes who can fix what.

  1. Physical

    Bare metal. You touch what breaks.

    Racks, cables, PBX cabinets

  2. Virtualization

    One host, many machines.

    Hypervisors, VMs, snapshots

  3. Cloud

    Location stops mattering.

    Regions, IaaS, elastic scale

  4. Cloud native

    Servers stop mattering.

    Containers, orchestration, services

  5. Intelligent infrastructure

    Configuration starts writing itself.

    Automation, AI-assisted operations