Four principles guide how I lead engineering teams. Each comes with a practice I actually keep, because a principle nobody can see in the work is only a slogan.
Stay close to the code
Leaders who drift from the work lose the judgment to coach the people doing it. I build with the same agentic coding tools I ask my teams to use, so what I expect of those tools comes from using them.
Own the outcome
A decision with no owner becomes nobody’s problem when it ages badly. We record architecture decisions as ADRs, each with a named owner, so the reasoning outlives the meeting and someone answers for it.
Remove friction
Before asking anyone for more effort, find what is in their way. I survey engineers about what slows them down and act on the top themes, because the people doing the work see the waste first. Overload works the same way: a team buried in work in progress and interruptions is rarely short on effort. It is short on room to think.
Share what works
A lesson that stays with one person or one team gets paid for again by everyone else. We hold engineering all-hands with demos and start, stop, continue feedback, so what one team learns can travel to the rest.
For the practice behind the second principle, see Architecture decisions: preserve the why.
Monday Momentum
Several of these ideas started as Monday Momentum, my weekly note to my engineering team: one idea, where it comes from, and one thing to try. Three are adapted here:
- Strong views, loose grip: hold a position firmly enough to act and loosely enough to change it.
- Empathetic testing: a passing test can still fail a person.
- First-principles thinking: ask whether a constraint is real or just convention.