Skip to main content
Anthony Humphreys
Architecture, delivery, judgement

Technical Leadership

I work best where unclear goals need turning into useful systems, sensible architecture, and delivery plans that a real team can live with after the launch confetti has been vacuumed up.

How I think about problems

I start by separating the goal from the assumed solution. Sometimes the first proposed build is right. Sometimes it is just the meeting's favourite hat.

Before choosing the architecture, I want to understand the user need, organisational constraints, risk profile, delivery timeline, and the team that will maintain the system afterwards. That context changes what good looks like.

Making choices clearer

The useful work is making choices explicit, risks visible, and delivery less theatrical.

Translating vague ideas into practical technical options.
Identifying risky assumptions early, before they become expensive folklore.
Balancing user value, delivery speed, maintainability, security, and cost.
Deciding what not to build yet.
Connecting architecture choices to the service people actually have to run.

Architecture judgement

AWS Certified Solutions Architect - Professional, used as a way to reason about systems rather than a licence to recite service names at innocent bystanders.

Cloud architecture in delivery context
The interesting questions are usually about ownership, risk, failure, change, and cost. The stack matters because those things matter.
Serverless and cloud-native systemsEvent-driven architectureIdentity, permissions, and data flowDeployment, observability, and release confidenceReliability, failure modes, cost control, and operational support

Architecture principles

The principles I keep coming back to when technical choices need to become something people can build, run, secure, and improve.

Start with the service shape, not the diagram.
Architecture should make the service easier to build, run, secure, and evolve.
Optimise for the team that owns it.
The best architecture is not always the most elegant one; it is the one that fits the people, constraints, budget, risk, and expected rate of change.
Make failure boring.
Good systems have failure modes that are understood, logged, recoverable, and unsurprising.
Cost is a design constraint.
Especially with cloud and AI systems, usage and scaling costs should be visible and intentional.
Security should be structural.
Security works best when it is built into identity, permissions, data flow, deployment, and operational practice from the start.

Command Palette

Search portfolio actions