How I lead
Process as the tool, guardrails instead of reminders, AI to raise the ceiling — and the part of the job that is still entirely about people.
I lead through process, not through presence. If a thing only works because I am in the room, it isn’t working — it’s being carried.
Process is the leverage
Most engineering problems I’ve watched go wrong were not capability problems. They were ambiguity problems: nobody knew which decision was already made, where it was written down, or who got to change it. So I spend a disproportionate amount of effort on the boring layer — where decisions live, what “ready” means, what a story has to contain before anyone builds it.
The corollary is that I try never to solve a recurring problem with a reminder. Reminders decay. A rule that fails the build does not. If the architecture must not be violated, that belongs in CI, not in a document someone read once during onboarding. The best version of a process is one nobody has to remember.
Working smart, including with AI
I’d rather a team move fast because the path is clear than because everyone is working late. That’s most of what “working smart” means to me: removing the friction that makes ordinary work expensive.
AI is currently the sharpest version of that lever, and I’m hands-on with it rather than theorising — running agents against my own projects with defined roles and real guardrails, so that what I bring to my team is something I’ve actually tested rather than something I read.
When the process becomes an agent
The boring layer used to be documents: where decisions live, what “ready” means, what a story has to contain. Increasingly it is agents and checks that hold those rules and apply them without being asked. A readiness check reads a story before anyone picks it up. A reviewer that did not write the code reads the change. A boundary check refuses the pull request that reaches across a module. On my own product that is how the whole delivery loop runs, and it is what I bring to a team: not the tools, but the rule that a process should be able to hold itself.
The effect is not mainly speed, though it is faster. Ambiguity surfaces before the work starts rather than after it. Drift is caught by a rule rather than by a tired reviewer at the end of the week. And people’s attention goes where a person is actually needed. Faster, yes. Mostly, more accurate about what is done, and more focused on what is not.
- Where a decision lives, and who may change it
- What “ready” means before a story is picked up
- The boundaries of the architecture
- Review by something that did not write the code
- Drift between what the docs say and what the code does
- What to build, and what to refuse
- Which shortcut will still be fine at fifty times the volume
- Feedback early enough to be useful
- What someone is ready for, slightly before they think so
- Saying no
The part that doesn’t automate
Growing engineers. Deciding what someone is ready for slightly before they think they are, and then making sure the work is genuinely theirs. Giving feedback early enough to be useful rather than late enough to be safe. That has not gotten easier as the tooling improved, and I don’t expect it to.
If anything, as more of the mechanical work gets cheap, judgment becomes the scarce thing — and judgment is grown deliberately or not at all. That’s the open question I’m sitting with: how you build that in people when the tasks that used to build it are the ones being automated away.
Where this shows up
- Forty-eight hours, nine prototypes — conditions for people who do not report to you, made legitimate and then left alone.
- Seventeen checks — every guardrail a record of a surprise, and never a reminder where a rule will do.
- The spec is the interface — the decision written down before anyone, or anything, starts building.