From cables to the cloud
In 2009 I was pulling Ethernet cables in a TV company basement and installing FreeBSD on servers nobody wanted to touch. I had no idea that fifteen years later I’d be designing multi-region Azure landing zones for enterprise clients. Nobody does.
Stage 1: Get comfortable being confused
The first few years of any infrastructure career are mostly about learning to sit with confusion. You don’t know why the packet is dropping. You don’t know why the service is down. The skill is not panicking while you find out.
Stage 2: Automate what you hate doing twice
I started writing Bash scripts out of laziness. That’s the right reason. If a task bored me the second time, I automated it. By year four I had a library of small tools that made me look faster than I was.
Stage 3: CI/CD is not the goal — trust is
When I moved into DevOps properly, I thought CI/CD pipelines were the product. They’re not. The product is confidence — the team’s confidence that the code they merged will behave the way they tested it. The pipeline is just infrastructure for that confidence.
Stage 4: Cloud is just someone else’s Linux
Azure, AWS, GCP — at the core, it’s still networking and compute. The abstractions are higher, the blast radius is bigger, and the billing is more confusing. But the fundamentals you learned on bare metal still apply.
Stage 5: Architecture is mostly communication
The hardest architecture problems I’ve worked on weren’t technical. They were about getting four teams to agree on a shared API contract. Or convincing a CTO that the “simple” approach had a hidden cost. Diagrams are negotiation tools.
Stage 6: Learn to say what you don’t know
I spent years pretending to know things I didn’t. It was exhausting and it slowed down every room I was in. Now I say “I don’t know, let me check” faster than anyone else, and my credibility is higher for it.
Stage 7: Coaching made me a better architect
I trained as an NLP practitioner and professional coach in parallel with my technical work. Seemed like a detour. It wasn’t. Understanding how people form mental models, how they resist change, how they get stuck — that’s directly applicable to every architecture review and migration project.
Stage 8: Specialise, but stay curious
I specialised in Azure and DevOps. But I stayed curious about AWS, GCP, Kubernetes internals, AI tooling, live-coding music. The curiosity keeps the specialisation honest — you stop thinking your stack is the only way.
Stage 9: The best infrastructure is boring
The most successful systems I’ve been part of were boring. They deployed without drama, scaled without heroics, and failed gracefully. Interesting infrastructure is usually a symptom of a problem.
Stage 10: Write it down
Every hard lesson I’ve learned that I didn’t write down, I learned again. Every decision I didn’t document, I had to re-justify in a future meeting. Write things down. Future you and future colleagues will thank you.
Stage 11: The human layer is the bottleneck
After twelve years, I’m convinced that most infrastructure failures are people failures — unclear ownership, bad communication, misaligned incentives. The technical fix is usually the easy part.
Stage 12: Start before you’re ready
If I’d waited until I felt qualified to take on each new challenge, I’d still be in that basement. The work makes you capable for the work. Start.