Keeping senior engineers interested

There’s the old joke: “wanted, junior developer, 10 years experience with a framework that only has existed for 2 years”. That’s usually a sign of a company that has their job ads written by recruiters who aren’t familiar with the technologies they’re hiring for, but it’s also a sign of companies wanting to pay experienced developers junior salaries. In my book though, 10 years experience is definitely a senior.

Different companies have different names for what they call seniors, and often with different levels. Staff, Architect, Principle. All names for what amounts to “a developer with a lot of experience and technical knowledge”. Titles tend to make people feel good that their work is respected and their career is progressing.

Not everything that motivates these experienced developers is the same. Some are in love with the product they’re delivering and feel very passionately about it. Others might enjoy architecting large projects, sticking mostly to managing people-problems rather than direct user-facing code. Some might feel happy creating things that they directly see users use, others might be happy figuring out some complicated algorithms.

So what can a company do to ensure that they keep their seniors?

Respect goes a long way: if someone has spent a good portion of their life building up experience and knowledge, it’s rewarding whenever that’s acknowledged. That doesn’t mean that you have to clap for them every Monday in your standup, but make sure their work is celebrated and valued. It’s particularly tricky when senior engineers are working on non-user facing code — there is rarely a party in a non-tech company when someone refactors a large codebase or shards some databases. But these things are important, so encourage your developers to talk about them in a team-wide setting and explain why these things are valuable. Enable your developers to share their knowledge through talks, pair programming, or meetings. The whole team will benefit from it, and your seniors will feel useful.

Allow them time to explore unfamiliar technology. Developers can get burnt out if they feel like they’re not learning anything, and may switch jobs so that they can be in an environment where they don’t know everything inside out. There’s a couple of good sayings: “if you’re the smartest person in the room, you’re in the wrong room” along with “vote with your feet”. Combine them together and you get that developers should use their feet to move to a room where they’re not the smartest person. Some people enjoy being smartest, which is okay too! But once you feel you’ve learnt all there is to learn, it’s easy to become bored.

Offer appropriate salaries. It should go without saying, but if you’re not paying your developers well compared to the market, they’ll go find a job that does pay well. It sucks to see less experienced developers being paid more than you, and one of the quickest ways to get a salary increase is actually to just switch jobs. But that comes at a big cost to a company: every experienced developer you lose is another step to losing vital context in your product and stack, not to mention all the time spent hiring new people. Just pay your developers more and you won’t lose as many.

Give them roles that allow them to grow. Maybe your developers are ready to take more responsibility, or to take ownership of some part of your product. Encourage it and back them up, provide a structure where they can have opinions - and share those opinions.

Treat them as humans. Very few people want to be stuck in the same role doing the same thing every day. Talk to them, see where they want to go and what interests them, and do your best to support them in getting there.