Hiring the Best Knowledge Workers, Techies & Nerds: Analyzing the Job

This chapter is from the book 

• Hiring Manager: “I need to hire a developer/tester/writer.”
• HR Rep: “Okay. What does that person do?”
• Hiring Manager: “Engineering . . . development . . . testing . . . writing, of course. A little bit of this, a little bit of that.”

Most technical staff and technical managers do a little bit of this and a little bit of that, but unfortunately, that’s not even close to a job description.

Performing a thorough job analysis is a fundamental component of the hiring process, and your analysis should help you define the requirements for the job. As a result of taking the time to analyze the job, you will discover criteria that you can use to create a job description. You won’t need to embarrass yourself by only being able to tell a recruiter you’re looking for “a little bit of this, a little bit of that.”

You will want to perform a thorough job analysis if any of the following conditions apply:

• You’ve never analyzed your open requisitions before in this organization.
• You’re starting up a group, after a reorganization.
• You need to change the general job descriptions of the people you’re managing.

If you’ve defined your hiring strategy according to the approach detailed in Chapter 1, “Developing Your Hiring Strategy,” you know the problems you want to solve. Now it’s time to define which kinds of people you need at what level to solve those problems. You may already have a high-level idea of what you want to see in potential candidates, but performing the job analysis will enable you to see what specific tasks a particular employee will need to be able to perform. In the sections that follow, I discuss job analysis in the context of designers, testers, writers, support staff, and project members in general, but I do not address jobs in management. If you’re hiring a technical manager, look at Chapter 14, “Hiring Technical Managers,” for how to analyze a manager’s job.

Let’s start with the high-level tasks you probably already have in your mind. Developers may design, implement, peer-review, unit-test, and debug. Testers may evaluate designs and perform black-, white-, or gray-box testing. Writers may develop new material or they may edit someone else’s written material. Support staff may answer calls and help customers by determining and fixing problems. It is also possible that the staff you will need may be required to perform different work altogether from the tasks I’ve listed. To enable you to identify what you want in a candidate, the job analysis must be more than just a description of the job’s functions. Your job analysis should identify the reasons you’re hiring someone for your particular culture and organization.

Before you start writing a job description, analyze the job in the context of your current team’s skills, experience, and personalities, so you know what to look for in a candidate. I use the following steps to analyze the job:

1. Define the job’s requirements, including defining the person’s interactions and the type of work he or she will perform.
2. Define both the essential and the desirable qualities, preferences, non-technical skills, and technical skills.
3. Define the required educational background and the desired level of technical experience.
4. Define the activities and deliverables, the outcomes of the work you want the employee to perform.¹
5. Define the factors that could eliminate a candidate from consideration.

Once I have filled in as much information as I can at each of the five steps, I then complete a job analysis worksheet (a sample is shown in Worksheet 2-1 presented a bit later in this chapter). The worksheet makes it easier for me to iterate on the analysis if necessary later on.

Aside from large changes, numerous small changes can sometimes affect your hiring strategy and job analysis. Use smaller changes (such as a change in release cycles or overall volume of work) to trigger a reassessment of your hiring strategy and job analyses. I tend to use the yearly budget process and yearly performance evaluations to review job analyses, especially when I expect to be hiring people during the coming year.²

If you’ve never analyzed a job before, but have existing job descriptions, try filling out Worksheet 2-3 at the end of this chapter, and then match your job descriptions with what you’ve written in the worksheet. If they don’t match, it’s time to reanalyze the positions you have open.

One caveat: The perfect person for the job probably does not exist, or, at the least, cannot be hired for what you’re willing to pay. That’s okay; we all have to live within constraints in a real world. That’s why analyzing the job is so critical. The analysis helps you decide which criteria are required and which are optional. You can then find a candidate whose qualities are close enough to the original criteria and choose what tradeoffs you will make in terms of position requirements, qualities, preferences, and skills.

Define the job’s requirements.

