About

I am a senior tech lead and a generalist engineer who goes deep in several directions at once. Software engineering, platform engineering, system architecture, data, AI and ML, cloud-native infrastructure, distributed systems. I do not specialise in one of these. The useful work is in connecting them.

What I actually work on

Over the last few years I have built and run an observability service, a DNS service, a model serving platform for LLMs, a model tracking service, and a data platform. Different problems on the surface. Underneath they are the same job: someone asks for a thing, the thing has to appear, and it has to still be working at three in the morning when nobody is looking.

The backend services handle thousands of requests per second. The MLOps platforms were designed from nothing. The cloud-native infrastructure sits under a large engineering organisation, which means the reliability and development standards around it matter as much as the code inside it. I care about writing fast code and about making sure the architecture around it lets a team move without breaking things, and I have never found those two to be in tension for long.

The most interesting piece is also the one I get asked about most: we turned the Kubernetes API into the control plane for a whole cloud platform. Not just containers. S3 buckets, databases, DNS records, IAM credentials, even whole child clusters became Kubernetes resources, defined as manifests, managed with GitOps, reconciled continuously by controllers.

Serving large language models at scale was its own education: acquiring and caching models, putting an OpenAI-compatible server in front of them, authentication, usage tracking for billing, autoscaling, and running several models under one domain without them fighting over GPUs. That work turned into a talk and eventually into genai-gateway, the rate-limiting and metrics layer pulled out into something anyone can run.

Beyond the systems themselves, I put a lot of time into engineering culture. Design documents. Organisation-wide coding and API standards. Mentoring. The shared libraries and templates that make the right thing the easy thing, which is the only way standards ever actually hold. Good engineering organisations are not an accident. They need the same deliberate design as the software.

I work mostly in Go, Python and Rust, across Kubernetes, Terraform and the usual cloud-native tooling. I teach distributed systems at university and speak at conferences. To stay close to the fundamentals I build things like a distributed key-value database in Rust, which is a good reminder of how much the frameworks normally hide.

How I think about architecture

The word architecture has been stretched until it means almost nothing. Everyone is an architect now: data architects, solution architects, customer success architects. I gave a whole talk about this, mostly out of irritation, arguing that we should get back to talking about code.

My actual position is narrower than it sounds. Architecture is the set of decisions that are expensive to reverse. Everything else is just code, and code is cheap to change if you structured it so it can be. That means the useful question is never „is this the best design“ but „what does this design cost me when I am wrong about it.“ I am wrong reasonably often, so I optimise for finding out fast.

In practice this means boring technology in the load-bearing places and interesting technology at the edges. It means a service that owns its data. It means writing the failure mode down before writing the happy path, because the happy path is the part that takes care of itself.

I write in Go, Rust, Python and TypeScript, in roughly that order by volume. Rust gets used more than its reputation suggests it should: not just for systems work but for web services, where the type system catches a whole class of bug before it reaches a review. I made that argument at WeAreDevelopers in 2024 and I still stand behind it.

On teams

The technical work is the easier half.

I gave a keynote at ITCS Darmstadt in 2026 called „Was ein gutes Tech Team ausmacht,“ and the argument holds up: teams that fail rarely fail because the engineers are not good enough. They fail on how they work. Code gets discussed in review instead of tested. Formatting gets debated instead of handed to a linter. Ego gets optimised instead of outcomes. And nobody ever stops to ask whether any of it is working.

The research backs this more than I expected when I started reading it. Google’s Project Aristotle found psychological safety mattered more than raw talent. The DORA metrics in Accelerate show that delivery performance tracks practices, not headcount. Team Topologies makes the case that team structure and system structure end up mirroring each other whether you plan for it or not.

What I take from that as a lead is mostly restraint. My job is to remove the things that stop good engineers from doing good work, and then get out of the way. Set standards so decisions stop being relitigated. Make the pipeline enforce what would otherwise be an argument. Give people problems with enough room to grow into, and be specific about what „done“ means.

I also spend a lot of time on review. Not nitpicking: the classic sign of a struggling team is ten comments on a ten-line pull request and none on the thousand-line one. The big change is where the risk lives, and it deserves the attention.

Outside the terminal

I train calisthenics. It started as a practical choice, since you need almost nothing to do it, and turned into the thing that keeps the rest of my life in order. Progress is slow and unambiguous: either you got the rep or you did not. There is no way to talk yourself into a muscle-up. After a day of decisions where the feedback loop is measured in months, something with an honest answer in ten seconds is a relief.

I also do not really stop building. There is always a side project running: a tower defense game inside Neovim to make vim motions stick, a voice bridge so I can dictate without a subscription, an MCP server so agents stop guessing at documentation they could have read. Most of them exist because I wanted the thing and it did not exist yet. Some of them turned out to be useful to other people, which is a pleasant side effect rather than the plan.

Right now the larger one is a fitness tracker, which is what happens when the training habit and the building habit collide.

I write regularly about all of this, mostly about AI and what it is actually doing to how we work, architecture, and the parts of engineering management nobody puts in the job description.

Two ways to go from here

If you want to talk about something I built, disagree with something I wrote, or just say hello, the contact page is the shortest route. I read everything that arrives there.

If you would rather see how I think before deciding whether that is worth it, the writing is the better starting point.