I’ve been leading engineering teams for over eleven years. In that time, I’ve never lost an engineer I didn’t want to lose.
I’m not saying that to brag. I’m saying it because it surprises people, and when they ask how, I never have a satisfying answer. There’s no framework. There’s no retention programme. There’s no career ladder with carefully defined levels and competency matrices. There’s just a way of working that, apparently, makes people want to stick around.
I’ve been trying to figure out what that actually is, and the best I can come up with is this: respect the people, make the work interesting, and don’t be a nightmare to work for. That’s it. That’s the retention strategy.
Career ladders tell people where they could go. Respect and interesting work tell them why they’d want to stay where they are.
The career ladder problem
I’m not against career ladders in principle. In large organisations, they serve a purpose. They give HR something to hang compensation reviews on. They give managers a framework for promotion conversations. They give engineers a sense of progression that’s visible and measurable.
But in a startup, in a small remote team, they’re mostly theatre.
When you’ve got a team of five or eight engineers, “Senior Engineer II” doesn’t mean anything. Everyone can see what everyone else is doing. The work speaks for itself. The person who’s great at architecture is obviously great at architecture, they don’t need a title to prove it. The person who mentors the juniors is obviously the person who mentors the juniors, they don’t need it in a competency matrix.
What career ladders do in small teams is create artificial distinctions between people who are, in practice, peers. And worse, they create the expectation that progression means climbing, which in a startup often means climbing into management, which means losing your best engineer so they can become a mediocre manager. Nobody wins.
What actually keeps people
I’ve thought about this a lot, and I keep coming back to the same handful of things. None of them are complicated. All of them require consistent effort.
Respect their opinions. Not “listen politely and then do what you were going to do anyway.” Actually let their technical judgement carry weight in decisions. If your senior engineer says the architecture should go a certain way and you override them without a good reason, you’ve told them their expertise doesn’t matter. Do that twice and they’ll start looking.
Trust them to manage themselves. Senior engineers don’t need to be told how to do their work. They need to know WHAT needs doing and WHY it matters, and then they need to be left alone to figure out the how. If you’re micromanaging a senior engineer, you’ve either hired the wrong person or you’re the wrong manager. Probably the second one.
Don’t second-guess their work. This is related but distinct. Trusting someone to manage themselves is about process. Not second-guessing is about respect. When a senior engineer makes a technical decision, your default should be to back it unless you have a specific, articulable reason not to. “I would have done it differently” is not a reason. “This will cause a production outage” is a reason.
Give them credit. When the system works, name the person who built it. In the board meeting, in the all-hands, in the Slack channel. Engineers notice when their work gets absorbed into “the team delivered” without any individual recognition. They also notice when you take credit for their ideas. Don’t do that.
Make the work worth doing
This is the one that I think matters more than anything else, and it’s the one that no retention framework can manufacture.
Senior engineers stay when the problems are interesting. Not “interesting” in the abstract, motivational-poster sense. Interesting as in genuinely hard, genuinely novel, genuinely worth their time. The kind of problem where they go for a walk and find themselves still thinking about it an hour later. The kind where they text a friend who’s also an engineer and say “you won’t believe what I’m working on.”
At SafeNav, we’re building autonomous systems for maritime environments. The software runs on ships for twenty years. The problems are real, they’re hard, and they matter. When I’m hiring, that’s the pitch. Not “we have a competitive salary and a career ladder.” It’s “we’re building something that goes on actual ships and has to work in the actual ocean, and the problems are fascinating.”
Not every company has that luxury. If you’re building a CRUD app, it’s harder to make the work feel meaningful. But even then, there are choices you can make. Let senior engineers own entire subsystems rather than churning through tickets. Give them architectural decisions. Let them choose their tools. The more autonomy they have over HOW the work gets done, the more invested they are in the outcome.
Be a good place to work
This sounds obvious, but the number of companies that get it wrong is staggering.
Reasonable hours. Startup culture glorifies the grind, and there are genuinely intense periods where everyone needs to push hard. But if every week is a crunch week, your senior engineers will leave. They’ve been around long enough to know that permanent crunch is a management failure, not a badge of honour.
Flexibility around life. I’m a single mum with shared custody. My day includes school runs, dog walks, laundry, and all the domestic infrastructure that keeps a household running. I build my work around my life, and I extend the same flexibility to my team. If someone needs to do the school pickup at 3pm, they do the school pickup at 3pm. The work gets done. It always gets done. Trusting adults to manage their own time is not a radical idea, but apparently it still needs saying.
A team that’s fun and smart. People stay for people. If the team is full of kind, clever, slightly geeky humans who genuinely enjoy working together, that’s worth more than a 10% pay rise at a company where the culture is toxic. I hire for this deliberately, and I let my team own the culture-fit assessment because they know better than I do whether someone will make the daily work better.
The pay conversation
I should address compensation directly because it’s the elephant in the room.
I’m in the EU. The career ladder title system that dominates American tech companies doesn’t translate well here. I don’t have “Staff Engineer” and “Principal Engineer” levels with specific salary bands. What I do is straightforward: once a year, I go to the board and argue for a pay rise, and then I distribute it across the team.
Is this sophisticated? No. Does it work? Yes, because the conversation isn’t about levels and titles, it’s about “are these people fairly compensated for the work they’re doing?” And if the answer is yes, the compensation conversation takes five minutes and everyone moves on to the actual work.
Senior engineers don’t leave over money unless you’re paying them insultingly below market. They leave because the work is boring, the culture is bad, or they don’t feel respected. Fix those three things and you’ll be surprised how rarely compensation comes up.
The quiet confidence of staying
There’s something that happens when a team stays together for a long time. They develop a shared language, a shared understanding of the codebase, a shared instinct for what matters and what doesn’t. New features get built faster because nobody needs to explain the context. Bugs get fixed faster because someone remembers writing the module three years ago. Architecture decisions get better because the team has collectively lived through the consequences of the last five decisions.
You can’t buy that with a career ladder. You can only earn it by creating an environment where people don’t want to leave.
I don’t have a retention programme. I have a team of people who are respected, who work on interesting problems, who have flexibility in how they structure their days, and who genuinely like working together. Eleven years, and the only people who’ve left are the ones where it was the right time for both of us.
I don’t think that’s luck. I think it’s just paying attention to what actually matters, which is simpler than the HR industry would have you believe.