Hire for a job, not for a headcount – Here is where you should probably start anything that you want to do, including building a team and hiring people: Understand what you are trying to achieve. As simple as it might sound, too often I see job descriptions being pointless as a result of not asking that question. Writing a job description is easy. Writing a job description that actually delivers value is harder.
Step 1: Understand what your goals are
It all starts with what you are trying to achieve. You might be recruiting someone to join a specific team: You should have a good idea of what your strategy is for the team, what its mission is. In fact, it should be coming to you from a higher level, and be aligned with the corporate strategy. For example, a CEO might decide that he or she needs his organization to have an IT function. He or she will chose someone that they think can run with the IT department. That person, in turn, will decide that the IT department needs development, QA and support groups. The support manager might create a Level 1 support team, and a Level 2 support team.
From the very top level of the company should trickle an orientation, a strategy or a vision. If you are not getting this, then you have a problem. If you don’t have clear goals, you should hold your management accountable to giving them to you. This is true at every level of the organization, for every job.
So ask yourself, what will the goal of that position be?
Step 2: Derive responsibilities
Responsibilities are the concrete tasks that someone will have to do in their job in order for the goal of the group or team to be fulfilled. When working on a goal, ask yourself “What are the tasks that I, or that my team will have to run in order to produce reliable and quality results in line with my goal?”
You should probably have no more than 5 or 6 of those. For example, the responsibility of our support person could be to
- Triage incoming incidents and requests as they come in
- Resolve incidents and requests within SLAs
- Relay user enhancement requests to the development group
- Provide training and guidance to new users and new team members
Step 3: Describe who can do that.
Now that you know what you expect that person to be doing, it is time to understand how that person should be. From each responsibility you should be able to derive abilities and skills that best describe someone that you know will be capable of running those responsibilities. In our example this might be:
- Goal orientation
- Problem solving abilities
- Ability to deal with pressure
- Familiarity with ITIL processes
- Knowledge of Perl or other scripting language
Note that those are at a different level – Abilities, skills, competencies can all be refined and understood further.
Step 4: Selecting people
The job description should include both the list of responsibilities and the list of abilities and skills, on top of the usual company description, benefit disclosure, etc.
Further, sourcing resume, screening them and interviewing people should all make use of this framework for selecting the right people. The discussions with the candidate as well as the deliberation regarding the fit of that person for the position should be using the framework. Too often I see people conducting “thumbs-up/down” interviews. They get into a room, ask various questions from “Talk about yourself” to “How many barbecues exist on the island of Manhattan”, but are still unable to understand the person to the degree that is required to weed out the bad and detect the good. I call those voodoo interviews and they are an indicator that the interviewing process is not taken seriously in the organization. There is much to be talked about on the matter.
Step 5: Taking it one step further
Since you now have a deep understanding of the role you are creating, and the qualities of the people that can run with those responsibilities, you can use this information for things like performance reviews. Rate your people explicitly against their responsibilities. I have seen everything from overall ratings (both opaque and useless), to generic frameworks built by HR departments with things like “Quality of work”, “Quantity of work”, “Team player”, etc. The goal of the performance review does not end with the rating itself! Here again there is much that can be said but that’s not the point of this post.
Like many things, hiring comes down to knowing what you are trying to achieve, and doing the things that make sense to get there. By understanding the what and the how, you’ll make the best who decisions.