How I Lead

I give the team concrete goals, good docs, and well-formed tickets. Then the work is theirs. I order the sprint and name what slips before we start, so slippage is a plan and not a surprise.

When a launch is ready, the engineer who built it runs it, not me. My job is to make the path clear. Their job is to walk it.

I'm a player-coach, and I take that literally. I carry my own small fixes across the stack, write them up the same way every time, and when something breaks in production I jump in: small, surgical, fast. Then I hand close-out back to the team.

Staying in the code keeps my reviews honest and my estimates real.

Feedback arrives within days, grounded in the actual behavior and the actual file, logged as it happens so nothing depends on my memory at review time. Praise travels. Critique gets no audience.

If I have to leave the same comment twice, the third time is a direct conversation, not another comment.

Good work nobody saw might as well not have happened when ratings are decided. So I put my reports on stage: they demo their own ships, they get named on launches, and I teach them what counts toward the next level.

If I don't know it happened, I can't advocate for it.

A short daily checkpoint inside an already-started day. Async Friday. Blockers raised the moment they hit, not saved for standup.

When an epic sprawls, I cut scope to protect one finish line instead of tracking everything late.

The lever for growth is a stretch assignment with a clear definition of done: a cross-stack epic for someone proving broader ownership, end-to-end launch responsibility for someone ready to exceed, a solo domain slice for someone new who needs to prove the level.

I frame the floor. They estimate it and run it.