Making our recruitment process more agile — a 10-month retrospective

For any growing startup, recruitment is challenging, time-consuming, costly and risky. At Deezer, we had the chance to experience this growth: our engineering team has doubled in the last year, and we have many positions open for this year. That’s why we work closely with our dedicated technical recruitment team to improve how we engage with the developer community, and how we handle the recruitment process for our candidates.

Today, I would like to share our ongoing experiment on adopting Kanban methodology for our recruitment process.

This work was originally initiated with our technical recruitment team. Over the months, it’s being expanded to all our recruitments.

Where did we start?

Our initial state was not too different from what you can see at many companies. Recruitment team was using a classic Applicant Tracking System(3)/Talent acquisition tool to track applicants, the recruitment process was not harmonized between all our business units. On top of that, there was a lot of recurring meetings, spreadsheets, chat, and emails to help synchronize all involved people.

From an applicant point of view, a lot of them didn’t know what to expect when starting the process. The quality of feedback we gave to a specific candidate was too much dependent on which recruiter and the hiring manager were handling this position. Some open positions require an interview first, other starts by a technical exercise. The minimal number of interviews was inconsistent too. The candidates may wait for ages at one step without knowing when they will get an answer. Sometimes, few candidates were not called back when we know we will not pursue their application (1). Definitely not a great candidate experience.

When we work in such a competitive space, these major issues hold us back in assembling the right engineering team. That’s why recruitment and engineering teamed up to change the situation.

Applying Kanban for HR is a part of a series of initiatives to enhance the collaboration between our HR/Recruitment team and our engineering teams. If you want to learn more about these initiatives, tell us on the comments.

A need for change

Our recruitment team has identified some pain points in their daily activities. In June 2015, we set a time slot to discuss them and find something to improve the situation. We listed three top pain points:

• Have a real, explicit process: we needed a unique “canvas” for any applicant. That way, any Hiring Manager(2) know what to do, and when we really need his/her support. It also helps us explain the process upfront to any candidate, whenever it’s when applying for a job, or discussing with potential candidates at job fairs and tech events. It also helps report progress in a unique way for any open position,
• Get measurable metrics: We “knew” that some steps in the process were a source of most bottlenecks. Without measuring them, it’s hard to improve them,
• Better reporting: recruitment teams are one of the teams who may report to the most diverse quantity of profiles. Each job offer has a hiring manager, Business unit managers who regularly want to know the status of dozen of open positions, C-Level executives, and their direct managers. Each of them wants different info with a specific level of details and across a different number of open positions.

After a quick chat, we decided to try Kanban. However, before starting to put post-it on any walls, we’ve done two things:

• Send a formal request to HR Director: We wanted to build this experiment, however, this can be done only with full support from our hierarchy. We were about to change the way a team is operating, with (hopefully positive) side effects on candidate experience, team efficiency (during transition phase) and office decoration :),
• Map our current recruitment process: we needed to have the same vision of our recruitment process. We took 2 hours to map — with post-its — our current recruitment process and decide on which parts we wanted to change.

Moving to Kanban

Choosing Kanban over other agile methodologies was quite a no-brainer. The concept of sprints from Scrum is not really applicable to recruitment jobs: candidates (eg. work item) can appear at any time, we can’t really evaluate time, and we can’t ensure any application can be processed within a specific time-frame or sprint. In the other hand, Kanban fits well with these constraints, and few key concepts, like limiting number of in-progress tasks, seemed like a great solution to some of our issues.

To begin our experiment, we chose to get two different boards: a candidate board and a job offer board. The job offer board was here to get an overview of all opened jobs. One post-it equals to one open position. Each recruiter uses a different post-it color.

This job board has 7 columns:

• Assigned: An open position has been assigned to a recruiter,
• Brief: We start the process of opening this position with a brief between the hiring manager and the recruiter,
• Job Description Writing: Job description is underwriting or review. This may need a lot of back-and-forth between different services,
• Management Approval: This step represents the final top management approval, including base package and recruitment priority. When this step is completed, the financial, administrative and logistical roadblocks are — for most of them — handled,
• Job Desc Approval: we’re finishing the job description writing, ensure it’s coherent with our others job desc,
• Hunt: The position is advertised on our deezer.com/jobs page and in some other places. Our recruiters are actively looking for candidates,
• Hired!: We’ve found our best candidates, we’re waiting for her/his arrival.

This board was intended to be used when reporting to HR Director and Executives. It was also placed in a strategic place where any employee can see it.

Our second board, named “Candidate board”, was here to track each candidate through the recruitment process. We were not sure about which columns were needed, so we started to map out the different steps that follow a candidate through our process. We’ve done this on glass walls with an erasable pen. That way, we could test if we had the room for each column we want.

The candidate funnel can lost a huge number of candidate in the first steps, so we decided to start our board by the “Test Sent” column. Each open position comes with a technical test or challenge that must be done by any candidate. When the test is sent, the hiring process is really kicked-off. For the first iteration, we choose the following columns:

