About

Background

I've been building software professionally since 1999 — before the dot-com boom, when the web was still figuring itself out. That early period taught me a lot about building things with limited tools, moving fast, and not knowing exactly what you're building until you've shipped it.

Over the past 25+ years I've moved through media, gaming (DICE, King, Embark Studios, Star Stable), finance, manufacturing, and e-commerce. Along the way I've been a front-end engineer, principal engineer, solution architect, and technical director. The role has changed, but the work has always been about the same thing: helping teams build software that actually works for the business.

I've worked across a wide range of industries and company sizes. That breadth is deliberate. Patterns that seem unique to one team often aren't — and recognizing them early is one of the most useful things an outside perspective can offer.

Why Yetric

After years inside engineering teams, I started Yetric because I wanted to work on the kinds of problems I find most interesting: teams that are capable but stuck, systems that need to evolve without stopping, and decisions that will still matter two years from now. Being independent lets me focus on those problems without the overhead of a large organisation getting in the way.

It also means I can be honest. When you hire a consultant from a large firm, they have their firm's interests to manage alongside yours. I don't. My only interest is solving the actual problem well enough that you'd want to work together again.

How I work

I don't think great software comes from brilliance. I think it comes from iteration, honest feedback, and teams that trust each other. Most systems don't fail because of the wrong framework or a missing design pattern — they fail because people stop talking, stop adjusting, or optimize for the wrong thing.

I work hands-on. I'm not interested in producing a document and leaving. Whether it's architecture, development, or team process, I stay close to the work, keep feedback loops short, and try to make sure mistakes stay small and recoverable.

I care a lot about leaving a team better than I found it — not dependent on me.