About
Not a conventional biography — a map of how the work compounds.
I started as a software engineer concerned with building better software. Over time the problems became larger—architecture, distributed systems, teams, delivery systems and eventually engineering organisations across fintech, enterprise SaaS and multi-region platforms. That progression did not move me away from technology. It changed the altitude at which I work with it. Today I care as much about clarity, ownership, operating models and measurable outcomes as I do about platforms and architecture. I lead at the intersection of technology, people and business: helping engineering organisations make better decisions repeatedly, adopt AI with discipline, and turn technical capability into commercial advantage. The through-line is leverage—building systems, teams and practices that compound. I still care deeply about craft and architecture, but my primary focus is designing the conditions under which good engineering happens repeatedly: healthy teams, clear technical direction, pragmatic platforms, and feedback loops that keep delivery honest.
I did not start my career wanting to manage engineers. I started by wanting to understand how things worked.
That curiosity took me deep into software engineering — writing production systems, solving integration problems, working with databases and APIs, building distributed systems, and taking blockchain work into production: Solidity smart contracts deployed to the Ethereum Virtual Machine, sitting behind real payments in both traditional currency and crypto.
Over time, the problems changed. The question stopped being "How do I build this?" and increasingly became "How do we build this reliably, repeatedly and at scale?"
That shift changed my career.
My foundation is hands-on software engineering. I have worked across application development, APIs, integrations, payments, cloud platforms and distributed systems, including environments where reliability and transaction processing are business-critical.
That technical foundation still influences how I lead today. I believe engineering leaders should understand the consequences of architectural decisions, technical debt and delivery shortcuts — even when they are no longer writing every line of code themselves.
As my responsibilities grew, so did the scope of the problems. Instead of solving one technical problem, I became responsible for creating environments where teams could solve hundreds of them.
That meant learning how to build teams, establish engineering practices, improve delivery predictability, develop engineers and create clearer accountability between product, engineering and the wider organisation.
My focus expanded from code quality to organisational capability.
Architecture became the bridge between those worlds. Not architecture as diagrams for their own sake, but architecture as a way of answering practical questions:
This led me deeper into solution and enterprise architecture and strengthened the way I connect engineering decisions with business outcomes.
Today, much of my work revolves around what I call the engineering system.
The engineering system includes the architecture, people, processes, tooling, standards, feedback loops and leadership behaviours that determine how effectively an organisation can turn ideas into reliable software.
Architecture Developer experience Delivery flow Quality Security AI-assisted development Team topology Technical strategy Engineering metrics Talent development Organisational design
Improving one in isolation rarely transforms an organisation. Improving the system does.
The next evolution of software engineering will not simply be developers writing the same software faster with AI. AI changes the economics of software creation.
That means engineering organisations need to rethink how requirements are expressed, how software is verified, where human judgement matters, how architecture is governed and what engineering leadership looks like when implementation becomes increasingly automated.
That intersection — AI, architecture and engineering leadership — is where much of my current thinking is focused.
How I think
Teams rarely move slowly because they cannot code fast enough. They move slowly because requirements are unclear, decisions remain unresolved, dependencies surface late or ownership is ambiguous. We ought to paint a picture of what good looks like, so teams stay in sync and know the expectation on each deliverable before the work starts. Speed is usually the result of that clarity.
Every deliverable needs a defined target. Where the outcome is left vague — no acceptance criteria, no definition of done, no agreed measure of success — teams rarely fail loudly. They quietly deliver something, and nobody can say afterwards whether it was the right thing. We ought to define what we are aiming at, because if we aim at nothing we will surely hit nothing.
The best architecture does not attempt to predict every future requirement. It creates enough structure to solve today's problem without making tomorrow unnecessarily expensive.
DORA metrics, cycle time, reliability data and quality signals are useful. But a metric should tell you where to investigate — not automatically tell you whom to blame.
Not all technical debt is bad. Sometimes accepting debt is the correct business decision. The mistake is allowing temporary compromises to become permanent architecture without consciously making that decision.
One of the clearest signs of leadership maturity is what happens when the leader is not in the room. Strong leaders create other decision-makers.
Working with me
I stay close enough to architecture and engineering decisions to challenge assumptions and understand risk, without becoming the bottleneck through which every technical decision must pass.
Ambiguous ownership, unclear requirements and inconsistent delivery processes create unnecessary friction. I prefer explicit expectations, clear decision rights and lightweight engineering systems that make good execution easier.
Senior engineers should not simply receive more difficult tickets. They should progressively own architecture, technical direction, mentoring and engineering decisions.
Engineering excellence that cannot connect to customer value, risk, revenue or strategic priorities eventually loses organisational support. Technical strategy should make the business stronger.
Engineering organisations are never finished. The objective is to create feedback loops that allow teams to continuously improve delivery, quality, architecture and developer experience.
Software engineering foundation — shipping product and learning systems under real constraints.
Systems, platforms and cloud — designing for scale, integration and operability.
Teams, delivery and organisational performance — building the conditions for sustained execution.
Technology aligned to business outcomes — connecting architecture choices to organisational advantage.
AI-enabled engineering, emerging practices and new ventures — extending the operating system.
Capabilities
These describe operating range across engineering leadership, architecture and platforms.
Certifications
Technical foundations that complement engineering leadership experience.