Lightweight approach to hiring for agile teams


In article How to hire for an agile team I wrote that I will provide some examples of alternative hiring approaches. Here, I will discuss the lightweight approach, which builds on existing hiring procedures of the company. It does not change the form too much, but provides significant value.

At some point I got really frustrated and quite desperate with candidates that were being provided by the HR department of the company I worked for. Most of them actually met requirements from the job ad quite well. From the process standpoint and assigned KPIs, everything was perfect. All the bullets from the candidates’ checklists were checked, assignments done well, interviews revealed nothing extraordinary. Yet, repeatedly there were candidates failing to accept environments or be accepted by it. Of course, this was not out of proportion and sometimes even very subtle, but could have been done much, much better. Unfortunately for both sides, there were all kinds of managers pursuing their agenda and pushing for extra earnings in the company, so the issue was ignored. As far as agility and effectivity were concerned, they were outcasts. They costed money both from failed HR effort and missed opportunity for more effective work.

This might sound like a description of a failing company, but the reality is that most of the companies end up in similar nightmarish scenario.

The first thing that I wanted to see improved was to have existing teams interview future teammates. However, that was not possible at the time. There was not enough trust to actually let the teams participate. Rigid procedures were not helpful either. It seemed like a stalemate. HR was the owner of the process, so they wouldn’t let anyone interfere.

I had already been taking part in the interviews at that time, but I wanted to make a meaningful change. So I decided to try with the small gains. The first success was when HR manager actually let me break the rules and experiment with the exercise I came up with. I got 10 minutes of interview time to implement the experiment. So, what did I do?

I was less concerned with actual technical skills of the candidates – they all came well prepared to more or less pass the test. And being intelligent enough, they could pretty much dodge the nasty collaboration- and culture-related questions. What I wanted to learn, however, was their ability to approach and solve new problems effectively and to learn how they can collaborate with the customer and others within the team.

To do that, I devised a 10-minute exercise to get them out of their comfort zone and to null their technical strengths. I looked for something that wider audience is familiar with, simple, yet unrelated to actual technical skills of candidates. Even now, just by listing these properties, LEGO comes to my mind first. So, naturally, I wanted to ask them to build something using LEGOs. After a brief consideration and brainstormings with the team we came up with the following format of the exercise:

  •  Candidates were presented two photos:
    • one of Angry Birds’ Red
    • and another of pile of unsorted LEGO bricks
  •  Candidates got the following verbal instructions: “I (interviewer) am the client. You have the best references as a master LEGO builder and I want you to build this for me (present Angry Birds image). There is an upcoming exhibition in couple of weeks and I need this to be built by then. Here are all the materials you need (present LEGO pile image). Since I am the client, you can ask me everything you need to accomplish the task. I need to know whether you can do the work, when it will be done and how much it will cost.”
  •  Additional instructions for the candidates were that I wanted to know their thought process: what information they needed, what would be the first steps, what was their intended course of action? – so I asked them to describe it as they go.
  •  The assumption is that candidate is master LEGO builder, so their ability to assemble bricks in perfect way was a given

Basically, this is a modified “sell me a pen” approach.

I was nervous at first about the success of the approach. Essentially, this would determine success of the experiment. However, the response was extraordinary. Most of the seemingly perfect candidates hit the hard wall there and couldn’t continue. And it was not because they got confused. They needed tasks. They wanted to be managed. That is not the way agile, self-organized teams work.

Some of them couldn’t get past technical concerns (of which there were none, since it was not about writing code anymore).

So it was not about algorithms. It was not about logical problems. It was all about understanding what to build. For example, it was really surprising to see that only a few of the candidates came up on their own with a question about whether it was a flat LEGO representation of the picture or a full 3D figure they were supposed to build.

As a help for the stuck candidates, I had a generic question: “Ok, so what would be the first thing you would do?” Some jumped straight to implementation, without trying to understand the problem first. One even started quoting a code he would write (?!)

After a couple of sessions, enthusiasm among HR staff soared and in the subsequent interviews I got even more time with mandatory “come on, show him/her the image” nudge.

With more time, even more possibilities opened, so I expanded exercise with questions about teamwork and swarming.

In later stages I even got approval for team members to participate in interviews (but not the whole team though), which proved even more beneficial by having culture check even sooner.

What did we learn from it?

  • Instead of hiring hard tech skill, we started looking further for the skills that will benefit the team and the product much more
  • “shopping list” approach to hiring proved to be expensive; hiring candidates that could rise above technical concerns paid-off much quickly, since such individuals could be a part of self-organizing teams
  • involving team in hiring process provides much quicker feedback about actual cultural fit

So, if there is no full support for improvement you want to make, you could always ask for a short period of trust. If you fail, you will learn from the experiment. Everything that other side loses will be that short period of time (if they even consider it a loss).

In the next post I will present you a heavyweight approach to hiring for agile teams, using example of a company that experiments a lot while searching for more effective ways of working.