Begin analyzing the job by creating the high-level view of the tasks to be done and define the kind of person best suited to do those tasks. Think about other people with whom this person will work, and consider the conditions under which they will work together—in effect, the customers or clients of the employee.³ Identify the personal qualities and preferences of current staff members that enable them to get the work done properly—characteristics such as whether a person is talkative or quiet, or whether someone is innovative or prefers to follow strict guidelines. Define the specific tasks this newly hired person will do, the technical environment in which the person will work, and the kinds of deliverables the person will complete. If you also are looking for specific desirable experience—such as pharmaceutical company experience, recent college training, or the subcontracting experience a military contractor might have—list that on the job analysis sheet. Or, if this person may need specific talents and skills to complete the work in your time frame, list that detail as well. When you spend time analyzing the job at the start of the hiring process, your recruiting and screening efforts are more effective.

List the job requirements to include five things: (1) interactions, (2) functional roles, (3) role level, (4) management component, and (5) activities and deliverables.

I find that if I start by defining with whom the person will work, before I list the candidate’s deliverables, I’m more likely to develop a job description that I don’t need to revise after I’ve seen the first few candidates, wasting precious phone-screen and interview time. No matter how you start an analysis, don’t forget to include all the analysis components in your position definition.

This approach admittedly is a top–down approach, and may not be comfortable for you if you prefer to start with the details. If you prefer, try working from the inside out, starting with the role level, the role, and the interactions. Then, define the management component, activities, and deliverables. Don’t start with the activities and deliverables first; you’ll forget something crucial in the interactions, role, and level.

To define the requirements for candidates, use the following techniques:

First, define the expected interactions. Define with whom this person works. One way to think about the interactions is to consider who the person’s customers are, and who the suppliers are. To whom does this person deliver work product or information? Define the daily, weekly, and monthly team and personal interactions. I tend to use titles of people, not names here, so that my job analysis is clear even if the group experiences turnover. However, if you do use actual names, the people named may be willing to help you review the analysis. Write down how the person in this position will work with other people: cooperating, influencing, providing work direction, negotiating, or working as part of a team. Specify the frequency of the interactions.

Second, define the functional roles for the position. Sometimes, you only need to record “developer” or “tester” here. But if you have a writer who also fields calls, the position is a combination of roles. I like to think of functional activities (architecture, design, programming, planning, analysis, quality assurance, release engineering, integration, documentation, and testing, for example) when I define the roles this position requires. Then, go on to define how large a part each role plays in the position.

If you’re defining a job with multiple roles, spend enough time on this step to know which roles are most important, or how much time you want each role to take. People find it difficult to work when they have to spend time on two separate functions. If you’re looking for a support representative who will also test, a writer who will also support, or a manager who will also perform development, decide what percentage of time you think is appropriate for each function, based on the activities and deliverables you need from the position. Keep in mind that once you’ve hired someone, the percentage may change.

Third, define the position’s level. You may find it difficult to determine whether this is a senior- or junior-level position, especially if your organization does not have a formal, posted job ladder. I follow the guideline that the more experience and the broader the experience required, the more senior the position. When in doubt, look at the deliverables and activities, discussed below.

You might want the new person to change the balance of seniority in the group. If your group is top-heavy with senior people, you may want to start adding junior people who can be trained. You can make good use of a junior-level person even if the position is on a time-critical project that requires a lot of technical knowledge, simply by moving a current senior-level staff member to the new position and backfilling his or her current work with the new junior-level hire.

Fourth, define the position’s management component. Many technical people take on technical leadership roles at some point in each project. However, some positions are combinations of technical work and technical leadership. Or, the position may have elements of project management or people management. Decide now if this is a purely technical job.

When you define a management job, define the scope of the job. For example, is the scope strategic (requiring a person with the ability to plan an organization’s operations), operational (requiring someone with the ability to plan and oversee the daily work of the organization), or supervisory (requiring a person who has demonstrated administrative ability and who is task-oriented)? Then, define which functional area or areas are involved in the job. Analyzing a manager’s job is more difficult than analyzing a purely technical job. See Chapter 14, “Hiring Technical Managers,” for more information.

Fifth, define the position’s activities and deliverables. Most people start with this fifth task when writing a job description, but I caution against jumping in without having done the previous tasks. Although it is true that a developer develops, a tester tests, and a writer writes, and that for some jobs, the activities and deliverables are that easy to define, most technical positions require more than just a one-word functional description of activities and deliverables.⁴ The more specific you can make the deliverables, the better your job analysis will be. If you are hiring for specific work, be specific in the activities and deliverables, noting for example, “Complete the Big Project by Jan. 30,” or “Lead the architecture effort for ModuleX, completing the initial architecture by June 5.” The more specific your activities and deliverables are, the more people on your interview team can focus their questions.⁵

