Approach

Good engineering
is mostly judgment.

Architecture, delivery, people and business rarely pull in exactly the same direction. My job is to understand the trade-offs and make decisions that work beyond the code.

01

Architecture is a
trade-off system

Architecture doesn't exist in isolation. Every structural decision affects delivery, cost, the people building against it and the business maintaining it. I weigh those together rather than optimising for architectural purity.

02

Capability,
not dependency

The best outcome I can leave behind is a team that's more capable than when I arrived. I share context, transfer knowledge and create ownership deliberately, because technical leadership shouldn't create a dependency on the technical leader.

03

Conditions,
not output

I don't manage output directly. I work on the environment that makes good output possible. The conditions underneath the work usually matter more than the effort visible on top.

How I Think

Create conditions.
Trust the team.

Four specific conditions I actively work to put in place for every team I lead.

  1. 01 — Clarity

    People understand priorities, constraints, ownership and why a decision is being made.

  2. 02 — Safety

    People can challenge decisions, admit uncertainty and surface problems before they become expensive.

  3. 03 — Focus

    Friction, unnecessary interruption and unclear dependencies are actively removed so engineers have room to think.

  4. 04 — Growth

    People get autonomy, honest feedback and increasingly difficult problems so capability grows over time.

Practical principles

01

Context over rules

Give people the why — constraints, priorities and trade-offs — so they can make good decisions without waiting for instructions.

02

Protect deep work

Engineering needs uninterrupted time to understand difficult problems. Meetings, dependencies and context switching carry a real delivery cost — often uncounted.

03

Lead close enough to challenge

Stay technically engaged enough to question assumptions, architecture and trade-offs — without becoming the person every decision depends on.

In a nutshell
“ The best thing I can build is a team that doesn't need to route every decision through me. ”
AS

Ideas I return to

  • Team Topologies — Skelton & Pais

    Cognitive load as a design constraint.

  • Accelerate — Forsgren, Humble & Kim

    What high-performing engineering teams actually do.

  • Staff Engineer — Will Larson

    Technical leadership without formal authority.

Let's build something that lasts.

Get in touch →