• Test sent: the exercise was sent to the candidate. We’re waiting for the completed project,
• Test received: the candidate sent us his/her project. It was sent to the hiring manager for review,
• *Test validated: the hiring manager — with assistance of his/her team — has validated the candidate’s project,
• 1st Interview: this column represents the 1st in-person interview slot. It’s subdivided into two columns: planned/done,
• 2nd Interview: this column represents the 2nd in-person interview slot. It’s not a mandatory steps for all our positions, This column is also subdivided into planned and done,
• Validation: We’re waiting for the validation of all the interviewers from the 1st and 2nd interview,
• Decision making: We’re discussing the opportunity between the hiring manager and the recruitment team to elect this candidate or not,
• Management approval: we’re waiting for the management to sign-off this hiring,
• Prop. Sent: we sent an offer letter to the candidate and waiting for his/her answer,
• Hired: the candidate has accepted our offer. It will be now handled to our HR department for contracts and onboarding,
• Rejected: Somewhere during the process, we’ve decided that the candidate is not ready of any of our open positions,
• Gave up: Somewhere during the process, the candidate canceled himself/herself the hiring process.

“Gave up” is one of the most important column, at several levels. When a recruiter engages in a conversation with a candidate, getting a “no” from a candidate — unexpected or not — can be emotionally challenging. This is event more disturbing when the recruiter has promoted the candidate internally. This gave up column helps the recruiter to move on this bad news, with the assurance that we will take care of this issue at a better time. Periodically -ideally every 4 to 6 weeks- we take a moment to parse all “gave up” notes. We try to find patterns that explains why candidates gave up, and how we can prevent that outcome, or make it happen as soon as possible. We also do the same job for “rejected” column. However there is no such emotional pressure compared to gave ups.

We spent a bit of time thinking about the post-it itself. First, we used a color code to differentiate candidates among the recruiters. Each recruiter was then able to quickly see her candidates. The candidate name was obviously the main info. Even if this board was placed in a limited access space, it was still accessible by a lot of employees. We made the choice to display only the first family name letter, to ensure the confidentiality of our candidates.

Upgrading our Kanban board

After few months of experimentation, we decided to reflect on our setup, and change a few things: it was our iteration #2.

The first thing we changed was removing “Decision making” and “approval” columns. In fact, almost no Post-It stayed in these columns.

The recruiter color code put a lot of pressure on them. Sometimes, a recruiter will not have any candidate in the process for few days, and it can be totally okay. He/she might be working on a recruiting event, on employer brand, or on other subjects. However, it was not clear when managers see a board without any note of your color. So, we reverted to same color notes for everyone.

For this 2nd iteration, we also decided to remove the step dates on each sticky note. Maintaining them up to date was time consuming, and we didn’t have a proper way to parse them. If we needed this info, we can find it in our ATS app.

With this new iteration, we’ve also adressed a physical issue with the Post-It. Some of them did not resist time. Recruiters needed to use scotch or Patafix for some of the sticky notes. After few days of research, I found the perfect replacement product: Magentic Notes from Tesla Amazing. Yes, these sticky notes neither use glue, nor paper! It’s a statically charged plastic film. Writing is as smooth and as resistant as if it was paper, and all the note surface adhere to almost any other surface (excluding screens and MacBook cases).

In the middle of this iteration, a big part of our recruitment team changed. Without prior experience about Kanban, and a little knowledge of agile methodologies, we’ve decided to setup a training session. The agenda was divided in two parts: introducing Kanban, and introducing how we adapted Kanban for our technical recruitments.

Our current iteration

We made two main changes with our current iteration. First, we finally get rid of our Job board. The info was redundant with our ATS(3) system.

The second update we made was on the candidate note template. In this third iteration, we’ve added the candidate origin in lieu of the steps dates we’ve removed after iteration #1. A candidate can come directly to us — via our Jobs website, on our LinkedIn page, or by meet us at various events and meetups. We can also use external resources to help us find great candidates. It’s important to know how a specific candidate was in touch to personalize the candidate experience.

We didn’t changed the columns of our candidate board between iteration #2 and iteration #3.

Where we moved away from Kanban ?

There is few core Kanban/agile concepts we decided not to follow. The first one was about Definition of Done. For so many reasons, we cannot be 100% strict about our recruitment process. Sometimes, we had opportunities that make sense to not follow our process. For example, a candidate is in the city only for few days — so we can interview him before the technical exercise step.

The other one is more open to debate: the Work In Progress (WIP) limit. We don’t have any limit on our columns. It’s quite difficult to ask a candidate for waiting before moving to the next step because we’ve reached a specific limit. The approach we choose is to look at the first columns in terms of volume, to get an insights of the future work: number of technical exercises sent drives the number of exercises we need to review, that in turn drives the number of interview we need to plan.

What’s next ?

As any agile methodology, this is still a work in progress. Our latest reorganization causes us some reporting issues. Our boards clearly communicates the current progress. However it’s still difficult to get precise metrics to communicate without spending some time reporting board info into another system. In the next few weeks, we will look at new ways to compute these metrics more easily.

The candidate experience still has room for improvement. We worked on this topic during our latest hackathon, and we’re evaluating how we can phase out these ideas.