leadership
I believe most engineering leadership is the work of compounding small, boring things. Clear writing. Honest estimates. A hiring bar you actually hold. None of it is dramatic, and all of it pays out for years. The dramatic stuff, the heroic weekend, the last-minute save, is usually evidence that the boring stuff got skipped earlier.
I also believe a team is a system, and like any system it has a throughput, a failure mode, and a set of incentives you are either shaping on purpose or shaping by accident. My job is to shape it on purpose: to make the default path the good one, so that doing the right thing does not require heroics or permission.
How I operate
I tell people why the work matters and what good looks like, then trust them to choose the how.
If a decision is not written, it did not happen; documents outlast the meeting and the memory of it.
I default to the smallest change that teaches us something, because cheap mistakes are how teams learn fast.
I want the argument before the decision and the alignment after it, not the other way around.
I treat uninterrupted hours as the scarce resource they are, and I spend my own time defending them.
I would rather stay short-staffed than lower the bar to fill a seat; one wrong hire costs the team more than the empty chair did.
Metrics I care about
Lead time, idea to production
How long it takes for a decision to become something users can touch. It is the cleanest single signal of whether the system around the team is helping them or fighting them. When it creeps up, the cause is almost never the engineers.
Example: A team I led cut lead time from three weeks to four days by deleting a staging approval step that no one could explain the origin of.
Change failure rate
What fraction of changes cause a user-visible problem. I care about it because it keeps the lead-time number honest: shipping fast is meaningless if half of it has to be shipped again. Together the two describe a team's real speed.
Example: When change failure rate spiked one quarter, the fix was not more review; it was better test data, which had quietly gone stale.
Time to a confident no
How quickly the team can look at a request and decline it well, with a reason. A team that can only say yes is not prioritizing, it is just queuing. Fast, well-reasoned nos are a sign the team understands its own strategy.
Example: We started writing a one-paragraph rationale for every roadmap no. Within a quarter, fewer of them came back.
Voluntary attrition, and who
Not just how many people leave, but which people. Losing someone who was coasting is not the same event as losing someone the team relied on. The headline number matters less than the pattern behind it.
Example: Two strong engineers leaving the same team in a quarter is not a problem you solve one exit interview at a time; it is a signal about the team itself.