It’s just that we’re doing hiring wrong
When attending meetups, particularly the manager-heavy kind, the current “skills shortage” in our industry often comes up. At a recent discussion session the organiser tabled this very topic – first asserting there is a skill shortage, then challenging the room to discuss how to resolve it. Of course I had to blurt out: “There is no skill shortage: we’ve just been doing it wrong!”
Fewer things are more effective at exacerbating imposter syndrome than being the focus of a room full of high level technology managers in a fancy restaurant, at a session organised by a Silicon Valley giant.
As impulsive as my statement was in the moment, this is a topic I feel strongly about. I believe that if one hires according to the accepted norms in our industry, then it may certainly appear there is a skills shortage – the statement rings true. It is also true that the standard hiring practises also result in homogenous teams that fail to represent, and therefore serve, the customer base they create solutions for.
I propose that not only is there no skill shortage in technology, there is an abundance of people willing to join our teams. We’ve just got to stop limiting ourselves to the standard candidate pool, take ownership of our culture, and create the demand that pulls people into our field.
What we’re doing wrong (and how to fix it)
Whoever you are, wherever you work – whatever shape your team is: you’re doing great! I mean, you care enough to bother reading about how to improve, right?
This is long and when read in one go it paints a pretty sad picture of our industry. Our industry is sad, and we who are in positions to change it should feel bad.
I agree it’s hard. But we can fix it. The alternative is to do nothing, which I won’t tolerate. These organisational, behavioural and cultural issues can be fixed in the same way we fix bugs – by focusing on the cause and changing our process until the bug no longer recurs.
What follows is a list of the most common problems I’ve seen or discussed, with easy to follow pathways for you to follow if you want to fix them in your organisation.
Using qualifications as predictors of future performance
Don’t turn people away at the gate
Problem: If your job advertisements mention a degree as being a requirement for applying for a role or you list extensive responsibilities, you’ve immediately alienated a large pool of candidates.
Background: I’ve been successfully converting code into money for over 12 years. I have a degree, sure: in Social Studies. Although I did take programming papers, I’ve never used anything I learned in those classes on any projects except for knowledge of basic syntax.
On the team at Lightbox NZ, we had four engineers who either did not attend university or studied completely different subjects. Two of them transitioned from manual testers to automation engineering in a matter of weeks. They completed online course, then paired with their teammates. The other two came into engineering positions fresh from the Enspiral Dev Academy – having completed an 18 week bootcamp. All of them contributed at least equally to the business compared to their university trained colleagues.
There is a confidence gap between men and women, and between cultures. When hiring, this gap will manifest itself in fewer applicants from women and other cultures when advertisements explicitly state required qualifications or include long lists of responsibilities.
Solution: Do not mention qualifications or lists of responsibilities in your job advert. Universities do not have a monopoly on the teaching of software engineering skills. Applicants will tell you why they think they are qualified – this is the main function of a CV.
Research shows that men will apply for jobs when they feel they achieve 60% of the qualifications or responsibilities. Women may not apply until they feel they achieve 100%. On reflection, this is what I do. To me, lists of responsibilities and even required qualifications are “nice to haves”. If I think I can do the job, I’ll apply. It works for men, and as a side note – it can work for women too. But please, don’t expect women to lean in: change your process to include them.
Commitment to culture is commitment to people, and that takes time. Understand this and allocate sufficient time to do a first pass of candidates that takes into account all the qualifiers people put into their CV.
The best engineers love learning – some love it so much they taught themselves to code and therefore never needed to attend classes. Some attended bootcamps. Some (like me) didn’t know a career in programming was possible until their early 20’s, and thought university was the only way to learn.
Programming is becoming a commodity skill, complemented by people skills, background experience, and a personality. Requiring a degree or including extensive lists of responsibilities will limit your application pool.
A clone army is inflexible and prone to bias
Be careful of subtle biases in your hiring material
Preamble: Research shows there are significant advantages to be gained by having a diverse and inclusive team. Topics in this section have been written about extensively, including articles in Forbes, Gartner and the Harvard Business Review: diverse teams doing the right thing most of the time, generally perform better than monocultures and how to disrupt bias on your existing teams.
I’d like to focus on how you can change your hiring process to cut off the source of clones. This will increase your pipeline of diverse candidates, enabling you to build out and maintain a diverse and inclusive team.
Problem: Your job ad and hiring process are designed to hire people who look and think like you.
Background: This is a tough pill to swallow. I thought I had done everything possible to ensure my job advert was as attractive as possible to all candidates. I was committed to creating a diverse and effective team. I’d consulted people in my community of different gender and cultural backgrounds from me on my advert content. I passed it through the gender decoder & Joblint tool.
Only 2 of the 60 or so qualified applicants were women, and only 15 of the remaining 58 were not caucasian males. Something was obviously wrong. The issue was no longer with the advert itself, but with what happened next: the process through which an applicant registers interest was hilariously broken.
Turns out the software we used to manage the hiring process had been configured with a bunch of default options, which were frankly horrible. Instead of being asked for general identifying details and a CV, the candidates were requested to:
- Upload a cover letter
- Upload a photo
- Phone a robot and leave a voicemail introducing themselves
A cover letter I can understand – but I don’t care to read them: an applicant’s CV should be enough to decide whether to have a quick chat on the phone. I know from experience that writing a cover letter for each job application is draining and time consuming torture that I wouldn’t wish on anyone.
Upload a photo? This was a surprising one. I mean – this wasn’t the first time I had hired for this team, where else did I think the photos were coming from? I had assumed there was some clever programming going on, with the system pulling them from LinkedIn. Nope, the applicants were required to upload a photo. For a programming job.
Phone a robot? Leave a message?! I can’t even.
The process of discovering this was rather embarrassing for me and uncomfortable for the person who brought it up. I had the CV from a wonderful applicant given to me and needed her to apply online in order to proceed. She took longer than I expected to do this, so I reached out and asked if everything was OK. After learning the above I immediately apologised and spent the next two hours figuring out how to remove everything but the bare essentials from the application form.
This dramatically increased the diversity of applicants.
Solution: Take an MVP approach to your application form.
After posting a job advert, use incognito mode to go through the process of applying. If there are any steps that could be postponed until you’ve had a chance to view a CV, remove them. You should ask only for the bare minimum: name, phone number, email, availability & CV.
Don’t ask for anything that is not necessary for you to decide whether to do that first phone call. Make sure your application form does not ask for salary requirements or a cover letter. Request nothing but the bare minimum.
No clear process for addressing gender imbalance in applicants
Also known as the “but no women apply” problem
Problem: For any given technical job advertisement, 5% women applicants is considered winning.
Background: You know diverse teams benefit the business, the health of our field, and society on the whole. You’ve removed all the unconscious bias from your process. But still, 95% of the applicants coming through are male.
Solution: Switch from passive to active recruitment. An amazing way to kick this off is to pick an arbitrary point in your hiring process, and require hiring managers to collect a 50/50 mix of male/female CV’s before allowing the process to proceed past this point.
This will force yourself and your hiring managers to be less passive about collecting suitable applicants. When I started doing this I found I started having much more direct conversations with recruitment companies. I started to understand which recruiters were able to change their process, and which weren’t. This lead to me reaching deeper into my network for specific leads. Ultimately I was forced to form a deeper understanding of the issues facing our industry, and develop the alternative processes I’m documenting here.
I cannot take credit for this critical suggestion. That honour belongs to Amanda Santos, who presented at length on this topic in the 2018 SparkONE Unconference.
Hiring processes often require unrealistic amounts of time from applicants
Only people with heaps of free time are eligible to work on my team
Problem: Many companies “validate” technical abilities of applicants by requiring them to perform a take home test that attempts to simulate a real-world problem. Said test is then handed in and evaluated by team members who rate it on some opaque marking criteria. Applicants who do not score well on these tests are not considered further.
Background: Hiring people is scary. There is huge room for error, and the consequences have a large impact on teams – positive for great candidates and negative for poor candidates.
It is important to evaluate the technical competence of applicants, but this task itself is wide open for abuse that will ostracise the otherwise great people who may apply for a given job.
Consider the applicant’s perspective: they want a new job. In order to do so they must apply for available positions. There are 10 positions available at their preferred location that appear to meet their criteria. If each position requires candidates to complete a take home test that was intended to take 4-8 hours to complete, the applicant is looking at an additional workload of 40-80 hours on top of their current job.
It is hopefully obvious that this is unrealistic even for a single person who works 40 hours a week, has no hobbies or personal responsibilities that require significant time.
In this “ideal” scenario, the person is able to put in 2-4 hours a night after work, up to 16 hours a weekend. This person will be able to apply for 2-3 jobs per week. It would take them up to one month to apply for all 10 jobs. Consider the demographic this fits, and compare this to the majority demographic applying for your positions.
Now consider reality for most of the rest of us: we work 40-60 hours a week, have a spouse to share housework with, have children we are responsible for. Maybe we also have ageing relatives to care for. Also we could just be old and jaded and unwilling to burn ourselves out just to jump through recruitment hoops.
We can apply for up to 1-2 jobs per month on the outside, more likely we’d be unable to properly service one application that required a take home assignment per month. Consider the demographic this fits, and again compare it to what you see in the demographics applying for your positions.
Broadly, these tests function to eliminate women and single parents from the hiring pool and disempower career changers.
Solution: Get creative and flexible with how you validate a candidate’s ability. Some candidates may have an amazing GitHub profile. Many may have creative and technically interesting portfolio websites. Some might have nothing.
You should consider how you might use what candidates can offer to validate their stated skills and experience against your requirements, and have plan on how to quickly and fairly assess those who are unable to provide anything.
This solution hinges on the understanding that there is no one-size-fits-all approach to evaluating technical skill. Like any dogmatic approach, fixating on one metric will cause you to miss out on many candidates.
In order to fix this aspect of the hiring process, we should force ourselves to consider multiple ways to validate skills, and be ready to apply whatever is appropriate on an individual candidate basis. I like David Gilbertson’s take on this topic, and recommend you read his article: How to hire the best developers. Excellent exploration of the failings of “testing culture”, with solid advice on how to avoid losing out on great candidates while effectively screening poor ones.
Being a manager means managing people. Hiring the best people requires real work and must be approached with the same care and rigour we apply to resolving the most troublesome bugs.
Belief that seniority can be inferred by years on the job
Doing things wrong for ten years is not better than doing it right for two
Problem: Many people blindly assume that there is a correlation between the number of years one has been in a field and their seniority in said field.
Background: I used to hold this assumption, and when posting jobs for seniors I would include something like “Must have W years experience in X & Y, overall must have been in technology as a programmer for Z years”.
I held this assumption until I hired someone who was, on paper, very senior. Their on-the-job skills failed to live up to expectations, they left, and I had to rescue their projects over many late nights.
This caused me to carefully reconsider what I mean when I say “senior”. Instead, seniority needs to be categorised according to measurable traits and skills, for example:
- Entry level engineer
- Can complete only trivial tasks without significant help
- Has shallow understanding of at least one complete area of the team’s software
- Is learning how to take ownership of self-learning
- Actively seeks out mentorship in the technical space
- Intermediate level engineer
- Can complete middling and higher complexity tasks without significant help
- Has deep understanding of at least one complete area of the team’s software
- Has mastered self-learning and looks for opportunities to expand their knowledge
- Maintains mentorship relationships in the technical space, has started mentoring less senior members, actively seeks mentorship in the interpersonal space
- Senior level engineer
- Can complete tasks of any complexity level
- Has deep understanding of most areas of the team’s software
- Seeks out opportunities to increase knowledge and understanding across the team
- Actively mentors members of the team at all levels
Notice there is no mention of time on the job. I’ve had team members who have been in software engineering for less than two years meet requirements for the top intermediate level. Then there is the person who, despite many years in the industry, could barely be categorised as entry level by the above descriptions. The above categories are a very diluted version of a much more comprehensive document I’ve been working on for years – inspired by the CircleCi Engineering Competency Matrix. I’ll blog about my interpretation of this concept in a future post.
Solution: Seniority, expressed in years on the job is not a good hiring metric. Seniority has little to do with technical ability. Do some research and decide yourself what seniority means for your team. Don’t blindly assume that anyone with a good number of years on the job will meet your requirements. Learning the hard way hurts.
Practise interview techniques that highlight skills that are difficult to teach
Favour methods that expose flexibility, teamwork and willingness to deal with change
Problem: Common interview dogma is that we should focus on proving a candidate can perform technical tasks adequately well. This is wrong as we are not robots that are easily interchangeable, and technical skills can be taught quickly to the right people.
Background:As outlined above, technical testing interview culture does nobody any favours. Instead we should focus on proving the candidate:
- Can learn
- Can deal with change
- Is flexible
- Can take feedback well
- Works well with a diverse range of people
Being able to learn is important, and ties in well with dealing with change. Over the course of my engineering career I’ve gone from JavaScript to PHP/MySQL, back to JavaScript with probably 5-10 different frameworks, then Java, then Node, then AWS appeared. The most accomplished developers on my teams have similar histories. Nothing wrong with loving a stack and sticking with it – but limiting your choices to only those with “x years of experience in stack y”, can prevent you from seeing a good number of excellent applicants.
Flexible applicants with great communication skills should be favoured over “rock stars”. Being able to pair with a business-focused team member to solution out a feature is much more important than being able to make the fanciest, most efficient widget. Consider the following comparison between two developers, one who is amazing at programming but poor at dealing with people or with change, and one who is middling in skill but excellent at dealing with people and taking feedback. Both are given a task that is estimated to take two weeks.
- Amazing engineer finishes it in one week, and demos it to the lead. The feature has been implemented in a way that is incompatible with the solution architect’s vision, which was alluded to in the ticket and mentioned in planning. The engineer goes back to the drawing board and takes the remaining week to complete the task according to the spec.
- Middling skill engineer spends a day or two asking questions and understanding the underlying business requirements for the task. They take the remaining eight days to complete the task. Since they spent time asking questions and didn’t get started until they fully understood the problem domain, their solution passed scrutiny.
Both engineers finished their task in the same amount of time – the difference is the management and technical overhead required for each team member.
As a manager, I want team members who proactively look to fill holes in their understanding of the underlying reasons for their work, and who raise flags early. I do not want team members who go silent for weeks and surface only with what they consider a “finished” feature.
Solution: Consider how to interview and screen for applicants who possess the interpersonal skills, flexibility and communication ability that make for a great team. Do not fall into the trap of hiring for technical ability alone.
Interpersonal skills, flexibility and communication ability can be exposed with a surprisingly simple tip my current boss, Jean-Louis taught me:
Spend the first 10-15 minutes of the interview generally chatting. Your discussion should aim to surface some strongly held technical opinions (e.g. Docker is bad, Azure is better than AWS, Go is better than Rust, whatever – you don’t have to be an expert in it for this to work). Once you’ve got your topic, turn the conversation back to it, positing that you strongly feel the opposite is true. Maintain this position.
People with skills I claim here are desirable will argue with grace, no matter how unbelievable they find your position to be. People who don’t have these skills … will act vastly differently.
The idea is to simulate the type of interactions engineering teams should be experiencing frequently: the free exchange of ideas and suggestions without egos getting in the way. We want everyone on the team to feel comfortable expressing their opinions – if they’re wrong, they learn why. If they’re right, the company learns a better way.
Understand that different genders and cultures view their position in hierarchy differently
Pay attention to what their experience tells you they can do, not what they apply for
Problems: Observations during hiring have shown me that people are vastly different in their opinions of their own position within professional hierarchies, and therefore how eligible they might be for open positions.
Background: When advertising for multiple roles identical in everything but the expected level (and therefore pay), I’ve found that women and people from cultures different to mine are more likely to apply for roles lower than what I argue they should be applying for.
Solution: When faced with a situation where an applicant is clearly applying for a position below them, don’t knowingly hire them into the lower role. If you have a higher level position available, at your earliest opportunity inform them that you very much appreciate them applying for the role they applied for, but you’d be very interested in interviewing them for the higher role.
I’ve taken this approach with multiple hires. In some cases it took some convincing on my part to have them confidently proceed with the higher position, but in all cases they excelled at their new roles.
Wrapping up this long but not exhaustive list
Go forth and build a diverse and inclusive team
Building a diverse and inclusive team is challenging, and takes more time than hiring according to decades-held traditional dogma. It’s worth it: as with biology, a monoculture always loses in the end when competing with a mixed population – the same is true for technology teams.
There are clear benefits to hiring and maintaining a diverse team, like doing the right thing most of the time and performing better than monocultures.
The solutions to some problems I’ve faced when hiring technical team members should help you restructure your recruitment strategy into one that favours applicant’s who will take your organisation forward into the future, instead of entrenching habits from the past.
