Lead Engineer · Sydney, Australia
Designing systems that last, and teams that can own them.
I write about resilient distributed systems, the engineering judgment that keeps them safe now that AI makes code cheap, and leading the engineers who build them. Drawn from building and modernising enterprise platforms where mistakes are expensive.
Product R&D at a CMS vendor · global digital agencies · regulated enterprise. Now leading engineers through AI-assisted delivery.
Australia · Italy · Malaysia · Bangladesh
Three areas I work in
All articles →Systems fail at the boundaries: ordering, timing, retries and who owns the data. I write about designing for those failures before production finds them.
Start withLast write wins, and the customer loses3 articles →Safety is a permissions problem before it’s an approval problem. Agents, guardrails and review, where mistakes are expensive.
Start withHuman-in-the-loop is not a security boundary2 articles →Making good decisions possible without being in every one: ownership, honest feedback, and judgment that grows in the team.
Start withTech debt snowballs, then it avalanches4 articles →Also: 8 notes on what I'm reading, a bookshelf, and 15 earlier Sitecore & .NET posts.
Recent articles
All articles →- One person owns the outcome. The team owns the solution.James Stanier argues every project needs one named owner. I agree, with one adjustment for enterprise teams: individual accountability without individualising the work. What named ownership will and won't fix, and how I'm going to test it.4 min read
- Human-in-the-loop is not a security boundaryTwo AI agents deleted production databases. Neither was stopped by its instructions. Approval improves an agent's decisions; it doesn't limit what the agent can do. Why agent safety is a permissions and architecture problem first, how to size the risk of an action, and what humans are actually for.8 min read
- Tech debt snowballs, then it avalanchesTechnical debt rarely fails slowly. It grows quietly for months, then one day nothing can move until it's fixed. How to spot the snowball, why you don't get to choose the avalanche day, and what a lead can do before it arrives.5 min read
- Deep Work, read as a lead engineerCal Newport's Deep Work argues that focus is getting rarer just as it becomes more valuable. Three ideas I'm taking from it, and the tension it doesn't resolve for anyone who leads a team.3 min read
- Don't build business logic on an expiry notificationA background process that was going to be triggered by a cache telling us a key had expired. Why that's fragile, the queue-and-scheduler design we chose instead, and why we deliberately stopped short of a full event-driven rebuild.4 min read
- Last write wins, and the customer losesA multi-tab bug that looked like a one-off defect turned out to be a design assumption the product had outgrown. Why I argued for fixing the model, not just the bug, and how to raise that kind of risk.3 min read
- Release risk usually isn't in the codeMost release risk I've dealt with wasn't a software defect. It was environment differences, unclear ownership of manual steps, late changes and rollback plans nobody had tried. What I learned preparing a high-risk platform migration.3 min read
- Being right is not the jobCong Wang's essay on why he stopped arguing, a 2,500-year-old line from Lao Tzu, and what changes when you're the one who has to make technical decisions stick.2 min read
- Moving my blog off WordPress with an AI agent: what I delegated, and what I didn'tI migrated this site from WordPress to a static site in one afternoon, working with an AI agent. The speed was impressive. The more useful lessons were about where the agent stopped and I had to decide.4 min read