Yegor Bugayenko asked me to be a guest on his podcast to talk about Hiring Geeks That Fit. I gladly accepted and the podcast is now up: Shift-M/10. We spoke about many issues in hiring: Laundry list/shopping list problem in job descriptions Starting ...

Click here to read this mailing online.

Your email updates, powered by FeedBlitz

Here is a sample subscription for you. Click here to start your FREE subscription

  1. Shift-M Podcast Posted About Hiring
  2. Creating Agile HR, Part 4: Agile Sourcing
  3. Creating Agile HR, Part 3: Possible Agile Hiring Metrics
  4. Creating Agile HR, Part 2: A Flow for Agile Hiring
  5. Skills Gap? No, Wage Gap
  6. More Recent Articles

Shift-M Podcast Posted About Hiring

Yegor Bugayenko asked me to be a guest on his podcast to talk about Hiring Geeks That Fit. I gladly accepted and the podcast is now up: Shift-M/10.

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.


Creating Agile HR, Part 4: Agile Sourcing

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:

  • Create small safe-to-fail experiments with where to look for candidates
  • Experiment with the candidate funnel: how many candidates do you reject when?
  • Iterate on the job description, using feedback from the networking, candidate responses, and hiring manager concerns re the resumes
  • Further iterate on the job description once the hiring manager phone screens candidates.

You can read about how to do all of this in Hiring Geeks That Fit.

The posts so far:


Creating Agile HR, Part 3: Possible Agile Hiring Metrics

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.

Let’s think about the flow first. For agile hiring, we might want to think about the time it takes us to get a position approved. That’s the equivalent to getting an item on the Ready column.

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.

We have to know that we hired the right person, not just that we hired fast.

That means that I look for speed in opening the req, in the job analysis steps, a regular cadence in the interviewing, and speed in the offer and first day.

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:


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.

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.

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.


Skills Gap? No, Wage Gap

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:

  • Hire the great embedded people (at a reasonable level of experience), and train the entire team in agile. Use a buddy for the initial week or two weeks. (They work in flow.) In the training, work on their work, so they can practice working together. Encourage pairing, swarming, and mobbing, not just in the workshop, but for all the work.
  • Hire someone who has great depth of knowledge and experience in agile approaches, and teach them the ins and outs of embedded development with a buddy. I would encourage pairing, swarming, and mobbing for all the work. Maybe even do an in-house workshop or retrospective where people can discuss the risks they have seen and addressed in previous projects.
  • If the team needs one more person, can one person take on more responsibility for the team’s risks and backfill their position? I often discover that people are more capable and ready earlier than their managers believe they are.

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

Click here to safely unsubscribe from "HTP – Johanna Rothman, Management Consultant."
Click here to view mailing archives, here to change your preferences, or here to subscribePrivacy