Five Tips to Hiring a Generalizing Specialist

We talk a lot in agile about generalizing specialists. Scott Ambler has a terrific essay on what a generalizing specialist is: Has one or more technical specialties… Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas (From Scott Ambler’s essay, http://www.agilemodeling.com/essays/generalizingSpecialists.htm) How do you hire one of these mythical people? First, they are not mythical. They are real. Second, you do a job analysis, just as you would for any job. Third, you would look at how they have acquired skills throughout their careers. What does this mean for the hiring manager and/or recruiter? If you search on keywords only, you will miss these people. They may not have all the keywords you want on a resume. That’s because they are generalizing specialists. You have to write a job description to entice these people to an opportunity. If you say things such as, “You will have worked at a place like <insert name of your favorite company here>” you may well miss great people. You are assuming a particular class of people. You have to change your assumptions about work history, school history, any kind of history. Again, the job description or ad has to be about an opportunity where people can learn and grow. You have to look at how they have learned in their resume. You have to look at their technical leadership roles. Yes, they will show you technical...

Creating a Succession Plan for Your Technical Team

We often think about a succession plan for managers. But, if you’re not thinking about a succession plan for your technical team, you’re falling prey to local shortages, and hiring the same old kinds of people. You’re not getting diverse people. That means you may not be able to create innovative, great products. It also means your people might be stuck. As soon as they can, they might leave. Sometimes, when I coach people on their hiring process, I discover that they have all one kind of person. Everyone has five years of experience in one domain. Or, everyone has fifteen years. Or, everyone has the same background. Everyone all looks alike. Everyone—even though they were hired at different times—has exactly the same demographics. This is not good. You want a mixture of experience on your team. You want some people with less experience and some people with more. I once had a client who, through their hiring practices and attrition, ended up with people who had no less than 25 years of experience. Every single person had at least 25 years of experience in this particular domain. It was very interesting introducing change to that organization, especially to the managers. The technical staff had no problem with change. But the managers? Oh boy. They had worked in a particular way for so long they had problems thinking in any other way. That was a problem. It’s not that less or more experience leads to easier or more difficult change. It’s that heterogeneity in a team tends leads to more innovation and more acceptance of change. So, what can...

Do You Ever Take Hiring Shortcuts?

There are many hiring traps and shortcuts, especially for technical people. Partially that’s because too few HR people know about technical people. But, partially that’s because too many technical people think, “I have a job, I must know what it takes to hire well.” In my most recent management myth, Management Myth 27: We Can Take Hiring Shortcuts, you can read about four hiring shortcuts I have encountered: hiring barrel-of-the-bottom candidates, supposed ‘rock stars’ or ‘ninjas,’ not paying people what they’re worth, or people who don’t fit with the team. The dialogue in this myth is paraphrased from a real conversation I had with one of my VP’s many years ago. He wanted to help me by hiring Kelly Temps to help with testing. He was  not a stupid man. He did not understand the value testers brought to the organization. I realized I had not done my job yet as a middle manager. Even though I’d only been in the organization for three months, I had not yet “sold” him on testing. Hiring shortcuts can kill your organizational capacity. If that is your hiring strategy for now, decide what you will do later. Read Hiring Geeks That Fit for more...

Hiring Trap: We Only Hire Rock Stars

Thanks to George Dinwiddie, who pointed me to the hashtag #FiveWordTechHorrors. I have been enjoying that stream.  I found “We Only Hire Rock Stars” at some point. I realized I had not written about a common hiring trap in a very long time. Yes, you should hire “stars.” They have to be stars who fit with the team. Rock stars who are experts who don’t fit with the team? They will not help you. They will splinter a team faster than you can say “lickety split.” It’s a subtle...

Hiring For an Agile Team: Feature Teams All Over the World

On Managing Product Development, I say that feature teams all over the world are fine. But, how do you hire these teams ? One way is to go to that country, hire the first person yourself, and have that person hire the rest. Another way is to hire someone here, wherever here is, and have that person relocate to the other country and have that person hire the rest of the team. Another way is if you have a friend or a colleague in another country—someone you have worked with before, and you hire that person. That person works out. Now, that person hires the rest of the team. Because you know the person you start the team with, you can hire for cultural fit. That person can maintain cultural fit. But which culture? I’ll discuss more about culture later. Culture is a big question. The real question is this: Do you have a dispersed team or feature teams? What Does Your Team Look Like? Is your team distributed or dispersed? It matters. For agile, I like distributed feature teams, where the team is all together in one place. You can have feature teams anywhere, as long as the team is together. Once the people are dispersed, it’s more difficult to find time to hire together, never mind do anything else together. I’m only focusing on hiring in this post. If you have read Hiring Geeks That Fit, you know I’m a fan of hiring as a team. The team has to work with this person. The team should hire the person. This is why it matters if the...

Hiring for an Agile Team: Create the Agile Interview

When I talk about interviewing an agile team, many people think, “Oh, we should pair!” and that’s it. But, many teams don’t pair regularly. If you pair in the interview and you don’t pair at work, you have an incongruent interview. That’s not helpful to you or your candidate. Instead, you want to create an interview that’s congruent with the way you work as an agile team right now. Not the way you want to work in the future. The way you work right now. You want to make the interview so compelling that the candidate asks for a tour. You don’t want to waste time on a tour, selling the candidate. Let your questions and audition sell the candidate on you. Create your Areas for Questions and Audition Evaluate your practices first. What do you do as an agile team? Do you pair? Do you do continuous integration? Do you ask each other for help? Do you coach and mentor each other? Do you collaborate? Do you stop when the customer/product owner says to stop? Do you get feedback often, either during the iteration or as part of your kanban? These are examples. I got carried away… Whatever you do, decide which areas are essential for questions and which area(s) you want to investigate by audition. Unless you are like Menlo Innovations, where everyone pairs all the time, don’t hire just by pairing. Instead, create an interview matrix. The matrix will tell you who will ask questions about which areas. You want a little overlap. Not much. Create behavior-description interview questions. Have a conversation with the candidate. The...