About
I lead technology transformations and help organisations build and ship better software, more efficiently. Engineer, architect, technical leader, director: the titles changed, the interest never did. What follows is not a CV: the four turning points in how I see the work, then the six dimensions of the role I hold today and the principles behind my decisions
Engineer
Computing has been a passion of mine ever since I discovered QBasic. I started out building network applications, then moved to web applications when Ajax arrived, for banks, media companies and telecom operators, with migrations and performance benchmarks along the way. The job was about delivering, of course, but also about making sure that what we delivered stood up to the real world.
Before long, the most interesting problems were no longer in the code I was writing but in the system around it. The architecture had grown in layers, without an overall plan, and its dependencies were making change increasingly costly.
That is where two convictions I still hold took shape. Simplicity is not a beginner’s virtue but the hardest thing to keep, and software is read far more often than it is written, so code is above all a way of communicating with the people who will maintain it.
Architect
Decomposing systems by domain, introducing event streaming and containers, and standardising REST APIs: my years in architecture have taught me that the hard part is not writing code but defining boundaries that allow systems to evolve in production. A good boundary survives the next three features; a bad one is paid for on every one of them.
They also taught me what an architecture is for. Not a diagram to admire, but a set of decisions that make the next decision cheaper: where to put a change, how to test it, how to ship it without losing a weekend. That is when I understood that delivery is part of the architecture, not a step that comes after it.
Technical Leader
An architecture only truly exists once a team has made it its own. Before that, it is just a drawing. Coaching Scrum teams, steering excellence programmes for large IT departments and teaching Craftsmanship, DevSecOps and domain-driven design moved my attention from the design itself to what makes it hold: the practices, the tooling and the people. Continuous delivery, security built in from the first commit, tests that let you change your mind.
Two things stayed with me from those years. Technical debt is a business conversation before it is a technical one, and the conversation is lost when engineers cannot put it in the terms of the people who pay for it. And knowledge that is not shared does not scale: I taught because it was the only way to change more code than I could write.
Director
Today the questions concern a whole organisation, and I have learnt to prepare the decisions in the rooms where they are made: executive and project committees, alongside CIOs and digital leaders. My work is now about what an organisation funds, stops or transforms: auditing a programme, deciding on a roadmap, sizing the teams and budgets that carry it, and answering for it to a CIO or an executive committee.
The six dimensions that follow describe that role. I stay close to the code, not to write it in place of the teams, but because I trust no direction I could not explain to an engineer.
Six dimensions of technology leadership
One role seen from six angles, and how I approach each
Technology Strategy & Transformation
A technology strategy is only useful when it sets a course the organisation can follow in practice. I have seen too many elegant target architectures never leave the slide deck because they ignored the existing estate, the teams that ran it or the budget that had to pay for them.
So I start from the business and work back to the technology: which foundational choices, which investments, what to modernise, in what order. Transformation then becomes a matter of pace: fast enough to matter, gradual enough for the new capabilities to take hold.
Engineering Organisation & Excellence
An engineering organisation is a system, with boundaries, dependencies and feedback loops of its own. It can be designed as one: an operating model, clear accountability, shared standards and communities that keep practices moving.
Engineering excellence cannot be mandated; it is measured and defended. Tests a team can trust when it changes course, an automated delivery pipeline, technical debt made visible to those who fund it: that is what lets an organisation hold quality and speed together, and it is where I start when I work with one.
Architecture & Technology Foundations
Few decisions bind an organisation for as long as its architecture does. A well-placed boundary, a well-chosen platform, a distributed system built to survive failure: each locks in years of cost and capability, and they are rarely undone cheaply.
I have kept that depth, from event streaming to cloud platforms, not to decide for the architects but to make the call knowing what is at stake. At organisational scale, it is what separates a necessary modernisation from an expensive fashion, and tells you when a decision can wait.
AI & Emerging Technology
Generative AI is not an end in itself: it changes the economics of engineering. As the cost of writing code falls, value moves to specification, architecture, verification and judgement. That shift is what an organisation has to manage, not just the purchase of a tool.
I take these technologies from experiment to operational capability: an adoption framework, AI-assisted engineering practices proven on real systems, roll-out one step at a time. One rule never changes: decisions stay human, and quality and security are not negotiable.
Technology Governance & Risk
Technical debt, a vulnerability, a regulatory obligation or a fragile dependency belong on the executive agenda, but they reach the committee in a language it cannot act on. My job is to translate them into comparable options, costs and risks, so that a decision can be made.
The governance I stand for clears the way more than it blocks it: decisions written down with their reasoning, explicit trade-offs, security and resilience designed in from the start. Making risks governable is what lets an organisation take the right ones without being paralysed by the rest.
From Strategy to Execution
A strategy only exists once it has landed: in priorities, trade-offs and milestones, and above all in the teams that have to carry it. I break it into steps the organisation can absorb, each with a result that can be measured and an owner who answers for it.
This is the part of the role I care about most. It takes presence, consistency and the willingness to revise the plan when the ground says otherwise, without losing sight of the direction. That is the difference between a strategy that was presented and one that was carried out.
How I think about technology
What guides my decisions, from the executive committee to the code
Technology serves a roadmap, not a stack
No technology is worth anything on its own. Its value is the capability it gives the business in two or three years, set against what it costs to get there. A technology strategy says no as often as it says yes.
Architecture is a decision-making discipline
An architecture is not a drawing to protect but a set of decisions that make the next one cheaper. The ones I am proud of survived changes nobody had planned for, because they were simple and their reasons were written down.
An engineering organisation is a system too
The decisions I have seen hold were not the clever ones but the ones a whole team understood and could defend. An organisation can be designed like a system: clear boundaries, short feedback loops, practices that travel.
Delivery is part of the architecture
How software is built, tested and deployed is part of the system, not a step after it. A design that cannot be shipped in small, safe steps is not finished; software that has to last stays in continuous delivery for as long as it is in use.
Strategy only matters when it lands
A roadmap presented to a committee has not changed anything yet. It matters once the teams have made it their own, the results can be measured and the practices hold after the programme ends.
AI changes the economics of engineering, not the accountability
AI writes code faster than any of us. It cannot decide whether the code should exist, what it must never do or when it is good enough to ship: that judgement stays with the engineer, and so does the responsibility. When code costs nothing, judgement is worth everything.