Posts filed under 'job analysis'
Lisa has a nice post, How to Hire a Manager - A Time Tested Recipe. She’s close. I’m not so sure about the “humble” part, and I would add something like “advocates for team.”
But the piece Lisa missed is integrity. Without integrity, the other qualities, preferences, and non-technical skills are useless. To be fair, she implies it in her post. But I like making it explicit, because then I can ask questions such as, “Have you ever been in a position where the company wanted you to do something that went against your integrity? What happened?” If you want to ask about what the person learned, ask, “What did you learn from that experience?”
It’s possible that less seasoned managers have not been in an integrity-binding position, yet. I have yet to meet a manager who’s been managing for more than a couple of years who has not been in this position. When I’ve been in a position to hire managers (or to be hired as a manager), I want to know how the candidate has performed while in the integrity bind, or how my potential managers have performed.
June 30th, 2008
I led a 90-minute Hiring for an Agile Team workshop at AgileItx! this past week. I ask each team in the workshop to call out a candidate’s quality, preference, or non-technical skill that they look for in a team. One of the teams said, “teamwork.”
Well, teamwork means a lot of things to lots of people, and what this team meant was along the lines of “subordinating what a candidate wants for the good of the team” or “making sure the team meets its goals before attempting to meet my goals.” Those definitions are different to me. I prefer the second definition rather than the first.
But you can see, that even though these two definitions of teamwork are similar, they are not the same. And, if you only write down “teamwork” or “communication skills” or “team player”, even if you do perform a job analysis, you may not be in agreement with the rest of the hiring team as to what the skills are that you need.
When you analyze a job, avoid shorthand words. Spell out what you mean. If you mean “able to communicate across geographical distances and cultures and time zones verbally and in writing, without pissing off the people in East Nowhere,” say that. If you mean “able to present project status to senior management and help them understand it,” say that. Those are both examples of “communication skills,” but they are quite different communication skills.
The more specific you are when analyzing a job, the better your phone screen and interview questions are going to be. The more you’ll have interview team agreement on who is–and who is not–a great interview candidate.
June 29th, 2008
I emailed with a colleague today. He’s been looking for a position that shouldn’t be too hard to fill–but it is. Let’s assume the position is a development position. He interviewed a candidate. He’s not thrilled with the candidate; the candidate doesn’t have quite enough functional skill to do a good job. The interviewing team is neutral to positive, so he’s not alone with this lack of thrill. But his manager wants him to hire this candidate, for a slightly different position, as a release engineer.
I suggested he make it clear to his manager that hiring this candidate as a release engineer does not fill the development position. If the organization needs a release engineer, then interview and possibly hire the candidate for that job. But don’t fool yourselves into thinking you’ve covered the development job; you haven’t.
Make sure your manager understands your test strategy and your hiring strategy and your job analysis before you agree to this hire. Point out the risks, “Ok, we can hire the candidate, but we don’t get more development done. Want you to know that.”
Don’t settle for less than what you need in a candidate. I have several ideas about what to do when you can’t find someone. I’ll start a series about what to do when you can’t find a candidate. But don’t settle. You won’t get the work done that you need done.
October 24th, 2007
A bunch of my clients are having trouble filling their positions. They can’t find a bazillion years of Java or .Net or something else.
There is a relative candidate shortage, compared to the candidate glut of a few years ago. But of people start looking for attitude and general problem solving ability and ability to collaborate, they won’t need to look for technical skills. See what Anton says he’s looking for.
You can send someone to a class and they can learn a particular tool. If you then buddy that person with someone else, you’ve got a great coaching/mentoring relationship, and the new person will be up to speed quickly.
But if you don’t hire for the more intangible things, such as initiative or teamwork or problem solving, you won’t find the right people who can make a huge difference in your organization.
October 19th, 2007
I met a software developer recently, who studied physics as an undergrad. He’s now working in an IT organization on financial processing software.
He’s part of the interviewing team for his organization. They’re trying to hire 6-7 more developers before the end of the year. He told me, “I like to ask a question about physics, to see how smart the candidates are.” I asked him how many candidates he’d rejected due to his question. “Only 2 out of 5.”
Ouch. He rejected 2 potential candidates not because of an answer that’s relevant to the job, but to an answer that is irrelevant to the job.
Instead of asking a question that you think will get you information about how smart a candidate is, ask questions that really tell you what you need to know.
- “Tell me about a time you had to learn an application quickly. What did you do?”
- “Tell me about a time you had to bring someone else up to speed on a system. What did you do?”
- “Tell me about a time you got stuck on a problem. What did you do?”
All of these questions are much better than asking a candidate about physics, art history, Spanish, or anything else you took in school. And, they’re relevant to the job.
Don’t ask about physics. Ask about job-relevant experiences. You won’t be falsely rejecting potential candidates. And you won’t be opening yourself up to a lawsuit about discrimination. Ask about issues relevant to the job you have open now, not experiences you had in school.
October 3rd, 2007
Read Sidu’s Avoiding hell at work by spotting Dilbertian job descriptions.Sidu’s on target. That’s why I suggest you do a real job analysis, and write the ad and/or job description with other technical people. People who are not in the industry dumb down the descriptions and ads, and make them worthless for people to filter themselves in or out for your job.
August 24th, 2007
A behavioral audition is one where youw ant to see some specific candidate behaviors. Management auditions typically fall into this category. But especially if you’re hiring for an agile team, you might want to see how a candidate exhibits behaviors, such as coaching, feedback, how the person participates in a standup meeting or in a retrospective.If you want to see some specific behaviors, first, return to your job analysis. What are those essential technical and non-technical skills? Can you make a behavioral audition around those skills?You might want to see if the candidate will be a smooth addition to a team or a disruptive addition. In that case, you ask the candidate to do some work with one or more members of the team. You’ll ask the candidate how that work went, and you’ll need to debrief the members of your team (with open-ended questions) about what it was like to work with the candidate.Try a focused conversation for the debrief:
- What stood out for you?
- Where were you challenged?
- What insights do you have about this candidate?
- What do you recommend we do with this candidate?
Behavioral auditions are the most difficult to design. In my experience, you can see the behaviors if you use a technical audition, you are likely to see the behaviors you want to see. But to know what you want to see, you’ve got to do a job analysis.
Labels: audition, job analysis
July 30th, 2007
Jason Yip’s Hire squirrels instead of turkeys has a link to a discussion of Harvard’s hiring of Faust as the new president. Looks like Harvard got smart and thought about cultural fit, and those critical influencing and negotiation skills. (See my other post A Perfect Example of Insufficient Cultural Fit.)On the other hand, read Seth Godin’s Sheepwalking, where he describes people putting in time at their jobs, instead of being creative and solving problems.The first part of a smart hiring decision is to know what non-technical qualities, preferences, and skills you need. That’s why you need to think about the deliverables and activities the employee will perform on the job. (That’s why I put so much emphasis on the job analysis.) Technical skills are easy to train. Finding people who can solve problems and do the hard work you need them to do–that’s hard. And that’s what’s necessary for a smart hiring decision.
Labels: hiring decision, job analysis
February 13th, 2007
I’ve been traveling for the past three weeks (one more to go), and heard one manager say, “With good people, you can deliver almost anything.” He’s right. And it’s hard to define good people. Saying, “I’ll know one when I see one” is not enough. That’s shot-in-the-dark job analysis.
Job analysis, even if you don’t get it right the first time, is essential to knowing who’s a good person for the job. If you don’t know how to get started, here’s my job analysis template.
October 30th, 2006
The most common hiring strategy I’ve seen is when the hiring manager is looking for more people to do similar work to the work already in progress in the organization. For technical organizations, this means more developers/testers/writers/whomever with similar functional skills and the ability to easily learn the product domain.
When you have plenty of candidates, it’s ok to look at tools/technology skills. But if you don’t have lots of candidates, make sure you’re looking at how easy it is for people to apply their current functional skills to your tools/technology.
One common mistake I’ve seen, especially in smaller organizations growing quickly is to assume that you need all people at one level. If you consistently hire lots of senior people, you end up with a top-heavy organization. If you consistently hire lots of mid-level people, you end up with a bunch of people who are not able to progress to the top level (which might not be a big problem). If you hire only people with little or no experience, the manager has to take the time to coach them and help them grow technically and personally into responsible staff.
It’s critically important to do a job analysis for the first open position, and continue to re-evaluate the analysis as you hire more people.
April 28th, 2006
Previous Posts