how I think
Principles, earned in practice.
I write about engineering leadership, technical organisations, and the decisions that connect them. These five principles are the shortest version of what I've learned — each earned on real projects, each linked to the story and evidence behind it.
Team boundaries have architectural consequences.
Teams don't just maintain architecture. The way teams are structured often shapes it — interfaces harden where organisations harden, and problems slow down at every seam where ownership is ambiguous.
Don't build what the ecosystem can build better.
Engineering ownership is valuable when it creates differentiation. Otherwise, it can become a distraction from the product. We are not in the business of building an SSR framework — or any infrastructure a mature ecosystem already provides.
Shipping is an organisational capability.
A team that cannot release is not necessarily facing only a deployment problem. Inability to ship usually reflects ownership, architecture, process, risk management, or structure — and it deserves leadership attention as a symptom, not just a mobile team's backlog item.
Technical problems don't always need technical solutions.
Sometimes the fastest way to improve engineering output is to change who owns what. The hardest debugging I've done has been organisational: finding where ownership went shared, and making it explicit again.
Build software, then build the organisation that can build it sustainably.
This one is the through-line of the whole site. Technical wins that depend on one person's heroics don't survive that person's departure. The durable version of any technical achievement is the organisation that can repeat it without you.
These principles come straight from the work documented in my professional experience — and the counterweight to them is the honest list in things I'd do differently.