Main image of article Agile Culture and Recruiting - Hiring Geeks that Fit
Johanna.RothmanIn this series by organizational problem-solving expert Johanna Rothman, uncover the mystery behind agile project management.  What is it? How does it apply to your workplace each day? Why should you be looking for technology candidates with agile experience? See how separating decisions, prioritizing projects and tackling one thing at a time produces a smoother, more ‘agile’ process in tech. __________________________________________________________________________________  Part 4 in Dice's Agile Series In Part 1 - What is Agile, Anyway, we covered that agile is about a small cross-functional team of people working on valuable features, releasing often, and obtaining feedback. In Part 2 - How Tech Teams Manage Workload in Agile, we discussed how the tasks move across the board and how people commit to work. In Part 3 - What the Heck is Kanban, we explained how teams can limit their work in progress so they continue to make progress, all the time. Agile methods are very transparent and focus on optimizing the team’s progress. So now in Part 4 of our series, I want to illustrate that culture matters in agile and how it will affect your recruiting. Culture Matters in Agile No agile team is going to be the same. You, as the recruiter, are going to have to work closely with the hiring manager and understand what the hiring manager (or multiple hiring managers) need in the open positions. With any luck, the hiring manager and/or the team will analyze their needs and present you with a job analysis. But not all hiring managers know to do this. Too often, they present you with a shopping list of technical skills: some number of years experience of Java or Ruby or Unix. This is not sufficient for agile teams. tshaped1Remember, in agile teams, the people collaborate on the work. The work flows through the team. So, even though you recruit for a developer or a tester, or some other person, the people need to be flexible enough to do what it takes to move the feature forward. Sometimes we call these “T-Shaped people” or “Comb-Shaped People,” generalizing specialists. Depending on your perspective, this is harder or easier to recruit. How will you know if those technical skills will fit into your agile teams? Or, if the person with those technical skills will fit the culture of your agile team? You don’t. And, that’s a problem. Because you have to recruit someone who fits the team. Recruiting an Individual for a Team is Not Easy You need to know what matters for this team. You need to know how the people on this team work. You need to know what skills are needed by this team. The culture on this team matters. So, let’s take a look at how to analyze a job for technical person. This is part of the job analysis from my book, Hiring Geeks That Fit. You can find the templates are available on my website. Start with these questions:HiringGeeksThatFit.blog_
  • Who interacts with this person?
  • What roles does this person have in this job?
  • What level is the company willing to pay for?
  • What’s the management component?
  • What are the job's activities and deliverables?
  • What periodic deliverables are required?
These questions allow you to investigate this specific job. Are you looking for a more senior role or a more junior role? Someone who will coach others or be coached? Someone who might make presentations outside the team, or work entirely inside the team? Someone who will deliver software or tests or requirements or documentation? Something else? A combination of deliverables I haven’t mentioned? You want the hiring manager to be specific. There is no point in you f inding a terrific candidate who expects more than $150,000 when the hiring manager is looking for an entry-level position. That’s why you want to ask about the activities and deliverables before you ask about anything else. Now, Ask About The Person Now, it’s time to ask about the human being. We’ll talk about technical skills later. Agile teams tend to need people who are adaptable, highly collaborative, are willing to ask for help, have high initiative, have respect for one another, are willing to take small steps and ask for feedback, do something good enough for now, are adaptable, and are willing to work outside their expertise. I also like to find people with sufficient communication skills. Sufficient means something different in each organization. In some organizations, it means people talk to each other in real-time, making eye contact. That means their spoken words better be understandable. Your agile team might need something different. Not all agile teams will rank all of these in the same order. You will need to work with the hiring manager to rank these possible qualities, preferences, and non-technical skills as essential and desirable. Finally, It’s Time for Technical Skills Now that you understand the scope of the job and the kind of person the hiring manager requires, you can review the technical skills. Why do I ask about technical skills last? For several reasons:
  1. It’s easy for technical people to learn technical skills. Once you’ve learned a couple of computer languages, operating systems or tools, it’s quite easy to learn more. It’s also cheap to acquire those skills.
  2. It’s much harder to change behavior, and our personal qualities and preferences are a significant portion of our behaviors. Can we change our behaviors? Yes, but it’s much more difficult.
  3. People want a job that provides them an opportunity. Those opportunities are based on activities, not on technical skills. If you start thinking about the activities at the beginning, you will write a job ad that people want to respond to, and one that screens the right people in and the wrong people out. Otherwise, you have a generic job, one that everyone responds to.
The Four Areas of Technical Expertise Technical expertise is one of four areas:
  1. Functional skills
  2. Domain expertise
  3. Tools and technology
  4. Industry expertise
Let’s look at them one at a time. 1. Functional skills are what a candidate started to learn in school, and has continued to learn on the job. This is where you must be wary of one year of experience repeated several times. I look for people who have continued their learning in some way. We’ll talk more about this in the detail in Part 5 of our series. 2. Domain expertise is all about the product. Solution space is how well the candidate has learned the internals of the product. Problem space is how well the candidate understands the problem that the product solves. 3. Tools and technology expertise is simply how well the candidate knows your tools and technology. Remember, this is the easiest expertise to learn. 4. Industry expertise is the implicit requirements that we expect people in our industry to know. If you work in the pharmaceutical industry for a while, you know about the regulations, especially 21 CFR Part 11. If you work in banking, you know about it's respective regulations. If you work in telephony, you know about distributed systems as well as high-capacity, high-performance and high-reliability systems. Analyzing the Job Provides You a Picture of the Candidate Even if the hiring manager has analyzed the job, you can have a five-minute conversation with the manager and check his/her assumptions. With a complete picture of the candidate, you are ready to source. You will find someone who fits this culture, this agile team. In the fifth and final installment of our agile series, I'll share the five W's of agile recruiting.