Tripling an Engineering Team in Six Months - Part Four: Hiring (finally!)

In my current employment as Delivery Manager at a software company I oversee the design and development teams (aka 'Engineering') that are building a brand new property management software-as-a-service platform. In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'. This blog series is a summary of the lessons I learned from tripling an engineering team in six months.

Part Four: Hiring (Finally!)

If you haven't already please read:

Part Four: Hiring (finally) is where the rubber hits the road. In this article I will cover lessons learned, how we tracked our recruitment process, and how we implemented flexibililty in our approach to hiring.

But first, a word from our sponsors. No wait, I meant to say a little bit of my personal recruitment philosophy. This is the first lesson about the actual recruitment process…

Lesson One: Take Responsibility

In all recruitment, regardless of scale, the actual hiring manager must be the key driver. The person who will ultimately take responsibility for the individual and the team MUST be involved as much as possible.

For three weeks after the acquisition was finalised I did nothing but recruitment. Nothing. Some days I had 5 back-to-back interviews scheduled from 8am to 6pm. I ignored all other duties for this period in order to get the process up and running and set the bar for where I expected candidates to fit. My involvement was critical because in the end all of these people would be either reporting directly to me or indirectly through one of the new leadership positions. I was ultimately responsible.

After that initial burst of activity I was exhausted but I had set the process, and the rest of my team, up for success for the remainder of the recruitment drive. The benchmark was clearly set for quality (both technical and personal), our processes well defined, and I had demonstrated how to recruit to all of our newly promoted leaders. From then on we proceeded as a team, empowered to make decisions and trust we all had a common understanding, but I don't think it would have been as smooth if I hadn't nearly killed myself with exhaustion in those first few weeks.

Side note: I then went and enjoyed a nice two week holiday in Fiji which involved a fair bit of this:

My near-burnout experience was also a reminder that leads perfectly to the next lesson.

Lesson Two: Get Help

This could almost be lesson 1a. Whilst I think my hectic involvement in the early recruitment burst was crucial to success it was also a little detrimental to my health. I needed help.

I had already identified that we needed some full-time people focused on the early stage time-consuming tasks - churning through the noise of incoming applicants, sorting CVs, checking work rights, shortlisting, booking interviews, and so on. Right from the start I had wanted a full time technology specialist recruitment person.

And I was getting one but he just didn't start until after my holidays. That was one month after we had started so while there was no other way for me but to smash myself for those first few weeks it really highlighted the importance of getting help.

When engaging in any recruitment of this scale you need help. Here are the helpers we put in place:

In-house technology recruiter

This was the role I wanted right from the start. Someone to straddle HR and engineering skillsets. Someone who could do all the 'soft skills' of recruiting but also knew enough about engineering to explore technical concepts with our candidates.

This person took responsibility for placing ads, curating social network content, trawling for contacts, reviewing applications, conducting first phone call, selling the opportunity, and also was the common point of contact throughout a candidates applications.

Administrator

This role was all about making the recruitment job easier for me, my engineering leads, and the internal recruiter mentioned above. There responsibilities were organising interviews, booking meeting rooms, sending the candidate pack, collating CVs, ensuring the jira board was updated, and so on.

External recruiter

The external recruiter was a company we had partnered with before and we used them again here to get started quickly. They were the only recruitment company used and as such they were given the opportunity to fill our recruitment funnel with any of the top quality contacts they had. The also provided an initial pool of contractors that we used in order to help us ramp up while we hired permanent staff.

Bonus point: having this external company out there and talking to people helped generate buzz in the industry for what we were doing which in turn helped convince people to apply to join us.

Lesson Three: Well defined internal processes

As previous covered in Part Three: Setting up for Success) we had defined our recruitment process early. This gave everyone clarity on the process and a shared understanding of internal roles and responsibilities.

Overview of recruitment process

Overview of recruitment process

I wont rehash the recruitment process but I will highlight again how important it is to have this clearly defined and understood within the organisation. Don't leave assumptions undocumented or obvious steps unsaid. It is those mistakes that result in candidates 'falling through the cracks'.

Once you have a nicely defined recruitment process you need to think about things like tracking and maximum cycle times.

Tracking

We used a custom Jira board to track our recruitment tasks. We had a column for every step in our recruitment process and the core hiring team were reviewing and updating it daily if not hourly.

