The job is understanding.
Everything else is downstream.
I started in operations, tracing faults across a mobile core built by three different vendors who each swore the problem was on the other side. That is where I learned the thing I still work from: the interesting failure is almost never inside an element. It is in the space between two of them, where nobody's documentation applies.
Everything since has been the same instinct pointed at bigger boxes — signalling, then platforms, then the business case that decides whether any of it gets built. I write it down because an explanation you can't hand to someone else isn't finished.
Configured by hand.
Three areas where I can answer follow-up questions, not just name the acronym.
Mobile core & signalling
Packet core across 2G, 3G and 4G — SGSN, GGSN/PGW, MME, HLR/HSS, DRA, STP. Diameter and RADIUS. MVNO enablement and migration over the core. The part I enjoy most is still reading a trace and finding the message that never came back.
eSIM & IoT connectivity
GSMA SGP.32 remote provisioning, SIM profile development with IDEMIA and Thales, and connectivity platforms wired end to end — FreeRADIUS through to PostgreSQL, event-driven services on Kafka. I wrote the portal spec, then sat with the vendor while they built it.
Cloud-native & automation
Linux from the terminal up (LPIC-1), Docker and Kubernetes/K3s, Python for the parts that shouldn't be done twice — FastAPI, Polars. Infrastructure as code, running on hardware I own and am free to break.
Four things I keep coming back to.
- Read the specification before the vendor's slide. The slide is written to be agreed with; the spec is written to be implemented.
- If I can't draw it, I don't understand it yet. A ladder diagram has nowhere to hide a hand-wave.
- The architecture that survives the deploy is the only one that ever counted. Everything before that is a proposal.
- Translate in both directions. A requirement that only the engineers understand fails in the meeting; one that only the business understands fails in production.
One operator, three vantage points.
Technology Consultant & Solution Architect
Customer-facing consulting and pre-sales, turning what a client actually needs into a connectivity and IoT architecture that can be built. I architect the carrier's eSIM IoT strategy on GSMA SGP.32 — I authored the eIM/eSIM management portal specification and worked through the integration with the vendor platforms. I also handle the technical side of contracts: IMSI licensing, code ownership, the clauses that quietly decide what you're allowed to build later.
Product Owner & IoT Specialist
Owned a nationwide IoT connectivity portfolio running over the mobile network, for MVNOs and enterprise customers. Designed the event-driven architecture behind it — Kafka, microservices, REST APIs — and learned the difference between a system that works and a system that keeps working while nobody is watching it.
Mobile Network Engineer, Core
Deployed and operated the mobile packet core — GGSN/PGW, MME/SGSN, HLR/HSS, PCRF — on carrier-grade infrastructure, and wrote the Python that made the repetitive parts stop being repetitive. On-call taught me more than any course: at three in the morning nobody cares which layer you specialise in.
Still in it.
Specialization, Software Engineering for Applied AI
MBA, Solution Architecture
B.Eng. Electrical Engineering, Telecommunications
AWS CLoud Practioner
LPIC-1, Linux System Administrator
Same habit, different subject.
I read science fiction, Nietzsche and Dostoevsky with the same stubbornness I read an RFC — slowly, and twice when it matters. I write poems, which is the only thing on this page nobody has ever asked me to justify.
And I keep a homelab: a couple of machines running everything I'd never risk trying at work first. It is a laboratory for the same lesson on repeat — things fail, you find out why, they come back.
Ask me something.
If you're stuck on signalling, eSIM provisioning or an IoT platform that stopped behaving, write to me. I answer questions from strangers — it's usually how the next note starts.