How to Recruit the Living

No Zombie Want AdsThis is the second of a series of four posts based on my interview for the Conscious Software Development Telesummit, conducted by Michael Smith, The Zombie Apocalypse is Not an HR Product: How to Recruit, Hire, Retain, and Develop the Living.

Most organizations are seeing a talent shortage. Recruiting people with the right skills and experience, at the right point in their careers, who will fit in the existing culture is one of the biggest challenges facing the IT leadership team. But how we recruit reflects the character of our organization, and we usually won’t get a second chance to make a good impression.

What are these odd-looking job descriptions we keep seeing on job boards?

Most applicant tracking systems include various parts of job descriptions and other details describing the work that the employees do, sourced from the HR system. When a requisition for a new hire is processed, a description of the job is built from those pieces. The less often that a particular position is recruited, the less likely that the recruiter will understand what the work will consist of, and the more likely that those pieces will be assembled in meaning-free combinations. Recruiting software maker iCIMS recently conducted a survey of both hiring managers and recruiters that confirmed the lack of communication and understanding between them.

The hiring manager should ensure that the public-facing description of the position is meaningful and accurate. For example, don’t ask for five years of experience in a new technology, and don’t ask for weird combinations. Make sure that the level for the position, e.g. sole contributor, manager, director, and so on, is correct and that the description of the work is appropriate for that level.

Learning From Bad Examples

I recently collected three samples from a job board. They weren’t specially selected to prove any points; just random requisitions. Each of them included examples of very common errors that should be easy to spot and correct, if anyone bothers to look.

Example: Requisition for programmer analyst. “Key Skills: Knowledge of C, C++, Java, ASP, .NET, C#, VB.NET, PHP, COBOL, ColdFusion, Classic ASP, VB6, VBScript, JavaScript/Ajax, JSP, Python, PL/SQL, T-SQL, and XML/HTML.” And a Secret clearance. Seriously? “Other skills: Basic programming skills.” In that case, what did you mean by knowledge of all those technologies?

Ensure you identify must-have and nice-to-have skills and experience, as such. Not everything is a key skill! I’m not sure what the people who posted this job expect, but it plainly is not going to attract people who have deep knowledge and experience in any of those technologies, let alone all of them.

Example: “QA Project/Test Manager. This is a Director-level role.” Then they list the requirements. First requirement: “Responsible for Tracking Requirements Tasks Start and End Dates.” Tracking dates? This is a director-level position?

Don’t mismatch duties with titles, or you’ll drive qualified people away. In addition, your company will look clueless. The biggest challenge most job-seekers have is understanding whether they are qualified or possibly over-qualified for a position. When you send this sort of mixed message, the highly qualified people move on to the next job requisition, and those with nothing to lose and time on their hands apply for the job.

Example: “Project manager or project coordinator.” Looking at the description, they want extensive business skills and management experience, so why ask for a coordinator? It drives away the experienced people, who think it will pay like an entry level position.

Make it clear what you want in the title. Think SEO! After all, the applicant is finding your requisition through search engines. Be selective about the terms you use and how you use them. Many of the buzz words, abbreviations, and credentials are misused in these job postings. Don’t give your potential applicant the impression that your organization doesn’t get it, or you’ll only attract the ones who don’t get it, either.

How do they determine who is actually considered for a position?

Because requisitions are exposed to the world, some draw literally thousands of applications. Many of these applicants are only marginally qualified, making it hard to find those you actually want to consider. Consequently, modern applicant tracking systems score the applicants, based on the criteria provided by the hiring manager, in order to get the pile down to a manageable few. The recruiter doesn’t know the difference between PL/SQL and T-SQL, and you shouldn’t try to explain it. Managers who don’t take the time to provide the right filters risk eliminating applicants they might actually want to consider. Specify whether you want to filter out or require certain combinations. Like any other system, you have to use it the way it’s designed in order to get the best results.

The Hiring Manager’s Responsibility

As the hiring manager, you need to look at the requisition posted on your organization’s job board, and ask yourself three questions:

  • Would I have applied for this position, a few years ago?
  • Will the people I want to work with apply for this job?
  • Will I want to interview the people who apply for this job?

If you hesitate to say “Yes” to any of them, you need to intervene, immediately. Most of the people actively looking for jobs have alerts saved on the aggregator boards, like Indeed, SimplyHired, or CareerJet. If you post junk, it will quickly get an audience, and you may not get a second chance to make that first impression.

In Part Three, How to Retain the Living, we’ll consider what is required to on-board and retain the employees you’ve recruited and hired.

Waterfall to Agile: New eBook Available

Waterfall to AgileThe good folks at AtTask have released another of their eBooks. It’s called, “Waterfall to Agile: Making the Transition to Agile or a Mixed Methodology Approach.” Twenty Agile and project management practitioners and authors contributed, including myself. It’s a wide-ranging collection of essays, addressing topics from selecting Agile methods, to implementing them, to making Agile methods the new normal. You can download it for free, here.

After you’ve had a chance to read it, leave a comment with a brief review.

New PM Articles for the Week of December 1 – 7

Just OverheadNew project management articles published on the web during the week of December 1 – 7. We give you a high-level view so you can read what interests you. Recommended:

PM Best Practices

  • Dominika Chambon provides the “how-to” for preventing scope creep and other profitability failure modes on a fixed-price project.
  • Glen Alleman puts systems engineering the in the enterprise IT domain into context, with examples of capabilities that drive the effort.
  • Kathleen O’Connor explore the difference between a project and a strategic initiative.
  • Michael Lopp on why so many software bugs are discovered in the wild, rather than in the QA lab: “Humans do strange shit to software …” Still, the QA mentality has value.
  • Ron Rosenhead notes that lesson learned are only valuable to the extent that we actually do something to implement what we’ve learned.
  • Harry Hall illustrates the strategy of risk avoidance with an embarrassing story.
  • Ryan Ogilvie takes a lesson from Star Trek on managing the risk of exceeding your scheduled maintenance down time window.
  • Nick Pisano reviews our current state of fragmented digitized project information management tools and describes what the integrated future state should be.
  • Gus Lawson shares an anecdote about helping a team improve their ability to collaborate with others, and summarizes the lessons learned.
  • Robert Martinez outlines an approach for building effective teams.

Agile Methods

  • Mike Cohn makes the case for Scrum Master and Product Owner being two different people, not just different roles.
  • Johanna Rothman asks an interesting question: Who removes your obstacles?
  • John Goodpasture gets philosophical on the relationship between retrospection and management.
  • Sameer Patil reviews several alternative models for ordering your product backlog.
  • Sam Barnes provides the transcript of a Q&A he gave on managing digital projects.

Podcasts and Videos

  • Samad Aidane interviews Todd Williams on how to buy project management consulting service. Just 35 minutes, safe for work.
  • Dave Prior sits down with Personal Kanban guru Jim Benson to talk about matching work in progress (WIP) with capacity. Part 1 is just 11 minutes, all are safe for work.
  • Cornelius Fichtner interviews Joseph Flahiff on getting your team to be a rock band! Or at least, one that rocks. Just 28 minutes, safe for work.
  • Mark Phillipy and his two brothers compare notes on the practice of leadership in their respective industries. Just 54 minutes, safe for work.

Being Effective

  • Cheri Baker ditched her Outlook, Kanban board, Evernote, Toodledo, and Onenote for … uh, a paper planner. Hey, organization is about the skills, not the tools!
  • Peter Saddington shares an infographic on how set a daily routine that will improve your effectiveness.
  • Seth Godin clarifies the relationships between goals, strategies, and tactics.