Why My Engineers Stayed While Everyone Else Was Job-Hopping
26 hires. 9 fires. Zero regrets. Respect, Autonomy, Radical Candor.
Most engineering teams turn over every two years. That’s the industry baseline.
Mine didn’t.
At the company where I last led engineering, I made 15 hires over four years. 11 are still on that team. They’ve been there 1.5 to 4 years.
Across my whole career I’ve made 26 hires. The ones I’m still in touch with are all still at the same companies. Some 5, 6, 7 years in. The longest one works for a d-e-c-a-d-e, still going, long after I left.
Out of 9 people I ever fired, 5 I hired myself. Usually parted ways during probation period, up to one year max.
3 left. One relocated to Berlin and needed local employment there, happens to be one of my best friends. One got an offer we couldn’t match. Before he left, he found and onboarded his own replacement, for free. The third just wanted on-site job after war-forced relocation 6 months in.
That’s it. Zero regrettable attrition.
Nobody I would’ve fought harder to keep. That’s the part I’m proud of. Not the hires. The retention.
This post is for founders and CEOs who don’t run engineering directly but live with the consequences of how it’s run. Hiring well is hard. But hiring is only the first 10% of the problem. The other 90% is whether those people stay long enough to compound.
Hiring is guessing. Firing is knowing.
There’s an old line in tech and I can tell you, after a few hundred interviews, it’s exactly right.
No matter how good your process is, you’re making a probabilistic bet on every single hire. You have an hour and half with a stranger. They’re presenting their best self. You’re presenting your best company. Both sides are guessing.
Firing is different. By the time you’re firing someone, you have months of evidence. You know exactly who they are and how they work. That clarity is what makes the decision feel obvious in retrospect, even when it was painful to act on.
Why does this matter for a CEO? Because the cost asymmetry is brutal. A bad hire costs are roughly estimated at 30% of first-year earnings. For management-level misses it climbs to 50%. So on a senior remote engineer at $75K in Eastern Europe, you’re looking at $20K to $40K of damage from one bad call. And that’s before counting the team morale tax, the missed roadmap, and the cleanup work after they leave.
So if hiring is guessing, the goal isn’t to guess perfectly. It’s to:
Tilt the odds in favor of success at the interview stage (win-win)
Cut your losses fast when you guessed wrong!
Make the people who stick around want to stay & do their best work
What I actually look for in interviews
For senior engineers, hard skills barely differentiate anymore. Everyone has them. The candidates I see can all code. They can all explain their last project. They can all answer system design questions reasonably well.
So I dig hard into two things.
Motivation. Why are you looking right now? Why did you leave your last role? Why this company specifically? In my eyes, these three questions tell me way more about whether someone will stay three years than any technical assessment ever will. People who can’t articulate their motivation tend to drift out within 6 months. People who are clear about what they want and why... they plant roots for years.
Speed of thinking, not speed of typing. I still run live coding sessions. But I’m not measuring whether they finish the problem. I’m measuring how they reason. The whole tech industry just caught up on this by the way. Candidates literally use AI all the time.
Writing code is no longer the bottleneck. Judgment about code & systems is.
The difference between a $75K engineer and one worth twice that isn’t the code they write. It’s the questions they ask before writing a single line (or prompt). How will this break under load? What happens when the data doubles? Who depends on this 12 months from now? The senior ones lead with those questions. The junior ones rush to typing. Btw, my fav is when people start diagramming without being asked to.
When you guess wrong, the PIP
Initially, I used to fire by gut. I’d see someone struggling, give feedback asap, hope it improved, and eventually have an awkward conversation.
The Performance Improvement Plan changed that for me.
A PIP is not a punishment. It’s a clean trajectory with two acceptable outcomes: the person recovers, or the person exits with their dignity intact and everyone saw it coming. Industry data shows about 40% of PIPs end with the employee keeping their job. That’s roughly a coin flip.
The most important rule: metrics got to fit the actual job, not the industry template. If someone’s role is deep research that closes one task every two weeks, then “10 tasks a week” is a theater. You’re setting them up to fail and signaling the firing was decided before the plan even started.
Here’s how I run one:
Sit down together and agree on 3-5 concrete measurables. They have to align with what the business needs AND the realistic shape of the role.
Examples: filling out the daily team async “standup”, pushing code changes at a steady cadence, turning around peer reviews within a day. Whatever genuinely reflects the work.
Track weekly. Review at the end of the month.
If they hit the bar, the PIP closes and we move on like nothing happened.
If they miss without a serious reason, they’re out the next day.
The hardest PIP I ran was on a senior engineer who’d been with us over a year. He wasn’t a bad person. He just couldn’t operate at the level the role required. Without the PIP framework, I would have dragged that decision out for another few months. With it, we had clarity within four weeks and everyone (him included) understood what happened.
The toxic high-performer
The most expensive hire I ever made wasn’t an underperformer.
He was the opposite. He outperformed every metric we tracked by more than 2x. Commits. Tickets closed. Hours logged. Pull requests merged. On paper, he was the best performing engineer on the team.
A project we’d scoped together for 1-2 months took him more than five. And it still wasn’t done when I let him go.
This is the trap of output over outcome. He produced enormous amounts of code (shortly before AI). He worked insane hours. He hit every short-term metric. But the actual business outcome (a working, shipped, maintained system) wasn’t getting closer. The codebase was getting more complex, harder to onboard people into, more dependent on him specifically. He was building a fortress of personal indispensability while the project drifted.
The lesson I took: measure outcomes, not output. A team that ships one feature that actually moves the business beats a team that ships ten features nobody uses. Track the things that matter at the level of customer impact and revenue, not at the level of activity.
If you’re a CEO and your engineering reports are full of “stories closed” and “velocity points”... you don’t yet know whether your team is winning.
Why people stay
I’ve thought about this a lot, because the retention numbers are the strangest part of my career. Most teams turn over every 2 years. Mine sat at 4 years! Gallup’s research consistently shows managers account for ~70% of the variance in team engagement. Not the company. Not the comp. The manager.
But what does that manager actually do? For me it comes down to three principles and one rule.
Respect.
Treat people as adults. They chose to be here. They have lives outside work. They have opinions worth hearing. They’re capable of making decisions without me in the room. Most managers default to control and earn trust slowly. The good ones default to trust and add control only where it’s needed.
Autonomy.
I went through several team structures over the years. The shift that actually worked wasn’t structural. It was the moment I stopped just naming people “team lead” and actually gave them power. Power to change their own processes. Power to make decisions without escalating to me. Power to say no to me. That’s when they became real team leads instead of nominal ones.
This goes back to a principle I keep coming back to: good process emerges from friction at the work, not from frameworks imposed from above. I wrote more on that in “Don’t Transform Your Team, Confront Reality”.
Building a proper layer of real team leads between me and the engineers was one of my biggest achievements. The whole org sped up. I could focus on systems, hiring, strategy, roadmap. They focused on the day-to-day. The engineers got faster feedback, faster decisions, and someone whose full job was their growth.
Worth saying: scaling a team isn’t an immediate multiplier. Tripling the headcount doesn’t triple the output. The coordination cost grows faster than the throughput, and the only way out is structure. I covered this trap in “Why Tripling Your Dev Team Won’t Triple Output”.
Radical Candor.
Kim Scott’s framework, and I’m a fan. The core idea: care personally AND challenge directly. Most managers do one or the other. They’re either nice and vague (Scott calls this “ruinous empathy”) or harsh and impersonal (”obnoxious aggression”). Radical Candor is both at once. You can fire someone without poisoning the relationship. You can give brutal feedback without making it personal. You can have a hard conversation with someone you genuinely care about, because they deserve to know.
The PIP framework I described earlier? That’s Radical Candor in process form. The toxic high-performer conversation? Radical Candor in action. The motivation questions I ask in interviews? Same. It’s not a tactic. It’s a way of operating.
And one rule: match the rare offer that actually matters. One senior engineer of mine got an outside offer that almost doubled his comp. We matched it. He was about to lead a new initiative that would have unraveled if he’d left. That was six years ago. He’s still there. Still leading. The lesson isn’t “always match offers.” It’s “know which 5% of your team you’d fight for, and act when the moment comes.”
The retention isn’t an accident. It’s a system. And underneath the system, it’s three principles: respect, autonomy, candor.
What I’d tell a founder hiring their first engineering manager
Three things.
First, the manager you hire will set the ceiling on retention for the next five years. If they’re bad, you’ll bleed talent no matter how good your product is or how generous your equity is. If they’re good, people will stay through ups and downs you wouldn’t believe. Remember the Gallup number: 70% of team engagement comes from the manager.
Second, build the firing muscle before you need it. The PIP is not optional. Without it, your first bad hire will linger for a year and poison the team. With it, you can correct in six weeks.
Third, optimize for outcome, not output. The high-output toxic engineer is a real archetype. He looks like your best performer right up until the moment you realize the company isn’t moving.
Hiring is guessing. You will get some wrong. The wins compound when the people you got right stay long enough to matter.
Looking back, the thing I’m proudest of isn’t who I hired. It’s who I never had to replace.