Working with me
A short guide for anyone joining my team or hiring me to lead one: how I work and what you can expect from me.
Code reviews are for teaching
I run structured code reviews, and I treat them as the main way a team learns. I explain the why behind a change request, not only the what. The goal is a team that needs me less: since we started, escalations to senior engineers have dropped by 30%.
When something breaks
I fix the problem first and keep everyone informed while I do it. Clients and stakeholders hear from me early and often, even when the update is "still working on it." Once things are stable, the fix gets written down so the next person doesn't start from zero.
A spec before code
Requests often arrive as goals, not requirements. Before anyone writes code, I sit with the people asking and turn the goal into a written spec we all agree on. It's slower for a day and much faster for the rest of the project.
Releases should be boring
If shipping is stressful, the process is wrong. I automate the path to production so a release is routine, and I'd rather ship small changes often than big ones rarely.
What you can expect from me
- A reply within a day, and a clear written update when something changes.
- Honest feedback, given privately and with a reason.
- Credit to the person who did the work.