This episode is part of a recruitment mini-series; where I will be focusing on various characteristics that I believe are important in recruitment. And while I believe many of these themes are universal, I will of course be focusing on software development. In this episode I talk about the importance of defining the role.
Or listen at:
Published: Wed, 19 Feb 2020 16:48:07 GMT
Transcript
I find that too often an organisation will immediately reach out to a recruitment agency - with little to no real thought about the role or indeed why an individual would want to work for them.
And this really doesn't help you in terms of getting value out of the recruitment process.
For any role, I first take the time to define it in a written briefing.
This isn't just the traditional job spec.
Its more than just a summary of what the job looks like,
It will summarise the recruitment process, what the company is offering and why any perspective candidate would want to take the role.
Let's talk about that last point first.
Why should someone apply for the role?
Why would someone want to work for your organisation?
When I trailed this series back in episode 26, I say I'd ask uncomfortable questions about what is it like to work in your organisation - this is that time.
Often we concentrate so much on what we want as an organisation, we lose track that this is ultimately a transaction - we will be providing something to the employee for their services.
And in a market with considerable skills shortage for exceptional developers, we really need to think about how we sell ourselves.
How we can make our organisation stand out more that other organisations attempting to attract the best.
While money is obviously a factor in that - something I'll look at more in the next episode, having an appropriate remuneration package is effectively "table stakes". If you aren't offering enough to get them to the table, then you are going to struggle.
But once you have them to the table, there are many other factors that will be attractive to potential employees.
Key factors such as:
- The technologies they will be working with - older technologies are generally less attractive
- The office environment and company culture
- Flexible work
- Remote work
- Personal development
So you have to ask yourself ahead of time, what can you offer in these terms?
If you don't have a great story on these - then start to address them immediately.
While any immediate change is unlikely to help your current recruitment activity - it will help with retention of existing staff and in future recruitment.
Ultimately you should be treating this like any sales campaign.
What does the market want?
What is the expected?
Then exceed it.
And you should then be able to articulate that via the briefing document.
Think of that document as a sales brochure.
Initial rejections will come quickly from a poor effort. Whereas doors can be opened with an excellent one.
Again think of this as sales.
I will also outline the recruitment process in the briefing document.
I'll tell them if its going to be a telephone interview followed by a face-to-face.
I'll tell them the format of those interviews - who is likely to attend - and what they can expect from it.
If we're doing a technical test of some form, I'll say so.
Interviews are not the right place to "surprise" people.
While I'm aware that there are recruiting processes out there that go out of their way to put a candidate onto the back foot, I don't agree with them.
We aren't trying to catch the candidate out.
We are trying to establish if the individual is a good fit for the organisation and vice-versa.
Ideally the briefing document should also answer many of the questions that come from the candidate or recruitment agency.
I generally expand this with additional information like:
- Holiday allocation
- Sickness policy
- Training plans
- Office conditions (shared, noisy, etc)
- Parking/ transport
- Types of work – greenfield, brownfield, mixture?
- ... and anything else that affects your Developers on a day-to-day
This may feel like extra work – but I find a few hours spent on this pays dividends with both recruitment agencies and the candidates.
The agencies appreciate the additional input, and candidates really recognises that this is an important role for you ... not just a seat to fill.
Ok, now lets talk about the job spec itself.
A common mistake in recruitment is defining the role by specific technical skillsets.
While obviously a level of technical skillset are important in a software developer, I find a common mistake is made:
We list every technical skill under the sun - and they become the "only" focus of the job spec, agency engagement and interview process.
If you want to get a great developer that will add value to your organisation, you want them be able to demonstrate two things;
Firstly that they can learn; and more important apply that learning. The technical landscape moves so quickly that the critical skills today will be eclipsed by new skills in 6, 12 or 24 months time. Nothing stands still.
Within the industry, there is the concept of the “developer half-life”. An acknowledgement that of the technology skills we use today, within a number of years, half of it will no longer be relevant.
I’ve read various estimates on the numbers of years – ranging from 2 to 7 years generally. Personally I think that half-life is dependent on the technology in use – but 4 years is probably a good middle ground.
To give you some idea of how quickly things change; Microsoft’s primary website framework - ASP.Net MVC - has gone through 7 major revision since 2009. Each of these revisions changes how the framework behaves.
Yes there are some core principles that survive through each revision – useful knowledge to take forwards - but each revision has benefits which, if not learnt, will generally mean missed opportunities for improving revenue or reducing costs.
Continual learning and an ability to apply that learning is of critical important to not just software development, but modern business in general. And yet I'm constantly surprised that this rarely shows up in job specs or interviews.
The second thing you want that great developer to demonstrate is excellent communication skills.
They need to be able to clearly communicate ideas, problems, options and solutions – be they business or technical.
Getting the “wrong end of the stick” is such an easy way to introduce huge wasted expenditure.
So many of todays software project failures are down to the communication problems rather than any specific technology in use.
"Strong communication skills" will normally make it as a last bullet point on a job spec - basically an after thought.
It needs to be elevated in its importance both in terms of the job spec and interview.
Once you have your completed briefing document, I would then ask you to review it with diversity in mind.
As a middle aged white male in the technology industry, I'm not really the best person to talk about the challenges when it comes to diversity.
I do however understand that diversity does matter.
I freely acknowledge that earlier in my career that the term "cultural fit" would have been part of the job briefing and part of the recruitment process.
I would be looking for people that would "fit" with the existing team. I'd believed that in doing so, there was a greater chance of team cohesion and collaboration.
That approach could very well have had the reverse affect - it could actually have lead to very singular team with little diversity in thought and action.
There is overwhelming evidence that diversity produces better outcomes.
I'd recommend reading the book Better Allies by Karen Catlin - she provides advice on how to review your recruitment process for any diversity problems.
In this episode I discussed taking the time to define the role and produce a briefing document.
I talked about how the document should be provided to recruitment agencies and candidates with all the information they need to understand the role and your organisation.
I've stressed the importance of selling your organisation in a skill short markets. I've asked you to think about how your organisation will be perceived by potential candidates.
I've warned about over focus on the soup-de-jour technical skills - rather look for those that demonstrate an ability to apply learning and have exceptional communication skills.
And finally I've advised you to use the Better Allies book by Karen Catlin as a resource to help avoid missing out on great developers though diversity blunders.