Category Archives: Recruitment

We’re a DevOps consultancy, and we’re hiring DevOps engineers. But the software industry has a crisis right now – and that crisis is all about the word ‘DevOps’ and what it really means. I’m starting to wonder whether putting ‘DevOps’ in our job ads might actually be counter-productive – and at YOW! this week, I finally understood why.

Elabor8 (where I work) had a booth at YOW!, and I gave a couple of lightning talks there. Probably the biggest crowd-pleaser was my talk on resiliency patterns in distributed systems. I covered some difficult topics like the importance of having idempotent rollback steps in compensating transactions and how lessons learned from the ship-building industry help us craft better distributed systems, all presented in 10 minutes in a crowded event space.

Hang on, you may well ask. If I’m a DevOps consultant, why am I talking about atomicity and consistency in distributed systems? Shouldn’t I be talking about cool PowerShell tips and how to set up Jenkins?

As is so common with rhetorical questions, the answer is a resolute ‘No’.

When I talk about DevOps, I talk about Software Engineering.

When I do DevOps work, I’m doing software engineering. When I hire for DevOps roles, I hire software engineers. But I don’t hire just any software engineers: I want the ones who care about the delivery process. They know how to build software, and also how to put it in front of the user – and how to keep on putting that software in front of users, sprint after sprint, story after story, rapidly, efficiently, and without breaking things.

‘DevOps Engineer’ is the next ‘Full-Stack Developer’ – and not because it’s the next hype-cycle in tech hiring. In the same way full-stack developers expanded their scope to cover both the UI and the back-end, DevOps engineers have expanded their scope beyond writing software – and into the realm of how we get that software in front of users, in the fastest and most reliable way possible.

No longer are we content to just build back-end systems and UI layers on top of them: as a profession, we’re coming to understand that software engineering is bigger than just churning out vertically-sliced user stories. Software engineering is about building the right thing and keeping it running – and a DevOps engineer is a software engineer who cares about both steps. You don’t want a team full of DevOps engineers – but you definitely need at least one.

When I talk about DevOps, I talk about Agile.

You start to see the real benefits of automation when you’re deploying to production regularly. For example, if you’re only shipping a few times a year, the overhead doesn’t hurt you that much. If you have a 6-week QA pipeline and a 2-month UAT window, you don’t need DevOps (yet). Once you start trying to deploy regularly – getting your cycle time down, keeping your WIP low, delivering value to the user faster and more frequently – that’s when the overhead starts to hurt.

Once you introduce agility to your process, that’s when you need to pay attention to the DevOps movement. That’s when you need some software engineers who care about automation. Please note though that I’m not saying you need “some DevOps” – there’s no such thing as “some DevOps”, and anyone who tries to sell you “some DevOps” is doing you no more favours than someone who tries to sell you “some Agile”. What you need is some smart software engineers who care about DevOps – and you need to give them the time and resources they need to do their job.

When I talk about DevOps, I talk about teams.

DevOps engineers are software engineers, but that doesn’t mean you should fill your software teams up with DevOps engineers. DevOps engineers tend to be passionate about a bunch of really interesting stuff: resilience patterns, testing, automation, source control, and release management. The great thing about multi-disciplinary, cross-functional teams, however, is that you get a bunch of people with different passions together, and that breadth gives you the ability to do great things. Don’t try to hire DevOps engineers (or worse, to build a DevOps team). Hire software engineers, and when you find ones who are great at DevOps, keep them.

Having cross-functional teams also gives your team members the chance to cross-skill while they work with other team members, which is why…

When I talk about DevOps, I talk about teaching.

Great DevOps engineers have a genuine enthusiasm for quality software engineering and release management, and their enthusiasm is infectious. Great DevOps engineers don’t hoard their knowledge, but help their fellow software engineers to learn more about the DevOps mindset by sharing what they know. They also learn from their colleagues who specialise in other software engineering fields, becoming more well-rounded themselves as they help others do the same.

Finally: When I talk about DevOps, I talk about people.

DevOps is a branch of software engineering – and whatever you might hear, software engineering is all about people. It’s about the people who use our software, and the people who build it. DevOps is the intersection of those two groups: users and developers. Our users are not just end-users, who enjoy higher-quality software, but also our fellow engineers, who rely on our automation to work more efficiently. They’re our managers, who rely on the insights we give them into the release process. Our users are the junior software engineers who may one day specialise in DevOps engineering – or who might use what they can learn from us to be better at some other branch of software engineering.

And as always, we have a bunch of work on, and we’re hiring.

So, I have two things to ask. Firstly, if you have feedback on our job ad, please reach out! I’m always trying to improve these things.

Secondly, if you’re a software engineer who cares about the difference between GitFlow and GithubFlow; who has made calls to the Octopus API; or who loves showing other developers how to write a better test or add more context to a log message; please talk to me about joining Elabor8. We’re a bunch of software engineers who care about DevOps – and our users aren’t just one team, but a range of teams across some really great clients. If you want to take the engineering you care about and have a broader impact on more people, you want to join us. Get in touch.

Like this:

Wanted: Senior DBA!

Minimum 10 years experience managing SQL Server 2015 or newer

It’s a classic joke – the job ad which wants you to have experience in a specific technology for longer than it’s existed. Sadly, it’s funny because there’s a grain of truth in it: job ads are terrible.

I hate seeing job ads like this one. You want someone with 1-2 years’ experience to know all of that – and be confident enough to tell a recruiter that, and back it up in an interview? You’re not selecting for capability here. You’re selecting for over-confidence, and the coincidence of having a first job which involved just the right mix of technologies.

Technology Leadership Position!

