About

Software becomes most interesting to me when somebody has to make a consequential decision with incomplete information: a support engineer tracing a delivery problem, a user deciding whether an imported CV is accurate, or a developer deciding whether agent-written code is safe to apply.

My job in those moments is to make the relevant state, ownership, and next action clear enough that a person can move without guessing. That preference comes from work in university platforms, governed medical-data tooling, messaging delivery, and the products I now build independently.

How I work

Frame the decision before the implementation

I establish the user outcome, constraints, risky transitions, and evidence of completion before choosing a technical shape. Decisions affecting stored data, billing, privacy, delivery, or another team's ability to operate deserve a written rationale and visible uncertainty.

Review the artifact, not the narration

A confident summary is useful context, not proof. I inspect the changed document, code diff, test result, browser state, migration plan, or production signal behind it. With AI-assisted work, model output remains a proposal until a person has reviewed the relevant change and checks.

Design for operation, recovery, and ownership

Failure states, logs, alerts, support routes, recovery behaviour, and ownership should inform the interface and architecture from the start. The aim is enough signal to distinguish what happened, who can act, and whether the next step is safe.

The same applies when ownership moves between teams. A receiving team needs the operating map, decision history, known risks, and a way to test its readiness—not only an architecture presentation. I wrote about one employer-safe example in The handover is part of delivery.

Coach toward independent judgement

When managing and reviewing engineers, I care about the reasoning behind a choice as much as the choice itself: the trade-off, what could invalidate it, how it will be checked, and who owns it afterwards. Review should spread decision-making capacity rather than make every decision wait at one gate.

Background

My experience runs from computer-science teaching and university platforms through medical tooling and messaging infrastructure, where I progressed from senior engineer to technical team lead. Today I build Masterful CV and Consortio independently. The skills index keeps the supporting technology evidence separate from this page.

Get in touch

I am selectively open to senior product-engineering and hands-on technical-leadership opportunities. If you are working on product systems where delivery, reliability, and human judgement need to fit together, email me. You can also see my dated Now page.