I’m doing a webinar series for Kennedy, starting this Thursday. See Building Effective Hiring Strategies & Job Descriptions To Match!. You can sign up for either or both. I hope you decide to join me Jan 18 and 25, 2007. (I’ll be doing another series in May about how to use different interviewing techniques and how to teach them–assuming this series goes well.)
Labels: hiring strategy, job description, webinar
Add comment January 15th, 2007
I coached a manager who’d hired seven people in the previous year–and had fired five of them. His manager was ready to toss him out, too. Instead, the senior manager decided this manager needed coaching about how to hire people.
When I asked the manager about his interviewing style, he explained that he used what I call irrelevant and hypothetical questions. (In the links, I suggest ways to use those questions. This manager was not a savvy interviewer.) In addition, he made all the decisions about hiring himself.For this strategy, review and possibly update your job analysis. Develop at least two behavior description questions for each quality, preference, non-technical skills, and technical skill. Develop some auditions. And, practice your interviewing with someone else, someone who will give you feedback. Finally, use your interviewing team to help make the hiring decisions.
When people aren’t working out, too often the problem is the hiring, not the person. It’s possible to make great hiring decisions. It does require some up-front work and practice–especially of learning how to interview successfully.
Add comment July 3rd, 2006
So you thought the project was on schedule. And now, someone in power has requested you finish the project earlier. Earlier than you can manage with the people you’ve got.You have a bunch of options, including moving to 2-4 week iterations. But that’s something I would normally discuss on Managing Product Development 
So, here are the options you might use for this problem:
I can only think of these two options, but there are likely more.When adding people to a team who’s already meshed, cultural fit is critical. Sure, the technical skills are important, because the team doesn’t want to have to train the new people. But cultural fit will trump technical skills every time in this case.
1 comment July 3rd, 2006
Imagine this scenario: You’re a development manager in a small organization. You have a product and a couple of customers. Over the course of the next year or so, you add a few more developers and a few more customers. And, your customers want to know when you’ll improve the quality of the product, because they’re finding more defects than you are. Time to hire some testers! I see this strategy needed most often in small organizations, but larger organizations are not immune from having a too-homogeneous group.
Cultural fit is key here. As you interview candidates, make sure their values are similar to the existing group. The longer the current group has worked together the more difficult it will be to integrate new people, so making sure their values mesh is the most important thing.So what about functional skills–aren’t they important? Yes, after cultural fit. The abilities of each person–especially in a small organization is key. If you have great developers, you better hire great testers, or the testers won’t be able to pull their own weight.
Once the entire output of the group has to change, focus on cultural fit to make sure the new people can fit into the group.
Add comment June 20th, 2006
If you’ve ever been involved in a startup before the startup had competitors or were part of a disruptive change in technology, you’ve needed this hiring strategy. In this case, technical skills are close to irrelevant.
What’s really important when you’re starting a disruptive change or you’re hiring a not-quite-known skill set is to specify the kind of adaptability, problem-solving, teamwork–all those technical context-free and oh so important personal and interpersonal skills–required. This is a case of defining the deliverables helps you tremendously when attempting to define the job. Even so, you and the eventual hire may have to work together for a while to really see what the new hire needs to accomplish.Here’s an example from my career. Back in the early 90’s the terms “release engineer” or “configuration manager” had not yet been coined. The only common version control system at that time was RCS. I was the program manager for a very large (100 people) software project. The previous release had spent the last six months in integration hell. I was determined that this release was not going to do that.
I was lucky. Sun had just released NFS, an early configuration management system. It allowed for branching and labeling, techniques I knew I was going to need, to keep all the sub-projects proceeding on their own, and to allow me to do something that was as close to continous integration as I could convince the developers to do. I needed someone to manage the sources, the branches, and labels, and to make sure the integration was working.
I knew “librarian” was too wimpy a term for what I needed. I needed someone I could call an engineer, since this person had to convince, help, persuade, influence the rest of the project teams to use the system in a way that made sense for the project. (I could see what I wanted–to end integration hell–but had no words for what I really wanted the person to do.) But since the software was new, I had no idea what kind of engineer to call this person. When I interviewed, I looked for someone who would be taken seriously by the other developers, who wasn’t intimidated by new software (that might not work all the time), and who could share my vision. I think we called the position “program engineer” to go along with my “program manager” title.
They guy I hired was smart, had been a developer, and wanted to take a slightly different slant on the next project. He was fearless in the face of the new system. He had great problem-solving skills and managed to handle most of the developers with relative tact. We worked very well together and avoided integration hell. We had a couple of weeks of discomfort–that’s all.We were using a cutting-edge technology. If I had not found someone who could make the system work (and if the software had been vaporware), I would have been tossed out (that’s the bleeding part). But because I got lucky with the software, and knew enough to hire someone with the necessary interpersonal skills who could become a part of all the teams, we were successful.
To be honest, this strategy by itself is rarely needed, but looking for people who are adaptable, who are great problem-solvers, and who can work well in new/existing teams is almost always a good strategy.
2 comments June 6th, 2006
Sometimes, as a manager in a technical organization, you realize you need to change technologies. In my experience, this is a change that takes place over time. So when I’ve used this strategy, I have hired people with expertise in the new technology and who could coach my current staff with their learning. And, I have hired people who could do the current work and learn the new technology. I paid more attention to problem-solving skills, adaptability, and cultural fit rather than technical skills. And I paid attention to the levels of the staff I was hiring, to make sure I didn’t bring in people at all one level.
Let me caution you against a technique I’ve seen used: relegate current staff to the “old stuff” and bring in new people to use the “new stuff.” I don’t recommend it. If you have some staff who don’t want to transition to the new technology–ok. But my experience with technical teams is that most people want to learn and use the new stuff. If you use this technique, the team will lose trust in your ability to watch out for their interests. Since you aren’t looking to help them learn, they will find a manager who will–generally at another organization.
1 comment May 4th, 2006
Sometimes, technical managers realize their groups aren’t performing all the necessary work, and worse, the people in the group don’t have the background or capability to do the new kind of work. The example I used in the book was that of a test manager who had been hiring testers who had all the same functional skills (manual black box testing), and now needed to have testers with different functional skills (performance and reliability testing).
I have a difficult time with this one. My expectation is that the manager should be able to foresee when their processes need to change. However, there are certainly managers out there who don’t have the technical knowledge to foresee when their group’s work needs to change. If you are one of those managers, bone up on what the people in your organization do and could be doing.
But especially if you’ve taken over a group with all one kind of skill, or if you realize that you can’t do the work as you’ve always done it, this strategy is one to consider.
What’s most important here is the set of functional skills already in your group and the set you need. Defining those functional skills requires care; I suggest you review the job analysis and make sure you understand the activities and deliverables required.
1 comment May 1st, 2006
The most common hiring strategy I’ve seen is when the hiring manager is looking for more people to do similar work to the work already in progress in the organization. For technical organizations, this means more developers/testers/writers/whomever with similar functional skills and the ability to easily learn the product domain.
When you have plenty of candidates, it’s ok to look at tools/technology skills. But if you don’t have lots of candidates, make sure you’re looking at how easy it is for people to apply their current functional skills to your tools/technology.
One common mistake I’ve seen, especially in smaller organizations growing quickly is to assume that you need all people at one level. If you consistently hire lots of senior people, you end up with a top-heavy organization. If you consistently hire lots of mid-level people, you end up with a bunch of people who are not able to progress to the top level (which might not be a big problem). If you hire only people with little or no experience, the manager has to take the time to coach them and help them grow technically and personally into responsible staff.
It’s critically important to do a job analysis for the first open position, and continue to re-evaluate the analysis as you hire more people.
Add comment April 28th, 2006
Sometimes, I work with managers who can’t tell the differences between technical people. They seem to think all developers (or testers or project managers or whomever) are equivalent. If you’ve ever tried to make the case for hiring the best people, read Joel Spolsky’s Hitting the High Notes.
Spolsky says
… duplication of software is free. That means that the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.Essentially, design adds value faster than it adds cost.
Note that Joel says later in the article,
The quality of the work and the amount of time spent are simply uncorrelated.
Some people work faster than others. But the really great people will have great ideas and work at (overall) similar paces. And, what’s more important, the quality of their work is head-and-shoulders above the rest.So think hard before you let your standards down and hire the next-best, or the third-best. It will cost you time and money.
4 comments July 26th, 2005
My colleague, Will, has been attempting to hire developers. He’s a bit frustrated. Take a look at Explaining the tech job market. Will is frustrated with the level of competence he’s seeing in candidates. That prompted him to discover Parnas’s Law of Hiring:
Parnas’s Law: The more incompetent developers you hire, the more you need.
There’s plenty of anecdotal evidence to back this up. In fact, one of the reasons agile projects succeed more often than traditionally planned projects is because there’s no place for incompetent developers to hide. Either your stuff works today and tomorrow and the next day or it doesn’t.
So how do you recognize competent developers? Well, the first thing, is analyze the job. Competent developers don’t care what language they use, although may well have a preference for some languages over others. If you write a laundry list job description, you won’t attract a competent developer. Think hard about the functional skills you need, as well as the domain expertise required, and how well a candidate has learned products in the past. Make sure you ask behavior-description questions in an interview to discover what released products the developers worked on, and how they worked. Develop an audition. Check references.
There’s a corollary to Parnas’s Law of Hiring: The more incompetent the hiring manager, the more incompetent developers you hire. Sad, but true.
2 comments May 3rd, 2005