How to hire for an agile team

Finding the best or the most suitable talent is always a hot topic. There are different approaches to the problem and, expectedly, results vary. The variability comes from different factors, and they all depend on the context. Expectedly, it becomes extremely important when it comes to hiring for agile teams as well.

Very often, the process does not involve anyone from the team. Very often, “screenings” are done by external recruitment agencies with little to no knowledge of neither the company nor the product the hiring is done for. And as a rule of thumb, people are hired based on “shopping lists” – assembled list of skills they are supposed to have to fit the need perfectly. Great! And wrong… Wrong, because the context is omitted, and context is everything.

A few days ago I ran across this well-designed, but extremely dangerous ad:

At first glance, it appears as a clever message from the agency that they can offer readily made experts for your business. However, the real message (which is quite possibly not intended one) is that people are interchangeable by titles. Further it might mean that you could order them at a discount price and bundle them in whatever dream team you want.

How horribly wrong is that idea! People are not cogs. Knowledge workers are not mechanically replaceable like parts of a machine. Effectiveness of a team comes from different factors, which are not simply listed in required skills area within job ad.

However, such an idea is deeply rooted in the job market, so most of the candidates behave accordingly. Recently I had a conversation with developer from the company I’ve been consulting, and it is one of the examples of how demand shapes the market. He demonstrated little to no interest in product other than from bare technical perspective. He dismissed domain knowledge as something not important for his work. His perception of teamwork was barely sharing the same office space and having each person being tasked using the same tools. And he had no intention of changing that. He simple created his response to the shopping list demand on the job postings that way. He simply shaped himself as a “Frontend Developer”.

Put on paper, he perfectly fitted described position need. However, he was not able to work as a part of product development team in the real sense of that definition and was not compatible with team culture.

But something that he said made me think. We were discussing responsibility and accountability and product involvement and importance of domain knowledge and close customer collaboration and… he concluded with – “nobody ever asked about those things in the interview and it will never help me get hired, thus it is not important.”

And he has several year of development experience…

The sad thing is that there is an ever-growing army of narrow-skilled experts like him, almost useless in product development team context. They can work as part of a group (which they are great for), but team work means more.

Another striking example is an alarm that I got from discussions with several CEOs/owners of differently-sized companies. They are disappointed by the attitude of developers asking to be strictly tasked instead of taking initiative and assume accountability. Some of the examples (however logically incorrect they might seem) are now notorious “Write me a story for that” and “Where is a task for that?” They, as well, share their concerns about how little developers are actually involved in the product and even domain.

Since I have been a part of hiring process in several companies in the past, I want to share some of the examples of what I see as valuable approach to selecting right candidates for your agile teams. This is the introductory post in the series and I will update it with the references as the examples are published.

Related articles:

Meanwhile, you might find beneficial a huge developer survey conducted by Stack Overflow. It provides great insights for those trying to understand developers on the market.