Core Principles
“Get Engineers Engineering”
Remove friction. The best platform work makes it easier for people to do the actual work. If a process or tool is slowing engineers down, that’s the first thing to fix.
“Technology is People”
Delivery speed isn’t always about the technology – it’s often about the people and making sure they’re aligned. The best architecture in the world fails if the people building on it don’t understand it or trust it.
The Constraints Are What Make It Interesting
Regulated environments come with constraints – security, governance, compliance. That’s not a reason to avoid innovation, it’s what makes the engineering problem worth solving. The skill is making the safe path the easy path, so teams can move quickly without having to think about the boundaries.
“Build. Try. Feel. Iterate.”
Core methodology for rapid prototyping and innovation. Don’t design in the abstract – build something, try it, feel whether it’s right, and iterate. This is how you convert emerging technology into practical solutions.
KISS – Start Simple, Uplift When Required
Don’t over-engineer. Start with the simplest thing that works, prove value, then add complexity when you have evidence it’s needed.
YAGNI – You Ain’t Going to Need It
Build for now, not hypothetical futures. Every abstraction layer, every feature flag, every “just in case” adds complexity that slows you down.
“Would It Help?”
Before doing something, ask if it actually moves the needle. Not every problem needs solving. Not every improvement is worth the cost.
Manage Resilience vs. Complexity
Every layer of resilience adds complexity. Be deliberate about the trade-off. Sometimes accepting a small risk is better than building a complex mitigation.
Tech Serves Business Need
Technology for technology’s sake is a trap. Every technical decision should connect back to a business outcome.
On APIs as Innovation Strategy
APIs aren’t just a technical integration pattern – they’re how you unlock innovation safely. When you expose data and functionality through well-governed, versioned interfaces, you create a contract that third parties, internal teams, and AI agents can all build on without requiring direct access to underlying systems.
This is increasingly important as agentic AI drives demand for machine-to-machine interaction at scale. The organisations that have clean API boundaries will be the ones that can safely give AI agents access to their systems. The ones that don’t will either block AI adoption entirely or expose themselves to uncontrolled risk. Getting this right is an architecture problem, a governance problem, and a revenue problem – all at once.
On Architecture-as-Code
Architectural decisions should live in the codebase, not in slide decks or wiki pages that nobody reads after the first week. I’ve moved towards architecture-as-code: well-structured ADRs (Architecture Decision Records) that sit alongside the code they govern, written in a format that’s useful to both humans and AI coding agents.
The reason this matters now more than ever: AI agents need context to make good decisions. An agent that can read your ADRs understands why the system is shaped the way it is – not just what it looks like today. That means fewer wrong turns, fewer PRs that violate architectural intent, and a compounding knowledge base that gets more valuable over time.
This is where AI’s biggest leverage is in enterprise engineering – not generating code, but making the decision layer accessible and machine-readable.
On AI
AI gives the ability to try out 20 options in the time it would have taken to develop one. The most opportune time to be in innovation.
But AI’s biggest leverage point in enterprise engineering isn’t code generation – it’s the decision layer. Decisions made and recorded in machine-readable formats become a platform capability that compounds over time. Every future AI agent, every future design conversation, gets better because decisions are accessible.
On Scale-to-Zero
Scale-to-zero services allow hobby projects at near-zero cost that can then scale to enterprise. This is a philosophy, not just a technical preference: start small, prove value, scale when needed.
On Leadership at Scale
From studying Principal/Distinguished Engineer roles and living them:
- Scope across teams, not within one team. Architecture and design impacting multiple teams, not single-team delivery.
- Communication is the job. Different audiences need different viewpoints. Cross-functional: users, product teams, UX, engineers, business stakeholders.
- It’s not about writing code. A brilliant coder doesn’t automatically make a good principal engineer. The skill is identifying impactful technical problems, getting buy-in, assembling teams, and pushing through to implementation.
- Lead through influence, not authority. Virtual teams across organisational boundaries. No direct reports, but enormous impact.
- Business focus. How does it accelerate the business?
Credibility-First Adoption
The pattern that works in large regulated organisations: build evidence, create advocates, then scale. Don’t try to mandate adoption – earn it.
- Start with a small, visible win
- Build credibility with stakeholders through that win
- Use that credibility to expand scope
- Let organic demand drive adoption
- Then formalise through governance