Worthy of note: This piece isn’t about my current employer, who manage to be remarkably good at this stuff, it’s about my experiences in software in general.
There is a problem with IT recruitment. Companies that need good staff have to consider a million different factors, from location to person specifications, considering remote offices to remuneration packages — all to ensure they get better than average standard of staff. If you have a challenging problem to solve, and need good staff to do it, you need to attract and retain those staff, and that’s harder than it can seem.
In the spirit of oversimplification, and itemised list format articles, here’s my guide to attracting and retaining the best possible staff.
Forget the bullshit
So what I mean by this, is that either don’t do, or don’t make a primary focus of the little things that everyone seems to try. Sure, your staff will not complain if you have a well stocked kitchen, good coffee, some social stuff going on, and a table tennis, but they also won’t complain if you have an otherwise good place to work, at which (like anywhere else) they have to supply some stuff off their own backs. If you pack the kitchen, and hold table tennis tournaments, word will get around, but this will be far from the priority for devs. If it’s completely unrelated to the work, maybe don’t worry too much.
The exception to this, is a breakout area — you essentially have one, or your devs have nowhere to wander to whilst they consider problems, mull things over — even if the devs are buying their own food and drink (how unreasonable) give them somewhere comfortable to do it.
Trust your staff
Abandon all practices that don’t express trust in your staff. Don’t monitor time attended or work done, unless given really strong reasons to. Timesheets, inflexible hours, and close monitoring of any kind, are downsides that you don’t need. Get staff you don’t need to patronise, rather than patronise them.
Ideally, don’t even set hours, or set a core of a low hours, with opportunities to work up to larger amounts. Did you know that increasingly, evidence points to an “hours ceiling” after which productivity doesn’t increase at all? Varying studies have made varying conclusions, but it’s seeming like around 28 hours a week is comparable to 37.5, so why not set your hours at 28, and see if your staff are interested enough to do more?
This is difficult, because sometimes, strategic management necessitates things like knowledge on a need-to-know basis, or otherwise limited information sharing, however, wherever you possibly can, share info, and get feedback on it, as informally as possible. Put people on a level with yourself, and talk through the possibilities. If you have something huge that actually prevents you talking, like an IPO upcoming, then tell staff as much as you can — even if that’s only that there is something going on that you can’t disclose yet. Your staff will be happier, and will stay, if they both know what’s going on, and have input into it.
Deal with the basics well
Pay your staff, pay them enough that it’s not an issue. Look at it this way: If you want average staff, pay average wages. If you want (or rather, recruit) above average staff, pay above average. You don’t have to pay hugely over the odds to be noticed as a well paying employer. 5–10% over the average will leave most devs happy with their wage. The key isn’t to pay a fortune, or to make your devs rich, but to take pay out of the picture — make it so devs don’t have to worry about it. Couple this with a yearly increase in line with the cost of living increase — most countries will have some form of metric freely available to make it clear what this is — and offer a small increment on top of this basic increase in recognition of those who have made leaps in how you do stuff.
No one will care that others get paid different amounts, they will care if they, or their colleagues, go unrecognised, so go to some lengths to work out your increments — your retention rate will thank you. Offer staff an opportunity to put forward their own thoughts in advance of increment season, and seriously consider all of the points raised — it’s hard work, but the alternative is to generate some animosity, which is a mortal enemy when maintaining staff, especially skilled staff who can easily go elsewhere.
If you have an unskilled staff who can’t easily leave, that doesn’t mean you shouldn’t offer cost of living increases and incentives. That’s just immoral. Real wages have been dropping, and paying what you can get away with is part of the issue.
Remuneration includes other things too, especially in countries like the UK, where some stuff is actually legally required. Provide a decent, matched pension contribution. Like with pay, excel over the average by a reasonable amount. For example, the UK average contribution seems to be 3% matched. Mine is 5%. That’s a modest improvement on what I could get anywhere.
More to the point, realise what the pension is for. Your pension provider will offer forecasts of the total amounts that it will likely yield. You should consider these in setting up your funds. A good pension at retirement pays 50% of the final salary. That’s genuinely difficult to achieve at retirement, but it’s a good direction to aim in, even if you acknowledge that, at the moment, the market may well be against you. Pensions provide for your staff after they leave, and for those that realise, they are a factor in whether they stay with you in job they like, or endure a better paying job they dislike.
Remember that in most countries, going freelance can more than triple a person’s wage. I can leave my current role, and earn 4–6 times as much as I currently do gross. That means that even if I don’t use any tax reduction techniques, I can take home 3 times as much at least. My employer has that to contend with, and they do. You need to too.
Recognise the good stuff, and provide what you can
So, obviously you want to offer an attractive benefits package to your staff, but as we said already, you need to cut the bullshit. The benefits that attract you a hip group of twenty something grads who want to rewrite everything in Go or Kotlin aren’t the same that attract the reliable old hands that you also need. The Club 18–30 style getaway that you had planned isn’t going to go down well with the 35 year olds in general, especially when they can’t take their kids.
Some things are pretty much a given. You should have good hot drinks, and keep them available. Snacks don’t go amiss, and if you want to, you can branch out into free meals — no one dislikes any of these things, although don’t take offence at anyone who doesn’t want them, either.
Look at the nice touches: generally small investments that go down well with staff, like an Easter Egg at Easter, advent calendar at Christmas (Substitute for more appropriate things if these festivals aren’t celebrated in your area, obviously). It costs relatively little to give employees a voucher for their birthday, flowers if they are long term ill, that kind of thing, and it maintains a good relationship without costing the earth.
After you’ve decided how far to go with the above, look at the practical needs, and look at this bit most seriously, because it’s the stuff that actually add value to the remuneration package. Health insurance is a given in many places, but for those in which it’s not, consider it anyway. Dental and optical cover are great additions that get missed; employee discount schemes are all over the place, and never hurt; assistance with childcare, whether it be a creche at a larger organisation, or a contribution to the costs, or partnership with a local provider to get a favourable rate, is always popular.
Most of all, regarding benefits, take suggestions. It encourages openness, and it allows you to get the ideas from the people who benefit from them — meaning the investment you make will likely be best.
Maintain the challenge
Without doubt the most important point, maintain the challenges that you employees join up for. I’ve left a fair few jobs in Software Development over the past 15 years, and whilst I’ve had my share of employers have business difficulties, employers just be crazy, and the like, I’ve left more than not because they got really boring.
Every dev in the world would do something new every day if they could — so it’s part of your role to keep the work interesting, even when it’s settled to Business As Usual. You can do this by letting staff pursue their own projects, allowing people to take initiatives of their own with the products, see what works, and by rotating which teams end up with the BAU work. An unstimulated dev gets bored, and then they are really only a call from a recruiter with the right job away from leaving. Don’t lose valuable product and domain knowledge and have to start afresh for the want of letting someone try a new idea. Obviously, you have to be careful what ends up being done, and how outlandish an idea is, but my advice is simply to indulge dev interest as much as business requirements allow — you’ll get a lot of side work fizzle out, but the bits that don’t will often be the best improvements to your product that you’ve seen, and even those that aren’t will keep the devs minds in the game.
Recognise that people will go
Devs will leave, your workforce will rotate. That’s a reality that you have to face up to, and your task isn’t to stop it happening, it’s to make employee turnover gradual and manageable, and about maintaining the core hive mind that knows what’s going on. Your benefits package and culture are what keep devs with you, but some will leave. Don’t take it personally.
Firstly, devs leaving is sometimes in both your best interests — people leave because they actually aren’t yet ready for the challenge of your workplace — that’s the best outcome in the circumstances, and although you need to recruit and onboard a new dev, you aren’t flogging a dead horse.
Secondly, someone, somewhere, is always a better prospect. For every dev you have, there is an employer out there better than you, and some will find it, or leave looking for it.
Thirdly, just generally get over yourself. People don’t want to work in the same place forever, and you can be the best employer a dev has ever had, but eventually, some will be out of passion for your product. Let it go.
When devs leave, ask them why — and ask them before their last week — so that you can find out if they are leaving for something you could actually easily provide. The worst case scenario is that you find out something you could change, and would change, but the dev leaves anyway, and all you have is useful feedback.
It’s incredibly difficult to be an IT employer, and it’s a massive challenge to keep staff when you are fighting everyone else for a small pool of the actually good staff.
You can’t do anything better than treat your staff well, as equals, and enable them to make suggestions freely. Good luck.