"HTP – Johanna Rothman, Management Consultant" - 5 new articles
We spoke about many issues in hiring:
I had a blast and ranted/raved several times. In the last part about career ladder, I did mention the difference between boy parts and girl parts. I was not so mature. (I am a work in progress…) It’s still safe for work or the car.
Sourcing, how and where you recruit possible candidates is a great way to use small, safe-to-fail experiments. That’s because the recruiting landscape continues to change.
A little history: in the past, we read newspapers—on paper! Before the Civil Rights Act, employers advertised for “Men Wanted” and “Women Wanted.” (I don’t remember if it was women or ladies.) Those ads became the general help wanted ads we see today.
In the late 90’s, with the internet boom, Monster and other job boards started advertising electronically. Suddenly, a job ad could be large and all-encompassing because employers were no longer restricted to some number of inches of newspaper. That gave rise to specific job boards for specific kinds of jobs. (In Manage Your Job Search, I wrote about how to find the right kind of job board for you.)
With the advent of social media, hashtags and the ability to have some kind of a conversation started to change the networking landscape.
Sourcing is a function of who you know, your network, and how well you can funnel people into your candidate funnel. The more people you meet and can manage in your network, the more possibilities you have for finding the “right” candidate.
That means that sourcing is a great place to experiment. This suggested table from Hiring Geeks That Fit is one way to start seeing if this specific strategy works for you.
Sourcing cannot be just about the number of resumes received. It has to include the number of hires to know if the strategy worked. (That’s the lead time.)
One of the big problems with hiring and being hired is the idea of loose connections. It’s very tempting to only mine your network. If you use your current network, you are more likely to create an insular, and eventually mediocre, reinforcing culture.
When you use loose connections, you start to see alternative people, people who can bring new ideas into your product development.
How do you build loose connections? You go to professional meetings and meetups. You join the local agile groups and become visible. Maybe you even go to conferences, certainly local ones. You network.
This means that all your sourcing is an experiment. The “problem” is that sourcing is a lot like marketing. You know that parts of it work. You don’t know which parts. For me, that means tracking where I find candidates for the short-term and the longer term. The longer you are a hiring manager (or a recruiter), the easier it is to grow your network and learn where to find candidates. Then, when the social landscape changes, you learn to adapt to those changes.
This is why a general HR person is inadequate for sourcing technical people. Generalists cannot go to all the different professional meetings. They can’t know all the current hashtags. Most importantly, they cannot “focus” on hiring different people across the organization because they have other HR work to do. (Often, that work is more tactical and requires more time. Sourcing suffers.)
I’ve written about the costs of multitasking and lack of focus before. Any recruiter needs to decide which position is #1, #2, etc.
In Create Your Successful Agile Project, I have a chapter about workgroups and how they might apply agile approaches. I’ll touch on that in a future post. Here’s what an agile sourcing board might look like.
The “Technical positions” is what the specific recruiters might work on. I have swim lanes for Platform, Middleware, UI, Firmware and Hardware. You would change those lanes to be your areas of recruiting.
I’ve added WIP limits, but this particular board is past the limits. Often, that’s because a recruiter can look for several candidates at a time. I’m not sure where WIP limits make sense, except to discuss the open position with the hiring manager and team and decide how many positions to look for as a team. I do think it’s worthwhile to think about WIP limits and decide what to do about them.
The data I would collect here is the feedback from the resume review: does it affect the job description and where to source? The initial cycle time to get a candidate into the funnel might be longer than once the recruiter has some feedback. (That’s why time to hire is an inadequate metric. We need to know the cycle time of all the feedback loops that I mentioned in Part 3.)
BTW, I might recommend that the HR sourcing folks do a lean coffee daily or at some reasonable cadence to see what their issues are and how they can help each other. I do not recommend a standup for a meeting. That’s because their work is independent, not interdependent.
The agile parts:
You can read about how to do all of this in Hiring Geeks That Fit.
The posts so far:
One of the problems with agile hiring is this: what data do you collect?
Let me digress for a bit and talk about cycle time and lead time. This image explains cycle time and lead time for a cross-functional team. Everything starts in the Ready column and proceeds through the possible progression through development and test to Done. I have no WIP limits on this board because agile hiring would rarely (I can’t think of a time) have WIP limits.
Cycle time is the time from when the team starts to work on an item until the item is done. Lead time is the entire time the item spends on the Ready column until it’s delivered to the customer.
We might also want to think about all the prep: job analysis, description, and ad. That’s one piece of a cycle time. We also might want to look at sourcing in some way, another piece of cycle time. We definitely want to look at the cycle time in phone screens and interviews. And, we want the cycle time for how long it takes for us to generate an offer.
All of those cycle times create the lead time, the traditional HR metric of time to hire.
Here’s why lead time is insufficient: In agile hiring, the “team” changes. Approving a req requires HR and the hiring manager. The hiring manager with the team might work on the job analysis, etc, but sometimes the manager works alone. Sourcing requires another team. Phone screens and interviews are a collaborative effort between the manager, the team, and maybe an HR person. Offers and hiring is more of a manager possibly with an HR person.
I wanted to specify all the different cycle times, because randomly removing time in the process does not create a better candidate or hiring experience. (Just as removing testing does not create better features!)
Data should help us surface assumptions, review, and improve the process.
If you only look at the time to hire, the total lead time, you don’t see the possible wait states. There are possible wait states in the pre-phone screen states, and in the post-interview states.
In Hiring Geeks That Fit, I have several suggested metrics, and all of them involve finding the wait states. Here’s the table I suggested in Part 4 of the book:
You might not need these pieces of data. You might need something different. I do recommend you avoid one large piece of data, such as time to hire. That metric has too many pieces of the value stream as the only metric.
Time to hire is lead time, so you might also want to know that data. But, it’s not sufficient as the only metric.
With quantitative data and qualitative data about the candidates, you and your team—with HR, if that fits—can retrospect about the entire process.
Now, you have an agile approach to the hiring process, but we still have to deal with sourcing as part of hiring. That’s the next post.
The posts so far:
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.
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:
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.
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.
I keep hearing about the “Skills gap.” There is no skills gap. There is a gap between what employers want to pay and what people are willing to work for. I read an article this morning that prompted this post: Talk of a skills gap in the labor market is ‘an incredible cop out’
Let me phrase this a little more elegantly:
There is a gap of cheap and skilled labor.
If you are willing to pay for training, there are many people who would gladly work for you. If you are willing to pay a reasonable wage for people who already have the skills, there are many people who would gladly work for you. (This is one of the reasons older people have a tough time finding a job. Employers want their experience at a new person’s wage. I wrote about ageism already.)
If you want to hire people will scarce skills and pay them an insufficient wage, you might think there is a skills “gap.” It’s not a skills gap. It’s wage gap.
What is wrong with hiring for—dare I say it—cultural fit, where people can be a part of the team you want them to contribute to, and then training them.
Let me walk through a scenario I recently encountered at a client. The client wants to hire a developer with 10-12 years of experience in embedded products where they use agile approaches, and not pay more than $100k. That’s a tight wage for that much experience. The cilent can find people with embedded experience. Everyone and their brother thinks they are agile, so there are plenty of those people. However, when the client interviews candidates at that wage level, the client realizes the people don’t really have either experience.
Why? Because the people interviewing don’t have 10-12 years of experience. At that salary, he’s seeing people with much less embedded experience and much less agile experience.
What should the client do?
First, understand why there is a salary cap when the job seems to demand a higher salary. I often discover the higher managers want to hire someone cheaper because they don’t see the Cost of Delay when that person can’t deliver fast enough.
I suggested these alternatives:
Now that you see these three options, I bet you can see other options for yourself.
This client walked through the numbers. If he increased the wage, and paid another $20k for a one-week workshop where people worked together on the product, he thought he might be able to integrate someone with the embedded but not agile skills in a month. (One or two weeks to buddy/mob, one week of training, another week of buddy/mobbing.) The entire team would work together for a month. That would bring the Cost of Delay down for their project, and they could expect to see millions of revenue in three months, rather than nine months. Yes, by hiring the right person and providing training, the manager thought they could see revenue much faster.
The training and salary was a small percentage of anticipated revenue. I can’t report back yet because the project is still ongoing. However, they are going to a pilot with the embedded software six months early. (!!)
Consider what the right person in the role can provide your organization. Maybe think about cost of delay instead of wage cost and you might see more options. I have yet to see a skills gap. I almost always see a wage gap.
If you do think you see a skills gap, what skills are you willing to train, to get the “perfect” person and team?
More Recent Articles