Lean Hiring- An Experience Report

In an earlier post we saw how organizations can create an ecosystem to attract top notch talent. But that is a long term vision which will take time to implement. How do we address more immediate hiring needs? In this post I will try to apply the learning from Lean and Agile principles and practices like Kanban to the process of hiring.

Let us first compare hiring with software development to find out similarities between the two

Similar Problems- Comparison Between Software Development and Hiring

• We are not sure about the outcome when we start: Software evolves as new information comes in. Similarly job requirements change to accommodate new needs or bar is lowered for reasons of non-availability and urgency. Sometimes a professional is internally transferred from another project and the need to hire simply goes away.
• Large Batch Sizes (A.K.A. Waterfall model of development): If you think of software development and hiring as workflows; often managers try to maximize utilization of resources at each step of the workflow by handing over work in large batch sizes. Its not unusual for an HR manager to source more resumes to improve the chances of finding the right candidate. This results in pile up of half done WIP before the bottleneck, which is wasteful. Theory Of Constraints  and Kanban address this problem by putting a WIP Limit on the size of the batch to be handed over at each step of the workflow. Using Kanban to manage hiring is not new.
•  Delayed Feedback : Large batch sizes also result in longer iterations and delayed feedback resulting in wasted cycles of recruiters and developers working on what they think is needed which often turns out to be different. We load the hiring managers by arranging many interviews without asking feedback about the interviews that have already happened. We need to ask,learn from the feedback and use that learning to improve the quality of candidates in subsequent cycles.
• Ambiguous requirements: Its not unusual to start developing a software product with some high level idea and a few whiteboard sketches. Similarly we often hear managers giving high level directives to hire “smart developers” or “kick-ass salesmen”.
• Dynamic marketplace: Both software product and hiring opportunities are not permanent. They go away with changes due to technology, competition, new ideas and realization.
• Waste resulting from unused code or resumes sourced: We often write more code than required. We often build more features thinking we are adding value. Similarly we often source too many resumes and interview too many candidates to improve our chances of finding the best match. Unused code and resumes represent the waste we should be attempting to minimize.
• Vague acceptance criteria and definition of done: Software development and hiring can go on in perpetual loops because the end states are not well defined. Both software development and hiring reach states where doing more work would cost more than the value you get out of it. That’s when you should stop. There is no definition of 100% completion. But the good part is you can start using the software even if all its features are not yet implemented. Similarly you can start using a team that is not yet completely staffed. Best value is derived by prioritizing must have features in software or must have skills while hiring.

Here are some useful tips to make hiring process quicker and more efficient.  In the spirit of continuous experimentation we tried adopting the proven and well tested lean and agile practices to streamline hiring in my company.

Agile and Lean Principles Applied to Hiring

In an earlier post we had seen how doing painful things more frequently reduces the pain. We tried to make the hiring process less painful by doing the following –

• Short iterations with quick feedback :  Long and “hyped up resumes” were consuming a lot of our recruiter’s and hiring manager’s time. We overcame this problem by using a 500 character micro-resume covering important facts including relevant skills, project experience, notice period and expected compensation. This semi-automatically generated micro-resume was made actionable with “detailed resume”, “accept”, “reject” and “call” links. Hiring managers were encouraged to view these on their mobile phones to provide quick feedback. The printed version of this micro resume also helped us populate the Kanban board.
• Using the learning from the feedback : The recruiters asked the hiring managers to give a good idea of “must have” and “good to have” skills. Based on this information the recruiters shortlisted top 3 candidates whose micro-resumes were shared with the hiring managers via email and text message. We waited for the hiring manager’s response before sharing any more micro-resumes. One such iteration ideally got over within a day. At the end of the day we either had a shortlist of selected candidates or valuable learning that improved the next iteration. Due to the “anytime anywhere” nature of mobile phones; iterations were quicker where the hiring manager was more mobile savvy.
• Small batch size: Instead of inundating the hiring manager with a number of resumes ; we put a limit of 3 as stated above– which forced the recruiters to do a lot of groundwork to select the top 3 resumes from a couple of dozen that would satisfy the selection criteria. Smaller batch size also forced the recruiter to do a lot of groundwork and research before ranking a candidate. As seen in an earlier post ; instead of relying only on the information in the applicant’s resume we leveraged additional information available in social media platforms such as LinkedIn, StackOverflow and GitHub to determine the ranks. This motivated the hiring managers to be more responsive as it reduced the number of pending cases needing their attention. They were also more willing to provide quick feedback to enable the recruiter to learn from it and provide better choice in the subsequent cycles. In fact in some cases the feedback came immediately as the hiring manager disagreed with the ranking given by the recruiter.
•  Prioritization of requirements: While understanding the requirements we decided to check the most difficult constraints first. In the diagram below ; you can see the order in which we evaluated the constraints. This made the job of selecting top 3 resumes out of all the resumes relatively easy. This Job requirements matrix was filled in presence of the hiring manager. Limited space provided forced the hiring manager to think really hard before writing down the requirements in the appropriate space provided.

• Planning /prioritizing interviews: We always had the most suitable candidate in the backlog the next to be interviewed. Often its hard to get suitable time slots from good candidates, and recruiters end up scheduling a less suitable candidate ahead of more suitable one. We made it clear to the recruiters that Its not necessary to use all the time made available by the interviewers. Interviewer’s time is a scarce resource which needs to be utilized more judiciously. Moreover if the interviewer rejects the candidate; learning from rejection of a stronger candidate is more valuable than that from rejection of a weaker one. We always played our best card.
• Timeboxing: Whatever happens one has to conclude the process at some point. Many times you don’t get exactly what you want but you must staff the position for business to carry on. Prioritizing and having a backup candidate in case the best candidate doesn’t show up are some of the precautionary measures one has to resort to under time pressure. Like a truly agile process we kept some of the unmet requirements for the next round of hiring and had a retrospective to formalize the learning from the previous round.
• WIP Limit: Having too many candidates interviewed  results in a longer hiring cycle. It also results in inefficient use of interviewer’s time. The number in bracket under each step (as shown in the diagram at the top) on the Kanban board is the WIP Limit. E.g. we can’t have more than 3 candidates waiting for preliminary interview. We“pulled” a candidate from shortlist only after one of the three interviews happened and we got the feedback. This enabled us to learn from the feedback and to apply that learning to decide the next candidate .