Where's Charlie?!

[article]
Developing Your Hiring Strategy
Summary:
Are you inadvertently setting up a one-dimensional team? Managers regularly make statements to recruiters like, "I need another test engineer just like Charlie." Sometimes hiring people with very similar qualifications makes sense, but sometimes breaking the mold makes a better team.

"I need another test engineer, just like Charlie."

"I need another developer, just like Joe, Dan, or Sue."

Managers make these statements to recruiters all the time. Sometimes hiring people with very similar qualifications makes sense, but sometimes breaking the mold makes a better team. A hiring strategy can help you know when to look for more of the same, and when to break the mold.

When you create a hiring strategy, consider why you're building your team, and what you want to get from the team. I recently worked with a testing team where all  the testers were extremely capable and talented exploratory manual testers. These people found defects in the strangest places in the product. But these talented testers found it difficult to write down their test procedures. The test managers were concerned that the testers wouldn't be able to recreate the failures, so they requested that the testers create extremely detailed test scripts to document their testing.

The exploratory testers found this excruciating. These people use their senses and intuition to find defects in the product. Now they were asked to document something they couldn't even describe.

One of the hiring managers came to me and said, "JR, we need your help in putting together a get-well (improvement) plan for Charlie. He's wonderful at finding defects, but we can't get him to write anything down." Yet the company was looking for three more testers basically "just like Charlie." Their hiring plan was out of alignment with their personnel plan. I suggested that they stop looking for Charlie clones, and stop asking Charlie to do something he was not suited for. They didn't want to just get the testing work done faster, they wanted to get different, broader work done. One alternative was to augment Charlie with some test automation people-people who could write scripts and code to ystematically develop tests to walk through the product. Other alternatives included using capture-replay tools to record what Charlie did, and to pair Charlie up with another tester who could write the procedure as Charlie performed it.

So the test managers developed a hiring strategy by doing the following things:

  1. Listing all their projects. The managers listed projects using new technology in one column and projects that only used existing technologies in which the team had expertise in the other.
  2. Estimating how many of what kinds of people they would need for each project, and for how long. They thought about the deliverables they would need (test plans, test procedures, metrics), and they thought about the kinds of people they would need (planners, visionaries, catalysts, idea-a-minute generators).
  3. Estimating how many of the same people were needed for each project. How many Charlies did they need? If they only hired one automation expert, was that person going to be swamped the minute she walked in the door? The managers also tried to project out a couple of years to see what proportion of which kinds of people they would need.
  4. Identifying assumptions:
    • They wanted primarily permanent staff, with as few temporary staff as possible.
    • They wanted people to stick with a product for several releases, if possible. (Their current staff switched projects every month or so, thereby never increasing their detailed knowledge of the application.)
    • They wanted people to keep working at the company a long time, so they
      were willing to hire more junior people, train them, and create a job
      progression for them.
  5. Listing the deliverables they wanted from the entire test group, and which kinds of people would deliver which kinds of things.

Then the managers wrote job descriptions, developed the

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!