Hiring and Keeping Senior Staff
There is a continual challenge employers face in finding experienced, senior staff. Part of the problem is they’re doing basically everything wrong.
A couple of times a week I get a random phone call or message offering me an “exciting opportunity”. I often wish my OK Cupid profile was as active and attractive as my LinkedIn, but perhaps they’re mutually exclusive. Anyway, the majority of the offers, along with conversations I’ve had with HR, recruiters, and managers make it very clear that businesses often have little or no idea how to attract senior developers.
Seniors often represent a high outlay, but in theory are a lower risk. The return on investment should be high and rapid. Aside from whatever weird stuff and specific setup detail your company has, they should be able to hit the ground running. Relatively speaking, of course.
What constitutes a “senior” is necessarily vague, but it connects with experience, and therefore age. The pool of senior developers is crazily small. A third of developers have been in the industry under five years. More than 80% have ten years or less. People with more than 20 years of experience account for just over 6% of available talent. And “available” is the wrong word. Essentially all of this top tier of developers is gainfully employed compared to lower employment rates for more junior developers. This makes for a vanishingly small hiring pool.
Many business don’t seem to realise that finding skilled and experienced developers is no longer about finding someone that meets the employer’s high standards. In fact, more often than not it’s about you meeting theirs.
Ultimately you need to figure out what you have to offer. I’ll start with the least obvious, and move though to the most obvious solution, which I’ll spoiler right now: pay more money.
Have a valid hiring process
Companies routinely have hiring processes that are time-wasting or abusive nonsense. Making us code a bullshit question on a whiteboard is only valuable if you’re looking for a Senior Whiteboard Bullshit Engineer. By all means test and examine, make us prove our worth, but do it in a way that tests the skills you actually want and doesn’t waste everyone’s time. Making us spend three days on a nonsense project, or 10 hours in interviews is a waste of time. You need to find a balance of a significant enough test to get worthwhile results, with not making the process too onerous.
Be located somewhere reasonable
Senior developers have choices of places to work. Emphasis on places. Some things can’t be helped. I’ve taken contracts simply because the role was close to my house and I could walk there. But I’ve passed on many more because they were in suburbs or areas that I knew were a nightmare to get to. If you’re in the CBD or a major tech centre you’re fine, but if you decide to locate your office in a industrial estate two hours west of any major city for the cheaper rent I can guarantee you it will cost you quality developers. (Especially if you live on the west coast of something.)
It’s not just about distance, either. What’s around you? Where can I go for lunch? Is it close to public transport? Can I do some shopping after work? Is there parking? Is the area super shady, run down or crime-ridden? Is it an active volcano? Think these things through.
Do something cool
This is a short one. You can get away with a certain amount just by being in a fun industry. Videogames, music, or travel, for example. It won’t matter to everyone, but will certainly be a help in making you stand out from the pack. Not everything will appeal to the same people, but certain market segments just have a bit of fun to them. We’ll typically take a six figure job in the travel industry over the same rate in a light industrial startup or personal finance.
Use the best technologies
This might seem connected to the “Do Something Cool” stated above, but it’s not at all. I’d rather build Elixir and NoSQL micro-service based Angular 5 single page apps on AWS for a funeral home than Wordpress sites at a top-end videogames company.
Developers have to learn at a furious pace. Our industry is moving so quickly that if we try to stay still we go backwards. Keeping up with that requires constant exposure to new technologies and approaches. If we don’t get that at work we have to do it at home and for many of us our time at home is limited.
You might think that your trusty old early 2000s shopping cart is “good enough” but if you can’t hire or keep key staff then maybe an upgrade is actually a positive strategy even from a purely business point of view.
Use best practices
There are a lot of practices that senior developers like. Agile methodologies, Test Driven Development, continuous deployment, online issue tracking, continuous integration, test coverage, code review, version control, and the like. Many of these sound like academic considerations — like lofty goals that aren’t really achievable in the real world, but that we can maybe aspire to.
Experienced developers know this isn’t the case. These are practical and necessary approaches to software development that have genuine impact on reliability and profitability. They manage risks, remove uncertainties, and reduce turnaround on new features.
There’s something called the Joel Test that many developers will be assessing you on, potentially without even being aware of it themselves. If you have a low score on this test you’re a bad company to work for and the work will be unpleasant.
To anyone saying “Well, yes, but we…” Sorry. You don’t get a vote. This isn’t about how you feel about yourselves, but how you’re seen from the outside.
There is an important exception to this. If you’re hiring a senior developer to improve or implement the above practices then that is absolutely fine. As long as your intention is sincere and not an evasion, and you’re prepared for the change and disruption.
While on the topic of these tools and processes, it’s not specifically related to hiring but definitely retention. Do not under any circumstances skimp on these tools. Developer time is an incredibly expensive resource, and any money “saved” by not providing your devs the tools to be efficient and productive is the falsest possible economy. This includes expecting devs to use free or cheap inferior solutions. A few hours of trying to find documentation or retrain will undoubtedly kill any savings you might make.
Also note that this feeds more into staff morale than almost anything else. Experienced developers don’t typically bitch to each other about companies not having enough bicycle parking. They complain about not being given the tools to do their jobs.
Stop offering us dumb things
Seriously. Most senior developers are in our 30s and 40s. We have families, wives, lives, hobbies. We don’t care that you do Friday beers or casual dress. We don’t care that you have a foosball table. Team building exercises will make us roll our eyes. Forced dress-ups just make us annoyed. Our “culture” is one of excellence in coding and software delivery, not cheesy gimmicks. We don’t care that you have a barista on staff, we think that’s a waste of money.
We care about benefits that affect our bottom line, or our time. We’re far more likely to see the appeal of the company covering our phone and internet, or paying for regular lunches than a monthly paintball tournament.
I’m not actually going into detail on “benefits” here, like a 401k or health insurance. I’m from Australia where health care is not tied to employment and retirement contributions are mandated by government. You should know what the local expectations are, and that’s not what I’m talking about.
One of the best places I ever worked had an on-staff chef. Excellent food was provided every day. Not only was this a significant cost saving for all staff, but it provided a social hub that was highly communal. It organically meant people from random teams would sit together and chat, making the organisation more cohesive and effective. This is how you create a culture - not office beanbags. I have no doubt it was largely responsible for reducing turnover of key staff, and actually made itself a solid business case.
To an unavoidable degree these things are subjective. For example, to some people frequent international travel is a burden, while to others it would be a huge appeal.
Consider something other than a 9–5 full time in-house role
It’s constantly surprising to me that so many businesses insist on a strict 9 to 5 job, working five days a week in the office. Flexibility in any (or all) of these things is of enormous benefit. Remote hires drastically increase the pool of developers whether it’s full-time remote or working from home a few days a week. Working from home is a drastic improvement in lifestyle, and carries significant savings financially as well as in time.
There are a lot of experienced developers out there who value their time a lot more than a straight salary. It may well be that you get more interest from developers if you don’t get someone full time. A lot of us would enthusiastically take a 20% pay cut to work four days a week. Or a 10% cut on a nine day fortnight. You may well find that a senior developer who doesn’t work on Wednesdays costs about the same as a less experienced dev, and still gets more done.
Similarly, any movement you can put in around start and end times is a good thing. Leaving 20 minutes earlier or later can easily halve a commute, or make it possible to take the kids to school, or (let’s be honest) sleep in a bit. Starting half an hour later in the morning and leaving half an hour later could save us two hours or more a day. The math on that is painfully obvious. As long as there are known times that everyone is in the office — 10 to 3 is a common example — meetings and other collaborations can easily be worked around this flexibility.
I can see management people twitching now, about the loss of productivity. But I don’t see that necessarily as a given. I’m not convinced that man-hours at a desk directly equates to quality output. Your sprint velocity is whatever it is regardless of the specific details of people’s work. If you do 68 points a sprint, maybe you’ll end up with 64 instead. Sure, if there’s a lot of work to be done, maybe you do genuinely need all hands on the deck. But maybe that just means you need more hands. If you want Is there any real difference between having four developers who work five days a week and having five developers who work four days a week?
It’s hard to clarify the point I’m trying to make, but to make it crystal clear, try and make the case for developers to be working 6 days a week or 11 a fortnight and see if it’s compelling. Because it’s literally the same argument.
Last but not least — Pay good money
Management types get very fixated on minimising salaries, and with good reason. Salary creeps can have a nasty effect on the bottom line, and at senior developer rates a few percent matters. But ultimately developers want to get paid, and paid well. Supply and demand is brutal here. Not only are there relatively few senior developers, but almost all are gainfully employed. If you want to attract a reasonable selection of actual talent you may need to offer more than what you consider the market rate just to generate some movement.
It’s critical to stress that this isn’t about paying the rate someone would need to work for you. It’s about paying someone enough to leave where they’re working now in order to do so. That might need to be 10–20% above the standard market rate.
For what it’s worth, I get offers of work regularly from recruiters. Typically a few a week. But many of them are for rates as low as half my current salary. Needless to say, they’re not exactly appealing.
There are things you can do to keep the salary down. Any of the above listed advantages will help get our attention, and may help us choose between two roughly equivalent offers. But in the end there’s a good chance that any decision we make will come down to how we’re paid.
If you’re looking for a skilled dev with cutting edge technologies in a cool industry with great practices and flexible working conditions, then maybe you can lowball a little bit and still have plenty of interest.
But if you’re looking for someone to maintain a 12 year old ColdFusion application for a government client 9–5:30 and 5 days a week in an industrial estate near a tannery an hour out of the city… for the love of God, you are going to have to pay up.
Retention vs New Hires
Everything I’ve written above has been on hiring new developers, rather than retention. Except it’s not. The same pressures apply to your current staff. There’s someone on LinkedIn right now sending your best developer an offer 15% above what they’re currently on. Will they take it? If not, what’s stopping them?
If your answer is “loyalty” then you’re woefully naive. Your company is just a job, not an organised crime family. Unless you are in fact an organised crime family in which case… as you were, no offence intended and sorry I mentioned it.
No, it will be the things above that keep them with you, or the things above that prompt them to go somewhere else.