We used tags for roles, assigned people who were responsible for next steps, and used the Jira time reminders to keep on top of any candidate that had become 'stuck'. If a card hadn't moved from a column within a day then we had dropped the ball - not read CV, not called them, or not made a decision. That was unacceptable.

That last point is the perfect transition into the next one.

Define maximum cycle times

Define the maximum time you want each step of the recruitment process to take. I'm not talking about the actual interviews (if you've done a few before you should already know how long your interviews/assessments take). I'm talking about the maximum time you allow before moving a candidate along the process.

Our example:

  • Application review = Day 1
  • First Contact = Day 1
  • First Interview = Day 2-4
  • Second Interview = Day 5-7
  • Reference checks = Day 7-8
  • Offer = Day 9-10

So all up we aimed for a 2 week turn around, and ideally it would be less.

I'll be honest and say I don't actually have stats on what our average turnaround time was but anecdotally it felt fast. We moved fast and secured the good candidates within that two week plan. I could go dig up the actual stats but not having numbers doesn't bother me. The point of setting these targets was not to create a new metric or statistic but to ensure we kept on top of the process.

By knowing these numbers anyone could quickly look at the jira board and determine what should be actioned next by seeing which applicants had been 'stuck' the longest. If we had a candidate we liked and no-one had called yet then pick up that phone!

Lesson Four: Know where you are flexible

The last important lesson for the actual hiring part of the scaling process is to know where and when you can be flexible. It doesn't sound like much but it is important that everyone involved in the process is empowered to do something different when it makes sense.

Flexibility in the process will be different per company, team, project, and size of scaling. There is not a magic system I can write down here that applies to everyone. But I will provide some of the examples of flexibility we installed in our processes in order to make them more efficient.

Three examples of flexibility in the hiring process:

Initial programming exercises

Sometimes we used a few simple coding exercises, to be done at home at the applicant's leisure, as an extra screening tool. We understand doing this is not for everyone but by this time we had built a bit of buzz in the local industry so most people we asked were willing to spend 30 minutes doing these exercises.

Why did we use it? We used it when we had a good applicant but felt their CV/application raised question marks on their technical skill. We decided that a single engineer watching a video of someone coding was worth the potential of filtering out candidates who we'd have two engineers spending 90 minutes with. And we did manage to weed out a few applicants who weren't quite at the level we wanted at that point.

This is not a perfect solution and not something we use every time but definitely a valuable tool to have available.

Internal references straight to interview

This was a general rule of thumb: if people already working for us recommended an applicant then we would interview them. We trusted our people and, as previously mentioned, we had built a fantastic culture and team environment so we knew no-one wanted to jeopardise that. If someone was willing to put their recommendation forward then this person was worth getting in. These applicants had to go through the same process and were still expected to meet the same high bar we had set for everyone. We didn't hire them all but to me this was a no brainer.

Homework

As an alternative to the initial programming exercises (which were relatively simple) sometimes we gave 'homework' technical challenges as a final test for a candidate. This was generally done after the in-person technical interview and normally when we felt that the candidate had shown stress and nervousness during the interview.

We tried extremely hard to make everyone feel at ease during interviews but walking in to a technical interview with 2+ extremely smart engineers can be stressful. Some people handle the stress of the technical interview better than others but I didn't think it was fair to rule someone out based on this. They weren't going to be coding in an interview style every day so it's not always a valid read on their skill.

In these cases we would give them an opportunity to do a homework project. This was a coding sample, more relevant to their job, and generally aiming to take about 4 hours. It was a big ask but most candidates who had realised their nerves had gotten the better of them were very receptive to this opportunity.

It is important to note that the applicants still had to show a certain technical competence in the interview first. It wasn't a last chance for people who bombed the interview but more of an opportunity for someone we thought was probably good to convince us.

Result? We hired several people after the homework step and all have been great additions to the team.

The end (of Part 4)

There are dozens of more little tips and tricks I picked up along the way here but I wanted to keep this shorter than Homer's Odyssey. What I have presented here are the most important tips - the big wins or the quick wins - the things that either yield the biggest return or are the easiest to implement.

That wraps up Part Four: Hiring (finally!). We're nearing the end of this series. Next up is Part Five: After Hiring.

Below are the links to all posts in this series. You can sign up to email list to get alerted for new content and if you have any questions or want to get in touch you can email me or shout out on twitter.

Full series: Tripling an engineering team in six months