Posts filed under 'hiring strategy'
I’ve been reviewing job descriptions from clients that are a laundry list of tools. Or, that ask for “significant experience” with a particular technology.
No, no, no. People are not tools. They are human beings who have specific qualities, preferences, and technical and non-technical skills.
When you think about those personal qualities, think about these questions:
- With whom does this person work?
- What kind of deliverables does this person have in the short term and the long term?
- What kinds of interpersonal skills does this person need to do their job well?
Take a look at the job analysis template to see more questions. Now you’re ready to think about technical skills.
Here’s how I categorize technical skills: functional skills, subject matter domain expertise (problem-space and solution-space), tools and technology, and industry skills. Of these four areas, functional skills–how good a developer, tester, architect, designer, etc the person is, and subject matter domain expertise–how quickly the person can learn the internals of your system, matter the most. Most people can learn new tools relatively quickly. But it takes much longer to learn how to test first, or use combinatorial testing, or see the whole picture and what can go wrong, and so on. Functional skills require experience, and more than the same year of experience again and again.
When you think about the people you need, think hard about those technical skills, and which skills you really need. Tools, and familiarity with a particular tool may not be as important as the ability to work in small chunks and finish things. Or to explore the product to find really bad defects. Or to see how the system flows–or doesn’t–together.
People are not tools. Look for people, not tools.
Tweet This Post
October 23rd, 2009
I’ve been at the PMI Regina PDC this week. I did a general session talk Monday, and am leading a two-day estimation workshop through tomorrow. Andy Nulman had a great riff on normal vs. abnormal employees. You can see a clip of it here. Warning: racy, not completely clean.
If you think of normal as conforming to a type (see normal) and as average, then most of us want to be abnormal 
Should you specifically hire for “abnormal”?
If you are in an entrepeneurial environment, yet. In a high innovation environment, yes. In a place that takes risks, yes. But not everyone works in places like that. Hiring for people who have a wacky way of looking at the world is part of cultural fit. Don’t just hire people who are not average, who don’t conform because it’s an interesting idea. Make sure you have cultural fit, too.
But I still like the idea of not hiring “normal” people
Tweet This Post
May 6th, 2009
I read a bunch of blogs, and Evolving Excellence is consistently good. I was struck by this post, Homozygosity – That’s The Problem!. I had never heard of homozygosity before, so I looked it up. According to Merriam-Webster, it’s
having the two genes at corresponding loci on homologous chromosomes identical for one or more loci
The result: you get enough people (in this case) who think alike and get them to work together, they inbreed their thinking. That leads to
There is an old saying that ‘great minds think alike’. Probably, but I’ve noticed that morons think alike too.
I laughed out loud at that one.
But Bill is right. It’s too easy if you have insufficient diversity to achieve group-think without meaning to. If you’re hiring for problem-solving skills, which is what we do in high tech, you want diversity of all kinds: personality, schooling, race, culture, to name just a few. Insufficient diversity leads to an inability to generate other and different solutions.
Think about what diversity might mean for your group and how you can find it.
Tweet This Post
March 18th, 2009
In the comments to Why Hire Junior Contractors?, one of my recruiter colleagues, MN Headhunter, asked a great question:
…if we do not hire junior developers how they gain the experience to be a senior developer?
I was not clear enough in my original post. I believe in hiring a diverse team, especially in diversity of experience, and diversity of personality type. That includes junior developers (and testers and analysts and whatever other kinds of roles you need for your team). I encourage you to make that kind of diversity part of your hiring strategy.
Junior staff have a lot of possibilities to offer your team, which is why it’s worth hiring them: energy, a willingness to tackle any kind of work, maybe some ideas you haven’t considered, and more than I can think of right now.
But they do require training, which is why hiring a junior employee makes sense. To me, hiring a contractor as an extra pair of hands, when those hands need to be trained, doesn’t make much sense. But hiring employees–especially junior staff whom you can grow–that makes a lot of sense.
Tweet This Post
August 11th, 2008
Many hiring managers are looking for initiative, especially for agile team members. (In agile, the team members self-organize, which means they are looking for ways to do work better and to solve problems without requiring management’s involvement.)
I was thinking about initiative how to look for it, and I realized that at least some people with high initiative are only one small step away from being entrepreneurs. Sometimes it can be difficult to see where initiative ends and entrepreneurship begins. Should you hire people who have a high probability of walking away?
Yes.
First, there’s no guarantee how long any of your hires stay, so not hiring someone because you think the candidate might leave doesn’t buy you anything. But even more importantly: how much could you take advantage of this candidate’s ideas? High initiative people/entrepreneurs have lots of ideas. Many of them could benefit you, your team, your organization.
Bring on the high initiative/potential entrepreneur candidates. Let’s see them rock!
Tweet This Post
July 8th, 2008
Jurgen’s post, How to Select a Fine Technical Manager, along with the posts he responded to prompted this one. I’m not agreeing much with Jurgen today. I suspect it’s because we have very different experience. In my experience, only technical people who want to manage want to be managers–unless HR has screwed up the salary ranges. If the salary ranges don’t go high enough for technical staff to make a good living, they want to be managers to increase salary.
I addressed part of this question in How Technical Does a Project Manager Have to Be?. And the answers are similar for a people, not project, manager.
Technical managers need to have these technical skills: None.
Seriously, when was the last time you needed your manager to tell you how to solve a technical problem? Unless your manager is coaching you, the last time was when you only had a year or two of experience.
Technical managers need an in-depth understanding of the process by which the technical staff can perform the work. That may well mean an experience in where coding can trip developers up, where testers might have blind spots, how to help business analysts talk to the people who have requirements and how to translate those requirements into user stories, and so on. But the manager does not need to be the star of the group–and in many cases, the star is not interested in management, so makes a bad manager.
What’s way more important is all the interpersonal skills. Here are some from the chapter in Hiring the Best Knowledge Workers…:
- Provide effective feedback.
- Influence and negotiation skills.
- Problem solving and decision-making. Managers need to be able to solve problems and make decisions in the face of ambiguity.
- Delegation.
- Ability to manage things, such as projects or groups of tasks. Technical people don’t need supervisors; they need leadership, guidance, and effective decision-making, especially when faced with too many options or insufficient information.
- Ability to observe current state and choose another action to change state.
Jurgen goes on to say
Give the job to a technical person who never asked for it.
Well, I don’t buy that either. I have asked people who were critical of management if they wanted to try it. Some organizations make effective management just about impossible. I was a middle manager, had a technical lead who was critical of everything, and asked him if he wanted to try management for a few months. He lasted three months, and gave up. I told him not every place was as screwed up as that one, and to try management again later.
Potential managers need to want to work with people. They need to make decisions without enough information. They need to wean themselves off the technical work. They need to learn how to hire, give feedback, and all kinds of other management skills. (To see how great managers work, read Behind Closed Doors: Secrets of Great Management.) But they don’t need to be dumped into a management role, or think they aren’t good at technology and that’s why they’re managers.
BTW, if you’re wondering, I started my career as a developer, did some small-project management and people management starting once I’d been working a few years, still developing. I became a tester and took on a bunch of project management and coordination work because I liked it. After a couple of years, I became a full-time project and program manager. After a few years, I became a manager, then a group manager, then a director. Then, I went back to developing test code for a while, then a manager, then a consultant. Don’t think you need a linear career path. You can try management and return to your technical work if you don’t like it or if you’re not ready for more responsibility. But don’t try management unless you want to work with people. Management is a people-centric role.
Tweet This Post
May 27th, 2008
Joan Lloyd has a great post that I saw at Don’t turn down the new job before asking these questions by Joan Lloyd bizjournals.com. Her questions are:
* What specific results are you expecting in the first three months? Six? One year? How will you measure those results?
* To whom can I go for questions as I’m learning my responsibilities? How much time will you have to devote to getting me up to speed?
* Who are the strongest performers on the staff and would they be willing resources to help me with day-to-day questions and processes?
* What are the biggest problems that need resolution within the first six months? What has been done thus far? Who would I have to work with to settle these issues?
* Why have you gone to the outside to fill this position?
* May I meet some of the staff before making my final decision? That way we can make sure it’s a good fit from all perspectives.
If you’re a hiring manager, you need to answer these questions before you start interviewing, so you can answer a candidate. Yes, you need to answer them.
Tweet This Post
March 4th, 2008
SlackerManager agrees with me in his How do you hire great people?. I said Hire for Intangibles; You Can Teach Technical Skills.
It’s a person’s attitude, passion, and ability to work with other people that counts.
Tweet This Post
February 23rd, 2008
In my recent consulting (workshops and assessments), several technical staff and their managers have told me they’re not sure they are being paid what they’re worth. I ask “How do you know?”
They tell me all the ways they’re working for the organization and how much that benefits their managers. I ask the next question, “Did you tell your manager?”
When you’re looking to hire someone, you can’t have the conversation about what someone has done for you at your company now; instead, you have the conversation about what the person has done for their current and some previous companies during the interview.
Everyone provides some benefit. That benefit is what the position is worth. If you think you’re not making enough, articulate your benefits to your current employer. Assign a dollar (currency) value to your work. Don’t like the number? What would you have to do bring more value?
If you’re looking for a new job, know what you’re worth. And if you’re a hiring manager, think hard about the skills that would bring the worth you desire to your organization. Go back to your hiring strategy and job description. Do they describe the value you want from a candidate? If not, your job description is not working for you. Change it.
Companies don’t pay people because they are warm-hearted. They pay employees to provide value. The more value, the more pay. (We hope. Sometimes, that’s the more expected value, the more pay.) If you’re a candidate, define your value. If you’re a hiring manager define the value you want to receive. Now you’ll have a much better understanding of what you should pay. And, you’ll know what the decision is worth.
Tweet This Post
November 25th, 2007
I emailed with a colleague today. He’s been looking for a position that shouldn’t be too hard to fill–but it is. Let’s assume the position is a development position. He interviewed a candidate. He’s not thrilled with the candidate; the candidate doesn’t have quite enough functional skill to do a good job. The interviewing team is neutral to positive, so he’s not alone with this lack of thrill. But his manager wants him to hire this candidate, for a slightly different position, as a release engineer.
I suggested he make it clear to his manager that hiring this candidate as a release engineer does not fill the development position. If the organization needs a release engineer, then interview and possibly hire the candidate for that job. But don’t fool yourselves into thinking you’ve covered the development job; you haven’t.
Make sure your manager understands your test strategy and your hiring strategy and your job analysis before you agree to this hire. Point out the risks, “Ok, we can hire the candidate, but we don’t get more development done. Want you to know that.”
Don’t settle for less than what you need in a candidate. I have several ideas about what to do when you can’t find someone. I’ll start a series about what to do when you can’t find a candidate. But don’t settle. You won’t get the work done that you need done.
Tweet This Post
October 24th, 2007
Previous Posts