What I believe
My sporting background shaped how I think about engineering: strong teams beat heroic individuals. The best teams have trust, standards, ownership, and the confidence to challenge weak plans before they become expensive mistakes.
Engineers should be encouraged to ask whether we are building the right thing — not only whether we can build it. Good technical teams do more than deliver code. They improve the system, the process, and the decisions around them.
Understand the real problem. Reduce unnecessary complexity. Build software that works in practice, not just in diagrams.
How that shows up
The same ideas, whether I’m writing .NET on Azure, shaping a product, or coaching a team out of delivery chaos.
Care about the problem
Tickets are a side effect. The job is understanding the customer, the business constraint, and whether this work should exist at all.
Teams over heroes
Trust, standards, and ownership beat individual brilliance. Strong teams challenge weak plans early — before they become expensive.
Practice over diagrams
Clean boundaries and boring reliability matter more than elegant slides. If it can’t be operated without guesswork, it isn’t finished.
Ask the right-thing question
Can we build it is necessary. Should we build it is leadership. Good engineers improve decisions, not only delivery speed.
Security as care
Managed identities, private networks, automation — security that people don’t have to fight. The best control is barely noticed.
If people can’t find it, it doesn’t exist
Don Norman’s idea of discoverability applies as much to architecture and process as to product UX. A well-shaped system invites the next right action — it doesn’t hide behind a wiki nobody updates.
If developers can’t find where a change belongs, if product owners don’t know where the roadmap lives, if teams can’t see what another team is building — those are design failures, not people failures. Poor discoverability erodes autonomy, and autonomy is what accountable teams are made of.
Good design is not decoration; it’s orientation.
Tight loops beat clever plans
Release pipelines, sprint reviews, retrospectives, customer demos — they’re all feedback systems. Without them, even good intentions drift. With them, small corrections compound.
I care whether incidents are discussed or only logged, whether engineers see the impact of their work, and whether customer signal reaches the people writing the code. Observability, shorter cadences, and honest demos aren’t process theatre — they’re how effort stays connected to outcome.
Clean boundaries, boring reliability
I like the engineering side of software: useful abstractions, readable code, sensible data models, and systems you can operate without guesswork. Architecture is conversation as much as code — every service boundary mirrors a human one.
When boundaries are clear, collaboration flows. When they’re ambiguous, confusion grows faster than technical debt. That’s why I still push for writing — RFCs, ADRs, lightweight notes. Writing slows us down just enough to think, and keeps knowledge findable after the meeting ends.
Project finished ≠ product mattered
The shift looks small on a slide. In practice it changes what teams optimise for every week.
Project mindset
“Did we finish?”
Product mindset
“Did it matter?”
Organisations I work with often start with siloed delivery and waterfall muscle memory. Clear product boundaries, empowered roles, and transparent backlogs turn disconnected effort into value streams. The goal isn’t to mimic Silicon Valley — it’s to own your own rhythm of delivery.
Leadership is interface design
Every process, meeting, and channel is part of the interface your team uses to work with the organisation. Design those interfaces on purpose: onboarding that builds confidence, 1:1s safe enough for truth, planning that connects strategy to reality, recognition that reinforces the right behaviours.
The leader’s job is not to have all the answers. It’s to make the right conversations inevitable.
The human in the loop
At home the same ideas show up differently — cooking, science projects with the kids, fixing something in the garden. Each is a small loop of curiosity and learning. That patience feeds back into the work: behind every “user” or “engineer” is a person with their own context and constraints.
We build systems to serve people, not the other way around.
Create environments where people and technology bring out the best in each other
That’s the north star — one product, one architecture, one honest conversation at a time.