Posts filed under 'job analysis'
Maybe you have a job or two open. You’re reluctant to pay more than you have to for a given position. I understand that employers want to get the biggest bang for their employment buck.
I once consulted for an organization who had deliberately hired from the “bottom of the barrel.” (That was their phrase.) And, oh my goodness, they got less than what they paid for.
Getting to a release was a nightmare. And, because many of these folks were on H-1B visas, the people were desperate to keep their jobs. They would agree, as in say yes, to anything, because it meant they could stay here legally and keep working.
When the mix of work changed from commodity (keep the system going), to innovation (the market is changing, quick we need to change what we do), the technical staff was ill-prepared to deal with the changes.
Now, you don’t have to go outside the US to find not-highly-competent people. They exist here. We don’t need to import them. But the point is, the management in this organization had deliberately hired people they thought would be easily cowed, would be virtual slaves, and could do the minimum work for minimum pay.
Do a job analysis first, and know: what kind of hiring are you doing? Highly paid people can be competent for you–and they can be incompetent for you. You need to look at the environment in which people work, look at the problem, to find people who can learn the problem space and the solution space, and who can get along with others.
Don’t just look for the cheapest people. Look for the people who can do the work. Think about what you are hiring for, and pay for that expertise.
Tweet This Post
March 16th, 2010
I’ve been reviewing job descriptions from clients that are a laundry list of tools. Or, that ask for “significant experience” with a particular technology.
No, no, no. People are not tools. They are human beings who have specific qualities, preferences, and technical and non-technical skills.
When you think about those personal qualities, think about these questions:
- With whom does this person work?
- What kind of deliverables does this person have in the short term and the long term?
- What kinds of interpersonal skills does this person need to do their job well?
Take a look at the job analysis template to see more questions. Now you’re ready to think about technical skills.
Here’s how I categorize technical skills: functional skills, subject matter domain expertise (problem-space and solution-space), tools and technology, and industry skills. Of these four areas, functional skills–how good a developer, tester, architect, designer, etc the person is, and subject matter domain expertise–how quickly the person can learn the internals of your system, matter the most. Most people can learn new tools relatively quickly. But it takes much longer to learn how to test first, or use combinatorial testing, or see the whole picture and what can go wrong, and so on. Functional skills require experience, and more than the same year of experience again and again.
When you think about the people you need, think hard about those technical skills, and which skills you really need. Tools, and familiarity with a particular tool may not be as important as the ability to work in small chunks and finish things. Or to explore the product to find really bad defects. Or to see how the system flows–or doesn’t–together.
People are not tools. Look for people, not tools.
Tweet This Post
October 23rd, 2009
It’s now a hiring manager’s market. That means hiring managers can be picky and try to find just the right person for the open req. But, it also means that many applicants exist for each open req, and all of those people are applying for your job. How does a hiring manager find the right person?
First, realize there are any number of “right” people, and the first thing is to eliminate the wrong people. That means it’s even more important to do a job analysis. Once you have an analysis, you can see what’s essential for this job and what’s merely desirable.
Now, as you review resumes, you can say no to these people:
- People who don’t follow your rules for how you want to see the resume. If you want a doc file or a pdf or a text or in email, be specific about what you want. Anyone who doesn’t send you what you want is someone you don’t need to look at.
- Anyone who doesn’t fulfill all of your essential qualities, preferences, non-technical skills.
- Anyone who doesn’t have a minimum technical skill set that makes sense for your job
- Anyone who doesn’t have experience working the way you do. If you’re agile, you don’t have to look at someone whose projects for the last 10 years were serial lifecycle and were late.
Take a look at Tips for Reviewing Resumes for more ideas.
As I review resumes, I have three piles: yes, no, maybe. If you have a lot of resumes, many of them should now be in your “yes” and “maybe” piles. Now it’s time for phone screens. I’ll talk more about that tomorrow.
P.S. the job analysis link link was broken and is now ficed. If you’d like to see all the templates, click here for the templates page.
Tweet This Post
April 21st, 2009
I taught my “Hiring for Agile Teams” workshop at ADP today, and finally have words for something I’ve seen for a while. When I ask people to describe qualities, preferences, and non-technical skills, they say things like “easy-going” or “intuitive” or something else that describes behavior. Since I love behavior-description questions, you’d think this would be perfect, right? Nope. They’re not describing abilities, which is the key.
To change “easy-going” into abilities, I asked what easy-going looked like. The person said, “Relaxed in the interview.” I asked if the person would just interview or do other work. “Do other work.” We went back and forth for a bit. So then I asked “Would this be more accurate: able to keep his or her head in the midst of chaos?” Yes, that was it.
That’s different than easy-going. It’s something specific to the organization (which is good), and you can ask for examples in behavior-description questions.
So if you see adjectives, think about the deliverables and activities the candidate will have to do. Then see how to describe that in terms of abilities. You’ll have a better description and be able to ask better questions.
Tweet This Post
November 11th, 2008
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.
Tweet This Post
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.
Tweet This Post
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.
Tweet This Post
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.
Tweet This Post
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.
Tweet This Post
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.
Tweet This Post
August 24th, 2007
Previous Posts