The principles I bring to your production

These are the principles I work by. They're here so you know, before our first call, how I'll approach your systems, what I'll build, and where I'll push back. Each one comes from something I built or ran, and each points to the evidence.

1. 01

   The operator owns the blast radius.

   Safety is a decision made at the moment of change, by the person watching it. It isn't a setting inherited from the last incident review. A pipeline that's slow by default doesn't make a rollout safe. It makes it hard to watch, and it teaches people to press deploy and go to lunch.

   “Human judgment is absolutely in the loop.”

   — Henry Robinson

   In practice

   Every rollout I build starts as a dry run. It takes an explicit worker count and a filter for exactly which part of the fleet to touch. It stops on the first real failure and resumes where it left off. The person running it watches the signals as it goes, and widens or narrows the scope based on what they see right now. The tool guards what they can't see from a terminal, such as whether a lock's holder is still alive or whether a shard changed since the plan, and trusts them with what they can.

   Evidence

   hammerdown, the open-source version of the control plane that can roll an 11,000-node Vitess fleet in 35 minutes instead of 2+ days. The same shape goes back to Oracle's adpatch. The full story → And what happened when I left a brake off: A dropped SSH session is not a dead roll →

   What to expect from me

   I'll automate the mechanics hard, so watching a rollout is cheap and stopping one is instant. I'll push back on any process that takes the human out of the loop and calls the result safety. A deadline set last quarter doesn't know who's on call tonight, so I won't treat it as a safety input.

2. 02

   Judgment for people and models. Computation for code.

   A language model is good at deciding what to look at next. It's bad at producing the same number twice. So I split the work: Claude orchestrates and interprets, deterministic parsers compute everything that must repeat, and an engineer owns the intent and approves anything that changes state.

   In practice

   Runbooks are guidance with confirmation gates that stop for a human before anything changes. Analysis is a tested Go or Python program, not a prompt. If a number goes into an incident write-up, a program produced it.

   Evidence

   The OPS Framework, which made Claude Code the execution engine for on-call on a Vitess fleet, with sherlock-analyze doing the math.

   What to expect from me

   I use Claude heavily and I'll say so. I won't put a model's arithmetic in front of you as fact.

3. 03

   Provision like cattle. Maintain like pets.

   You create a database once and look after it for a decade. Provisioning should be automated, repeatable and forgettable. Maintenance is different: upgrades, restarts and failovers need care, history and judgment specific to each fleet. They're two problems, and they deserve two tools.

   In practice

   Provisioning becomes a pipeline nobody has to think about. Maintenance becomes a control plane an operator drives: explicit workers, scoped by filters, stoppable and resumable at any point.

   Evidence

   I'm the first-named inventor on US 11,693,748, Systems and methods for provisioning and decoupled maintenance of cloud-based database systems, from my database platform work at Auth0. hammerdown is the maintenance side, open source.

   What to expect from me

   I'll ask how your databases are cared for after day one, not just how they get created.

4. 04

   Measure at the resolution of the failure.

   If an incident lasts 30 seconds and your metrics average over five minutes, you're debugging a rumor. Before we argue about a fix, I make sure we can see what actually happened, at the moment it happened.

   In practice

   High-resolution capture where it matters, kept long enough to rewind after the host is gone. Every replica compared at the same timestamp, not each at its own peak.

   Evidence

   Sherlock: 5-second snapshots on more than 11,000 database servers, 14 days of replay, and 15 production incidents investigated with its data in 2026.

   What to expect from me

   Early on I'll ask what you can't see today. Sometimes the first deliverable is visibility, not a fix.

5. 05

   A mistake should cost one session, once.

   Lessons that live in a postmortem doc or in someone's head get relearned. Lessons that live in the tool don't.

   In practice

   When something goes wrong, the fix goes into a runbook's pitfalls, a guardrail, a default or a test, where the next run hits it automatically, whether a person or Claude is driving. Every command is logged with context, so the team can see what was done and find how it was solved last time.

   Evidence

   The OPS Framework's pitfalls, treated as hard constraints, and its searchable command log. And a time I broke this rule myself: a safety check I'd learned once got lost when I ported a tool into hammerdown, because it lived in code, not in a test. It's a test now. The write-up →

   What to expect from me

   My handoffs include the guardrails, not just the code. I'll ask to turn your recurring incidents into checks.

6. 06

   A boring core, owned by your team.

   The tools that run production at 3 a.m. should be small, readable and light on dependencies. They should belong to the people who carry the pager.

   In practice

   The standard library where possible. One place where integrations are wired in. Plain-text output you can grep. Docs and a CLAUDE.md, so your team and their assistants can extend it without me.

   Evidence

   hammerdown: standard-library Go, Apache-2.0, built to be forked and made your own.

   What to expect from me

   When the engagement ends you keep everything, and you won't need me to run it. I'll push back on lock-in, including to me.

7. 07

   A runbook is not training.

   A runbook can tell you an operation is dangerous. It can't make it routine. Scary work becomes boring through supervised repetition, not reading. Slow is smooth, and smooth is fast.

   In practice

   A new operator runs dry runs, then a canary, then a real roll with someone who knows the tool's sharp edges beside them, and gets signed off before running solo. Count trained operators per timezone: two is one, and one is none. Training is mandatory and backed by leadership, not tribal knowledge picked up on the job.

   Evidence

   The handover week of a hammerdown build ends with a canary roll that your team runs, with me there. Why that matters →

   What to expect from me

   Every tool I hand over comes with your operators having run it, not just a document about it. I'll ask who else can run it before I call it done.