9 posts tagged #leadership.
A small team is fast because the whole problem lives in two or three heads. That's also why it's fragile...when one of those people leaves, a big chunk of how things work leaves with them. Here's what actually walks out the door, and how to manage it before it happens.
The case for moving fast usually comes with a number, and the case for slowing down usually comes with a story. Here's how to turn your experience into a number the business can actually weigh...and how to tell when the numbers say you should move faster after all.
When review depth follows risk, the high risk work falls on the same two or three seniors every week. Here are three ways to spread that load without lowering the bar.
A one-line warning in my deploy log took my site down for thirty minutes. It didn't stop anything, the command exited zero, and it looked like every other line scrolling past. Software risk stays invisible until traffic hits it, and that invisibility is why the work that prevents incidents is the first thing a deadline cuts.
Nothing logs a 1:1. No ticket closes when it's over, and its best outcome is a prevented problem, which no system can count. Here's the 30 minutes a week I protect for each person, the short document that runs it, and what protecting it actually costs me.
Tech debt you can see, point at, and put on a ticket. Culture debt gives you none of that...it compounds quietly in the norms and the trust until it shows up in the product. Here's how one small team went into it, why the reward quietly beat the values everyone said they held, and why the trust took over a year to rebuild.
The risky PR is rarely the big one...it's the one carrying money code, a migration, or a red build, regardless of size. Here's what I look for when one lands, and the product I'm building so senior attention goes where the risk actually is.
Most merge standards are wiki decoration. What makes a team actually follow them isn't the list...it's enforcement, consistency, and the why.
The three targets I set for my engineering team — PR size, open-to-merge time, and change failure rate — and why these are the three that matter.