How I Work
These are the principles that shape how I lead, build, and make decisions. They’re not a manifesto — they’re patterns I’ve developed over years of shipping software in production healthcare systems where the stakes are real.
🔓 Open Source First
Before evaluating a commercial product, I ask whether an open-source solution can do the job. Not because free is always better, but because open-source gives you something money can’t buy: full visibility into what your system is actually doing.
This isn’t dogma. When a commercial tool genuinely earns its cost — in time saved, reliability gained, or complexity avoided — I’ll use it. But the default assumption is: start open.
🌿 Trunk-Based Development
Long-lived branches are where integration problems go to hide. I push teams towards trunk-based development with short-lived feature branches, feature flags, and continuous integration that actually integrates.
The discipline of merging to main frequently forces the conversations that matter: is this actually done? Is it safe to ship? Is it behind a flag if not? The answer to those questions is more valuable than any branching strategy.
📦 Everything in Git
If it’s not in version control, it doesn’t exist — or worse, it exists in an unknown state on a server somewhere. Build pipelines, deployment definitions, infrastructure config, runbooks: all of it belongs in Git.
This includes CI/CD. Our TeamCity configuration lives in the repo as Kotlin DSL. Our Octopus Deploy processes are managed as OCL Config as Code. When something breaks, the history is right there.
🔭 Instrument First, Optimise Second
I’ve seen too many performance “improvements” that fixed the wrong thing. Before you optimise anything, you need to know — with data — what’s actually slow.
This is why I invest heavily in observability: OpenTelemetry instrumentation on every service, distributed tracing with Tempo, structured logging with Loki. When something goes wrong at 3am, the trace is already there. You’re not guessing.
🏗️ Right-Size the Architecture
Not every problem needs microservices, Kubernetes, or an event-driven architecture. The best architecture is the simplest one that can handle your actual scale — not the scale you imagine you might one day reach.
I run HashiCorp Nomad instead of Kubernetes because at our scale, Nomad does everything we need with a fraction of the operational overhead. Simple beats clever, every time.
🧠 Data-Driven Decisions
Opinions are cheap. Metrics are not. Whether it’s a technical decision or an organisational one, I want to see the data before committing to a direction.
This applies to team health too. Deployment frequency, lead time, change failure rate, mean time to recovery — these numbers tell a story about how well your engineering organisation is actually functioning, and they’re harder to argue with than gut feelings.
🤝 Teams Deliver, Leaders Enable
My job as a CTO is not to be the smartest engineer in the room. It’s to build an environment where smart engineers can do their best work without unnecessary friction.
That means removing blockers, making technical direction clear, investing in tooling and developer experience, and trusting people to own their work. The best teams I’ve been part of didn’t need a lot of management — they needed clarity and space.
🔁 Boring Technology is Good Technology
The most exciting thing about production infrastructure is when nothing happens. I choose proven, well-understood tools over shiny new ones — especially in healthcare where reliability is non-negotiable.
New technology earns its place by solving a specific problem better than what we have. It doesn’t get adopted because it’s interesting at a conference. Boring scales. Boring is maintainable. Boring is what lets you sleep at night.
If any of this resonates — or you disagree strongly with something — I’d love to hear it. Find me on LinkedIn.