To deliver a continuously improving recruitment process that can scale and hire top talent.
Towards the middle of last summer our business had grown to twenty people and hiring was performed by one of two people. I had been responsible for hiring developers and followed a standard approach of reviewing CV’s and GitHub profiles before a phone interview and face-to-face interview.
Generally this process worked well but there was an obvious problems of a bus factor and scalability. When asked by colleagues what values I looked for I was able to respond but there was nothing documented. Simply put the process and opinions were in my head. It was clear that with pace the business was growing the status quo was not going to work and we need to scale recruitment.
Before starting to define a process my colleagues rightly pointed out that we needed to define what we valued in developers. We gathered together and used a whiteboard to write up the behaviours and skills that we were looking for in a developer. We are used to extracting user requirements in this way and a skilled facilitator was able to group common themes and draw an initial consensus.
What followed the workshop was an intense and passionate period of debate around the coffee machine and in slack channels. It was clear that people were passionate about what the team valued and this energy fuelled a fantastic debate. With surprising ease in a week or so the development team reached consensus.
Independently our design team conducted a similar exercise.
With a reference on what the company valued in place we progressed to defining a process to put candidates through. In essence we were looking to test coding skill, company fit and ability to teamwork. Whilst this was not surprising the way we tested these skills became a hot topic of debate.
Some examples of the questions we were asking were:
Further debate made it obvious there was no right answer and whilst the discussions were interesting we were not progressing. Embracing the idea that the process would be continuously improved we proceeded to try a couple of exercises with candidates. We found for example that a whiteboard problem with pseudo code was not successful. But we found other tasks were good for what we wanted to test.
We are lucky to have our Chairman Stephen Allott on call for advice. In the course of this process he shared a tried and tested recruitment process that had been used in the Management Consulting sphere. We took this process and trialled it to recruit a couple of client facing roles. We found it worked well for this role and the suggestion was made that we could roll this out across all of our positions.
Quite quickly we agreed that this was a poor idea. The value we had seen from teams owning and developing their own answers to the problem was greater than normalising a process from a top down perspective. Instead we made sure that teams were aware of some of the learning we had gained and in some cases these were incorporated by the teams. In some cases they were ignored entirely.
Perhaps the biggest achievement in my opinion is that the development and design teams are autonomous in developing and evolving their process. The goal is well understood and experimentation is encouraged to help quality improve with each iteration.
Looking back to the point where I was entirely responsible for recruiting developers this is liberating and exhilarating. Not only is the recruitment process better but it is evolving all the time as the teams learns from each candidate. Because we prioritised the goal over the process the teams are able to innovate continuously and find out quickly what works and what doesn’t.
In designing a recruitment process we thought we were tackling a pressing business problem. In working through the problem we discovered that the work we were doing was far more valuable. By defining our values we were able to be open as a group and through some vigorous discussions we came to a strong sense of our identity and what we value.
In the spirit of Kaizen anyone in the team is welcome to implement improvements and we are even seeking feedback from candidates passing through the process. It is hugely evident that by any measure what we have achieved is better than a single person thinking they have the answers to everything.
We have a stronger culture, a scalable recruitment process and a real belief that our recruitment will continuously improve.
Have an update or suggestion for this article? You can edit it here and send me a pull request.
Linux and Unix watch command tutorial with examples
Tutorial on using watch, a UNIX and Linux command for executing a program periodically and showing a fullscreen output. Examples of watching a file download, a network interface come up, and showing the five most CPU intensive processes.
Build your own Vim statusline
Statuslines in Vim are not hard to create. Making your own means one less dependency in your life.
Custom Vim Bindings in tmux 2.4
tmux 2.4 made a significant change to key bindings. Here is how to support custom keybindings for versions before and after tmux 2.4