On Thursday 5th February I gave a very short presentation at a TalentWaffle event organised by Reconverse. TalentWaffle is a meet-up for recruiters in the London tech start-up scene, with guest speakers, solution demos, and the chance to connect & converse. It was a great event, I met a lot of interesting people and was able to share a few pro-tips about hiring people for organisations looking to get into DevOPs. My presentation was about how to engage, recruit and retain engineers.

I only had a 15 minute slot so my content had to be very focused. I didn’t know how au fait the audience would be about DevOps so I actually prepared two presentations. One was an introduction to DevOps with a few basic tips to help recruiters understand what they were getting into if their technology departments started asking for DevOps people. I also prepared a more advanced presentation aimed at those recruiters who were in organisations that were already using DevOps.

The event wasn’t videoed so I thought I’d share my presentation in long form here, that way the three recruiters who were interested in the more advanced content could get to see it :).

So without further ado let me present:

One day I will do a presentation in the style of a choose your own adventure but 15 minutes didn’t really provide me with the opportunity. As such I explained to the audience that the topics in white were the beginners guide content and the topics in blue were the advanced topics. As I have a little more time here I’ll just run through the slides in order.

Yes, yes this is the obligatory “What is DevOps slide” but in this case this slide gave me the opportunity to convey a specific message to the recruiters in the room. This message was pushed further by Ken Ward and Matt Buckland later in the evening. Recruiters are in a position of great power and responsibility and unlike Spiderman they don’t have to just whinge and cry about things like an angsty teenager. Recruiters have a huge influence over the attitude and culture of an organisation because they present candidates for interview. If their CTO is asking for DevOps people the recruiters are in a position to find out whether the organisation is really ready fro DevOps or whether the CTO just thinks DevOps is the latest name for System Administrators.

This is the first of the more advanced topics. If I’d had the opportunity to present this slide I would have explained to the audience that engineers capable of contributing to a DevOps environment are rare and so they need to be sought out. It’s not enough to release a job spec into the wild and wait for them to turn up. Recruiters need to get on Github and look for the contributors, they need to follow the bloggers and build a network of contacts.

For recruiters in start-up organisations looking for one or two engineers this is impractical. The only alternative if the current employees aren’t able to suggest anyone is to go to the agencies. There are a few recruiters who are making names for themselves in the world of DevOps recruitment these people are making it their business to understand DevOps, the field, the people, the roles and the organisations. If anyone needs recommendations of good external recruiters then please get in touch.

The second major point I wanted to get across with this slide is how to get the attention of those good DevOps people. Every job spec talks about technology as if the particular tools an organisation uses is important. The field of DevOps software is incredibly fragmented and evolving rapidly. This week’s hot software will soon be old news. There are a few packages that are starting to mature and look like good solid options but they could well be eclipsed tomorrow.

Good engineers are far more interested in how engineers collaborate within an organisation to achieve their goals than they are in the tools and technologies used. Nothing is cooler than seeing what happens when motivated and talented software, testing and operations engineers are allowed to focus on a common goal and work together. That’s exciting, that will get engage people.

The UK has a strong and vibrant contractor market but some CTO’s seem obsessed with finding permanent DevOps people. I’m asked about it all the time. I’m told that permies have more “skin-in’the-game” how they’re more committed. This doesn’t match with my experience. Good engineers are committed and know they’re only as good as their most recent success. It doesn’t matter whether they are salaried or if they invoice.

To be capable of building, launching, managing and supporting services using DevOps methods and tools an engineer has usually been through the wringer. They’ve worked in environments where the CTO is an ex-developer and the developers leave at 1700 on a Friday having supplied software that won’t deploy at 1600. They’ve been expected to be on-call 24x7x365 for no extra pay and been blamed for live service incidents that weren’t their fault. So when the opportunity comes up to do what they love for £60,000 or £550 per day the choice is fairly straight-forward.

If it’s culturally important to your organisation they you have permanent engineers then grow your own! Encourage your organisation to invest. Hire a couple of good, senior, contract engineers and then bring in young people who haven’t yet learned any bad habits. Hold a hackathon to look for talent, encourage hobbyist engineers looking for their first step into IT and grow your own DevOps people.

Engage? Check! Recruit? Check! On to retention! I’ve spoken to a lot of organisations and recruiters since I launched my book last year. I’ve heard a lot about organisations struggling to retain engineers. I’ve seen some of the issues among my friends and former colleagues.

In almost every example the issue comes down to organisations not understanding that without collaboration there is no DevOps. Organisations that attempt to bolt a DevOps team onto their current organisation can only fail and make everyone miserable along the way. Creating a DevOps team to manage deployment automation while software engineers continue to design services with no input from the people responsible for operating or testing them just doesn’t work. Oh sure you’ll get away with it for a while but the approach you used to build software is not the approach you need to build a service. Services live they don’t just launch, they need support and management and optimisation. This isn’t done by presenting different challenges and incentives to different teams of people with different skill-sets and experiences. Online services flourish when talented engineers with different knowledge and experience work together to design, build, launch, manage and support services. Nothing is more inspiring or motivational than being part of team of talented and passionate engineers all focused on the same goals. If your organisation pays well, encourages real collaboration and hires talented people you will have no retention problems.

That’s engagement, recruitment and retention out of the way now I wanted to focus on a couple of pro-tips.

I love it when job spec’s list, Chef, Puppet and Ansible. I understand that the organisation is probably trying to convey that they want to use one of those tools and hasn’t decided which one yet. To many engineers that looks like either the organisation is using all of them. If that’s the case that company are a car crash that no-one wants to be a part of. Failing that the recruiter has no idea that all those tools do almost exactly the same job, in which case the organisation may be clueless and no-one wants to be there either.

If you want to make your job appear attractive and stand out from the crowd of DevOps job descriptions describe how your organisation collaborates. Do you eschew the old paradigms of teams based around skill-sets? Do you matrix manage teams around products? Sell people on how they’ll work with their peers to achieve your company’s glorious vision. Remember engineers love solving problems, they love making the world a better place. They don’t care whether they need a spanner or screw driver to solve the problem.

Tell prospective candidates the problems your organisation faces right there in the job spec. Make it clear that you and your organisation are honest, introspective and forthright. Those are all qualities almost universally valued by engineers.

I wanted to finish with something that would help recruiters present good candidates to their hiring managers. I wanted to help them identify engineers who are best suited to working in start-ups or newer business.

The main point is that good engineers that can work in collaborative and supportive teams are passionate about what they do and how they do it.

Ask them about something they built a long time ago that’s still running, ask them why it’s still useful. Do they get passionate? Can they laugh about a horrible hack they were forced into that worked so well it’s still running years later?

Ask them about what language they like to code in? Ask them why they care about it. It doesn’t matter if you don’t understand the answer but you’re looking for an answer that conveys that engineers passion for their profession.

Ask them about a time when they worked directly with software and test engineers to achieve something bigger and better than they could do on their own. Do they have the excitement and sense of wonder that comes when you see teamwork actually work.

Finally no Next Gen DevOps presentation would be complete with a shameless book pitch, so here it is: PLEASE BUY MY BOOK!

Thanks.