This is how we used Kanban techniques to visualize our hiring workflow, empower hiring process participants, and give executives a bird’s eye view on a short term project.
For many companies, hiring is something that happens in spurts rather than every day, week, or even month. At this very moment, many firms may be going through a hiring process, significantly staffing up as the recession appears to ease. If you are involved in this effort and are like me, you are probably banging your head against your desk as you try to keep track of all the job candidates and what phase of the hiring process they are in, while simultaneously trying to attend to your regular job.
In smaller businesses that have limited to no HR resources, this process can be a daunting endeavor. To hire for just 6 to 10 developer positions, there are often hundreds, if not more, applicants to sort through, review resumes, conduct phone and in-house interviews with, and offer jobs. Frequently, company participants have forgotten the steps and effort involved from the last time this process was enacted and therefore feel foolish as they stumble through it again. Executives and participants generally have little insight into what is going on and end up constantly emailing back and forth to check on the progress of the effort, to find out who was rejected and why, or to find out who has made it through and requires a formal offer. Interviewers must always report results back to a single point of contact (or more likely a single point of failure) who is tasked with keeping track of every candidate’s application “state.” Finally, anyone other than the single point of contact is usually clueless when a potential candidate calls in to check on the status of their application. After going through a full on hiring process, most people, other than seasoned HR professionals, are loathe to attempt it again.
To combat the organizational nightmare that is inherent in intensive short term one-off projects, a group at our company took a stab at visualizing our hiring process workflow on a Kanban board. Our CTO made the suggestion, as our company is currently in the process of making a heavy transition to Kanban (facilitated by Jim Benson’s amazing consultancy) and we all have “Kanban on the brain.” My first reaction to this suggestion was, “haha, thats a good one” but after a moment of contemplation, I realized this was truly a great idea. Our team used Kanban Tool (kanbantool.com), as we have multiple remote users, but this could just as easily be done on a traditional white board, with Agile Zen, or even Google Draw.
I worked with our office manager Judy, the CTO Jabe, and the developers responsible for interviewing candidates to come up with a Kanban board reflecting our ideal hiring workflow, accompanied by a document laying out roles and responsibilities associated with each column on the board. We held a 30 minute kickoff meeting to describe the process to all involved and get feedback and then we were off the races. Our company has a good amount of experience with “Agile” after working within Scrum parameters for the last 3 years so everyone understood that the Kanban board and hiring process might start off imperfectly but the goal would be to adapt and improve along the way.
This is the document which was shared with all hiring process participants, containing roles and responsibilities:
Here is a screen grab of our Kanban board (click to see full size):
If you read the Roles and responsibility document I linked to, you’ll understand the hiring process we proposed and some of the changes and suggestions for improvement that happened along the way. However, even if you didn’t read the document, the beauty of using a Kanban board is its self explanatory nature. This was especially apparent when few participants had questions during the kickoff meeting. In my experience, even the best laid plans are often confusing and require multiple explanations when presented in a list or outline format. Outlines and text just aren’t the most effective way for people to process or remember initiatives requiring multiple pieces to be pulled through multiple phases. Kanban made this easy.
When we created the board, we used color coding for the type of job the candidate was applying for and we implemented the following columns:
- Candidate Backlog (candidates who submitted resumes)
- Contact Candidate (candidate placed here when it was determined he/she was qualified from resume)
- Candidate Contacted (candidates who had been contacted)
- Phone Interview Scheduled (candidates who had a phone interview scheduled with a developer)
- Phone Interview (phone interview in progress between candidate and developer)
- Schedule in-house interview (candidates who passed phone interview phase and should be scheduled for in-house interview and test)
- In-House Interview scheduled (candidates who had in-house interview scheduled with product owner and developers)
- In-House Interview (in house interview and code test in progress between candidate, po’s and developers)
- Candidate Rejected (candidates who were rejected after phone or in-house interview *this column was later changed)
- Simon Interview (candidates who passed all interviews and would be called by COO for final discussion)
- Candidate for Offer (candidates who were receiving formal offer letter).
After some experience with the process, participants asked us to add the job type in actual text to each card (the color coding was considered a bit too confusing on its own). We also split the “Candidate Rejected” column into “Candidate Rejected – No Interview” and “Candidate Rejected – After Interview” and added a column for “Candidate On Hold.”
The nice thing about using something like Kanban Tool is the ability to add candidate information, such as a link to each candidates resume in Google Docs, to each Kanban card. This information is readily accessible when a card is clicked. This makes it easy for interviewers to find documents and information associated with each candidate in a timely and efficient manner.
There is also an area for interviewer comments so executives and anyone else can effortlessly check in on why a candidate was rejected or passed on to the next stage:
Finally, Kanban Tool records each step along the way, allowing us to know exactly who made which decision, in case we ever need to trackback (although this feature, along with comments, is just a perk of the tool we used – not something completely necessary to visualize the workflow).
Using Kanban to visualize this intense short term effort resulted in many positives compared to using traditional project management approaches. Here are some of the things we saw:
- Rather than relying on single point of contact for all information, participants and interested observers could get just about everything they needed from the board.
- Participants were empowered to make the hiring decisions themselves because they readily understood and could act on the goal. The Kanban board visually facilitates this type of understanding.
- Executives, who often worry about efforts which are extremely important to the company, were able to see the plan was being followed, the rate at which the process was progressing, and the status of each candidate at a glance. This meant less questions from above, and therefore smoother day to day operations.
- There was little confusion concerning the process at kickoff because of the visual nature of Kanban.
- Participants felt free to make change suggestions to improve the process on the fly. Those changes could be made and disseminated quickly. This is crucial to a short term project where oftentimes if change can’t be made extremely fast, it’s not worth making.
- We now have an easily accessible and quick to read “living” document of how this process should work for future reference.
- For some reason, this process just felt much more effortless than times in the past when I’ve gone through something like this. I believe this is because, by empowering all participants, a “team” mentality was fostered which led to cooperation and a culture of improvement centered around a short term process (unheard of!). This was good for everyone involved and good for the company.
One thing to note: Seasoned Kanban practitioners might wonder how we dealt with WIP. We did discuss WIP limits in the beginning but as this was for a hiring process and not development, we decided not to set any and to see what happened. The WIP for this process seemed to work itself out and stay low as each phone interviewer could only obviously handle one phone interview at a time, and each in-house interview group could also only interview one candidate at a time. It may also have been the superb scheduling abilities of our office manager but it never became an issue and there were very few bottlenecks, the worst being “phone tag” moments. This is not to say we would not have immediately imposed WIP limits if flow or end results were poor.
Finally, a word of warning: As with anything, someone still needs to “own” the process, watch the board, and make sure the gears keep turning. Our office manager Judy assumed this role. She made sure busy developers had the interviews scheduled on their calendar and if a responsible party let candidates stack up or sit too long in a column Judy would make sure to poke at them until they took action.
So that, in a nutshell, is how we used Kanban to keep ourselves sane and productive during a massive (for us) hiring effort with no HR staff. It would be interesting to see comments on how our process could be improved!