The team will have to work with the new hire. Shouldn’t the team do the hiring?
Imagine this scenario. You’ve transitioned to agile. You are past the first few months, and your team has settled into an even cadence. You manage your work in progress, whether you work in flow or iterations. Your features actually get to done and your product owner or customer is happy. You are managing your pre-agile technical debt.
Now, comes a shock to your happy team. David, one of your developers, is leaving. He’s not unhappy. But his wife has a unique opportunity with her job. They are transferring to the other coast. What do you do now? You don’t want to hire just anyone.
Tip #1: Start with Identifying Your Culture
Every team—agile or not—has a unique culture. Your first job is to identify your unique culture. To do that, first understand what culture is. Culture is made up of these three components:
What people can discuss
How people treat each other
What is rewarded
There is nothing right or wrong about culture. It just is. And while agile teams might be similar, every single agile team has a unique culture. Because every single team has their own stamp on how they make decisions, even in the context of the larger organization.
How do you discuss design and architectural decisions? That’s part of your culture. How do you discuss the issues of context switching or whether you should do more features or address the legacy technical debt? That’s part of your culture. Is your product owner/customer stronger or weaker than others in the organization? Do you have an agile project manager or Scrum Master? That’s part of your culture.
Do you have team rewards or individual rewards? I know, I’m spitting into the wind here, talking about team rewards. So few of you have team rewards. But at some point, more of you will have them.
Once you have identified your culture, you can say, “Here is our culture. This is what we want someone to fit into. We don’t need a perfect fit. We need someone who’s not too far off.”
Remember, we don’t often fire people because they don’t perform well. We fire people because they don’t fit our team norms.
Tip #2: Analyze the Job as a Team
It would be easy to use a generic job description that you have, or the job description from three years ago. But, I guarantee you that any job description from your pre-agile days is no longer useful. And any job description you haven’t updated in the past few months is suspect. So analyze the job. I have templates that can help you start.
When you analyze the job, you start with the person’s interactions and roles. In effect, you start with a user story for this person. The value this person brings is in his or her activities and deliverables. So, you want to consider the span of responsibility.
Do you need someone who can coach more junior members of the team? Or someone who is coachable? Do you need someone who can help the team think more strategically about where the product is going? Or someone who is happy to keep implementing by feature and refactoring to patterns? How about someone who wants to keep the testers happy? It really depends on your context, doesn’t it?
One of the big pieces of analyzing the job is to be able to differentiate the essential from the desirable in the analysis. If you don't do that, you will end up looking for a person you cannot afford.
Tip #3: Review Résumés as a Team
If you are large enough to have an HR department, you probably have an Applicant Tracking System, an ATS. Your HR department would love it if you used the ATS to review résumés and make decisions in the ATS, right? Don’t do it.
Use the ATS as a way to gather résumés. The ATS is an abomination upon the earth.
The ATS has made people exaggerate experience, load their résumés with useless keywords, and made it impossible to review résumés. Ask the hiring manager perform an initial screen of the resumes, throwing out the impossible resumes. Instead of using the ATS to review, print the résumés that remain. Instead of using the ATS, print the résumés. Yes. On paper. One copy for everyone in the room.
While you are recruiting, at the same time every morning, maybe right after your standups, have everyone read the résumés you received the day before. Have everyone sort the résumés into three piles for phone-screens: Yes, Maybe, and No.
When everyone is done reviewing the résumés, discuss who said Yes to which résumés, who said No, and who said Maybe, and why. The why is most important. After a couple of weeks of discussing why, you will all understand what you are looking for in a candidate. This is why it’s so important to work together and iterate on the analysis after you’ve phone-screened and interviewed some candidates.
Tip #4: Prepare to Interview as a Team
Just as software is a team activity, interviewing is a team activity. High performing software development teams are, for lack of a better word, intimate teams. You don’t want just anyone to join you. You need to know you can stand working with these people for hours every day, week in, week out.
Eliminate the Dirt-Bags
I don’t like working with rude people. So I organize the dirt-bag elimination phone-screen. That’s the phone screen where the HR person calls the candidate to set up the real phone screen. Is the candidate nice enough to the HR person? Or is the candidate rude? If the candidate can’t be bothered to be nice enough to the HR person to set up a real phone screen, that candidate gets crossed off the list.
That’s part of my culture, and might not be part of yours.
Assign a Primary Phone-Screen Interviewer
I do find it useful to use a primary phone screen interviewer, so only one person has to coordinate all the phone screens. Since I recommend you use a phone screen script and write down answers in a phone screen, I also recommend you use a manager for this.
Often, the manager will have the responsibility for new-hire paperwork, for extending the offer, for taking the lead on the hiring. The coordination may be easier for you if you do it this way.
Use an Interview Matrix
Know who is asking which questions. Everyone should take two areas to ask questions about. In a future article, I’ll provide you tips about questions to ask and questions not to ask. I like to use a matrix that includes the time of the interview and which areas each interviewer will ask questions about. I have a template for that, too.
Include an audition that fits your context. If you pair, by all means, pair with the candidate. But, if you don’t pair, please, don’t pair. That sets up an inaccurate expectation. Auditions are a huge topic. I’ve written more about them in Hiring Geeks That Fit, and have much more on my blog.
After a great interview, you want to make a decision as a team.
Tip #5: Decide as a Team
Deciding as a team, in a follow-up meeting, is a form of limited consensus. Since you will all have to work with this candidate, it makes sense for you to decide as a group whether you want this candidate. Not all managers understand how to use limited consensus, so here’s a way to make it work.
In a perfect world, no one would be brash and opinionated. Have you met me in person yet? What I lack in size, I make up for in volume. I can argue with anyone and often win—about just about anything. But we don’t want the loudest person winning when it comes to candidates. We want the person who will fit our team the best. That’s why we went through the culture activity first, so we could use it in the analysis and apply it to our résumé review and question development, and use it as a check on our decision-making.
In the follow-up meeting, we have several ways to see what people think. My first approach is to use thumbs: Everyone keeps their mouths shut, and uses thumb up to say, “Hire!” or thumb down to say, “No way!” or thumb sideways to say, “I’ll go along with the group.”
The key is for people to thumb vote while not saying anything. Once people have voted, now we can discuss and learn the reasons behind the thumbs.
Want More Tips?
These tips just skimmed the surface of hiring. If you want to read more, please visit my Hiring Technical People blog. And of course I’d love it if you’d buy my book Hiring Geeks That Fit. Stay tuned for my next article about questions to ask and not to ask. And yes, I’ll tackle the reasons why you should not ask why or how to move Mt Fuji. Seriously.
Johanna Rothman helps leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. She writes the Pragmatic Manager email newsletter and two blogs on www.jrothman.com. Please do go there, wander around and subscribe!