Are you a dynamic leader with top-notch management skills and brilliant technical ability? Do you have world-class knowledge of big data platforms and machine learning? Are you just as comfortable writing a PhD dissertation as you are selling a group of executives on a new company strategy? Do you have a passion for creating a dynamic company culture and mentoring a team of brilliant engineers, all while maintaining an unwavering focus on creating an unmatched user experience? Do we have a job for you!

If you’re posting a job ad like this one, you’d better have a remuneration package to match; but you probably don’t. The technology industry is full of people with imposter syndrome – and if the perfect applicant (who would have been great for your team) didn’t have it before they read this job ad, they will afterward. If the candidate who does meet that brief exists, they’re definitely not reading job ads on Seek, anyway.

These are, of course, caricatures, but they’re not so different from real job ads I’ve seen. How about a real example from my own life?

Checkbox Syndrome

Many years ago, I landed a job in the United States (I’m based in Australia, so this would have been a big move for me). The recruiter explained that the job had been open for nearly two years, and they were thrilled to have found me! I was their first suitable candidate, and they were keen to rush me through the hiring process.

This puzzled me, because I’m not that special. How was I the first suitable candidate in two years?

Well, it turns out that they’d written a very specific candidate description, and someone in HR had been handed the job of finding someone that matched. They were after someone who listed optimising high-throughput transactional systems on their LinkedIn profile, and who had completed at least two years of tertiary study in Latin or Ancient Greek.

They were building some language-processing software, and someone had decided that an engineer with a background in linguistics would be good to have on the team. That was somehow translated to requiring some tertiary education in a classical language – and bam! Two years of turning down candidates who probably would have been highly successful in the role. All they actually wanted me to do was to come up with a way to load-test the system, and then find hot-spots in the code and optimise them.

I never did end up moving to Houston: my visa application fell through (thanks, Global Financial Crisis). It was probably for the best: I wouldn’t have been a person to this company, or even an engineer; just a series of checkboxes.

What is a job ad for, anyway?

When you’re writing a job ad, please don’t forget what the ad is for. Your goal is to attract suitable applicants to apply, and discourage unsuitable applicants. Anything which doesn’t accomplish one of those two things is wasteful. Anything which discourages suitable applicants is a net loss.

As a specific example of this, please leave “Good Communication Skills” out of your ad. You might think that poor communication skills will disqualify a candidate – but putting that in the ad isn’t going to stop unsuitable candidates from applying, and it’s not going to encourage suitable candidates to apply. It’s noise. Leave it out.

Sell the job – genuinely

It all starts with empathy. Try to imagine yourself as your target engineer, tester, analyst, or whoever you’re trying to hire. Your goal is to sell them on the job, but also keep enough important criteria in there to discourage unsuitable applicants. The selling part is important: if there aren’t many great candidates out there, you need a job ad which will attract them. Candidates are about to invest a significant amount of their own, personal, outside-work time in applying for and interviewing at your company, and then you’re going to ask them to resign from their current position, where they have friends and valued colleagues and know the system, to join your team. Give them good reasons.

Please don’t give them a sales pitch. Don’t spend most of the ad spruiking the company. Talking about how great you are is for your marketing material, or your annual shareholders’ report.

Just talk honestly about your culture, values, and benefits.

Anatomy of a Good job ad

Here it is. This is what your job ad should look like.

Talk about the role.
Tell prospective candidates a little bit about the company and the role. This should be short. What does your company do? Who are you looking for? How will this position further the company’s mission?

Say who you’re looking for.
Really cut it down. Don’t have 10 bullet points. Keep it to 3 or 4. Try to focus on higher-order skillsets, rather than specific technologies, unless that technology really is core to the role.
If “Good Communication Skills” is making it to your short-list of 3 or 4 key skillsets, I hope you’re hiring a radio operator or air traffic controller. Otherwise, please, just leave it off.

Tell them what’s in it for them.
Describe your benefits. Tell them about the great company culture. Talk about training and conference budgets and career opportunities. Once again, keep it short and to the point.
If you can’t think of anything to put here, you might have bigger problems.

Tell them how to apply.

That’s it. Really. No nice-to-haves – those just give suitable candidates a reason not to apply. Don’t do that. If you get two suitable candidates, and one of them happens to have one of your nice-to-haves, you might still offer the role to the other based on the bigger picture. If it’s not necessarily a differentiator even at the end of the recruitment process, it definitely has no place at the beginning.

But I want to list a bunch of stuff!

Resist the temptation. Are you hiring a team lead? Just say you’re hiring a team lead. Don’t list out all the stuff that team leads need to do.

Lead a team of software experts to deliver innovative products.

Help to work with product owners to deliver real business value!

Mentor senior engineers, and help them to mentor juniors.

Engage with the business about technical challenges.

Foster a strong team culture.

Don’t do this! Team leads already know the day-to-day detail of the role, and they won’t be going back to the job ad to work out how to spend their time. Just say that you’re looking for an experienced team lead or a senior engineer looking to step up to a team lead role – and get on to covering the more important points! What kind of team is it? What is the team mission? Are you looking for someone to drive a major change, to keep an already-high-performing team pointed in the right direction, or to build a whole new team? That stuff is much more useful than saying things like “Ensuring the team is aligned with business priorities”.

Where do I put things like “Strong work ethic” and “Ability to work in a collaborative team environment”?

In the same place you put “Good Communication Skills”. People who don’t have a strong work ethic or the ability to work in teams are going to apply anyway, so all you’re doing is making the job ad longer and more boring.

This sounds like you’re a really cool person and I’d like to work with you.

No. This doesn’t match my “Anatomy of a Good job ad” at all! But recruitment is bigger than just job ads, and this was, secretly, a bit of guerrilla recruitment. That’s another idea I’m hoping you’ll take away from this post: recruitment is about a lot more than just writing a good job ad. It’s about being a place people will want to work, and making sure the right people know it.