Developers may perform requirements elicitation, requirements analysis, model building, design, architecture, analysis of defects found, coding, debugging, unit-testing, and more—for a specific project.

Testers may perform test planning, test development, and defect report generation; they may gather and disseminate metrics reports about defects or performance, and more—for a specific project.

Writers may write documentation, edit, run tests, develop examples, develop tutorials, and more—for a specific project.

In addition to project work, each position has daily, weekly, monthly, and some yearly deliverables. When you consider deliverables, consider how you will measure the employee’s success. If you think about what success means in this position, you will be able to define the activities and deliverables more easily. Be as specific as you can, using completion dates, module names, product or project names, or people’s names. For example, by specifying “Mentor junior members of the tech. pub. group to design a new document for the BuyWrite project by December,” you have defined both activities and deliverables for the open writer position. Write the activities and deliverables as if you were writing a yearly list of goals and objectives for an already hired employee.

Some position’s deliverables are harder to define. If you need a technical coach or a facilitator, describe those services in terms of the benefit to the position’s customer. One VP of engineering enjoyed benefits he attributed to his agile-programming coach’s services: “He watched how people worked together. He looked for teams that weren’t clicking. He made them click in a way that made the project manager happy.” The VP also could have described the agile-programming coach’s activities and deliverables this way: “Monitor the team—daily. Look for problems the team has using the methodology and other obstacles. Remove any obstacles to the team’s success—daily.” Here, the position is described in terms of benefits to the team members and project manager.

I find that as I define activities and deliverables, I look repeatedly at and review the other parts of the analysis, specifically the roles and the level. Defining the level of seniority needed for whoever fills the position may help you judge the activities and deliverables more easily.

Table 2-1: Junior- and Senior-Level Activities and Deliverables.

Job Category	Activities and Deliverables Needed to Satisfy Job Requirements
	Junior Level	Senior Level
Systems Engineer	Analyzes current requirements, looking for ambiguity.	Develops requirements cooperatively with others; assesses requirements documents for their completeness, fit with the rest of the system, and for ambiguity.
Developer	Designs modules after the major portionof the design is complete. Writes and compiles code in accord withsome predetermined description. Arranges to have his or her own designsor code reviewed. Reviews peers' code. Uses configuration management systemto check code.	Moderates code inspections, drafts design specifications, drafts functional specifications, and designs large pieces of the system.
Tester	Develops test procedures. Runs tests and reports on tests. Gathers metrics. Automates pieces of test procedures. Attends reviews and inspections.	Designs test approach. Designs automated test procedures. Moderates reviews and inspections. Develops metrics reports.
Writer	Writes documentation.	Plans tech. pub. and book design. Plans on-line help design.
Support Staff	Takes information for each incident. Resolves incidents that don’t require looking at the code.	Resolves any incident. Manages customer expectations for fixes. Manages the fix process for urgent problems.
Release Engineer	Writes scripts. Creates builds.	Sets up the configuration management tool. Manages and anticipates storage needs.
Project Manager	Plans and organizes small projects. (Make sure you define what small means to you: four people and four months, fifteen people and eighteen months, or something else?) Performs basic risk identification.	Manages large-scale programs and systems, bringing project managers across the organization together to deliver an entire product, not just the technical part of the product. Negotiates with suppliers and customers.
Manager	Facilitates problem-solving. Performs strategic planning. Performs risk management.	Manages multiple groups. Coaches and mentors other managers.

I make the distinction regarding junior- or senior-level requirements when I determine how much the position is worth to the company. The more senior the position, the more it’s worth. For example, I’d expect to get a less-professional functional specification from a recent college graduate than I would expect from a senior architect. When I choose the level, I must be willing to pay for the work completed at that level.

If the company isn’t able to pay what you think the position is worth, then be clear on the deliverables you can expect from possible candidates. If you expect too much of your candidates without offering enough pay, you may never hire anyone. Candidates will go through with the interview, conclude that you are asking too much for too little pay, and decline your offer.

Once you’ve described the deliverables, you’re ready to look at the other necessary candidate characteristics.