Quantcast
Viewing all articles
Browse latest Browse all 10

Creating Agile HR, Part 2: A Flow for Agile Hiring

This is part of an Agile HR series. The previous post is Creating Agile HR, Part 1: What HR Does

This post is about creating a flow for agile hiring.

Why flow? Very few people hire continuously. That means resumes don't arrive at the every day, and certainly not at the same pace of arrival—or even a dependable arrival pace.

Resumes ebb and flow into the organization. That means a flow-based approach to hiring reflects everyone's reality better than an iteration-based approach.

Image may be NSFW.
Clik here to view.
This is a possible board (not necessarily your board) for an agile hiring flow.

You start with Positions Approved. (I assume the need for a new req is a result of some other process.)

Once you have a new req, someone (I prefer a team) creates a job analysis and then writes the job description. It's possible that person/team also writes a job ad. That's why there are three columns before the Sourcing column.

Sourcing needs its own flow, so the output of that column is on this board, but not the entire flow.

Once the Sourcing activities provide candidates, there are people in the Ready to Phone Screen column.

The Candidates in Interviews might reflect the phone screen and in-person interviews. At some point, with any luck, a candidate passes onto an offer. Then someone extends the offer and the person is hired.

Now, here is a possible list of states where people other than HR should be involved:

  • The job analysis. HR is not going to work with any of these candidates. Taking 30-45 minutes and creating a job analysis with a team is time well spent.
  • Sourcing might have a component from people in the team. Imagine if you met a team member at a meetup and they were excited about their job, and then they said, “We're hiring. Want me to bring in your resume?”
  • Phone screens. I happen to like the dirtbag phone screen first (possibly from HR) and only if that fits your culture. I like the hiring manager or people on the team to do the actual phone screen. HR does not have enough understanding of the work to conduct an effective phone screen.
  • Interviewing is a team-centric process. Yes, HR needs to be involved. But they cannot know if a candidate will fit with the team because they are not on the team. (Same thing for the manager. Involve the manager, but any team needs to decide about a candidate.) Someone—either HR or the manager—does need to create and shepherd the interview process. I like an interview matrix so everyone knows what they should ask about.
  • An offer is a legal document, so someone with fiduciary responsibility creates and extends the offer. I often find that the hiring manager works with HR to create a reasonable offer and then the manager extends the offer.

Notice that the team and the hiring manager effectively take the req, do their magic keeping HR in the loop until it's time to create an offer.

Why is this so important in an agile team? Because the more the team is agile, the more the team needs to define the interpersonal and technical skills they need and to assess how well a given candidate meets those needs.

When I've worked in this kind of a flow, we, the hiring managers, had a brief huddle—not a real standup—every morning with the hiring managers and HR. We discussed who had finished their phone screens, who had not, and where the newest candidates came from. Every so often, we discussed where to get more candidates. We spent about 5 minutes in this meeting. I thought of this meeting more as a reflection than as a standup. We had independent work, not interdependent. We did not need to recommit to each other. However, we did need to know if two managers wanted the same candidate.

Often, we segued into a resume-review meeting. We all read all the resumes (on paper). We did a yes/no/maybe/for-someone-else classification. Yes/no/maybe was for each of us. For-someone-else was a prompt that we saw something a different hiring manager might like. We then discussed the for someone else resumes. If we had questions, we might discuss the maybe or nos.

Image may be NSFW.
Clik here to view.
The maybe or no resume was feedback to the recruiter (internal or external). This allowed us double loop learning in the resume review meeting.

We all needed to check our assumptions. The semi-public resume review allowed us to do that. (We should have done retrospectives back then, but I wasn't smart enough to know. I am now.)

You might not like the specific board above. You might even want to separate what HR does (initiate paperwork, maybe provide feedback to managers on job descriptions or ads, and initiate sourcing) from what the manager leads (job analysis, interview leading, and initiating an offer) from what the team does (phone screens and in-person interviews).

My next post will be about agile HR metrics. Time to hire is interesting and not sufficient.

The post Creating Agile HR, Part 2: A Flow for Agile Hiring appeared first on .


Viewing all articles
Browse latest Browse all 10

Trending Articles