Posts filed under 'hiring strategy'
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!
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.
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.
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.
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.
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.
October 24th, 2007
In Hiring the Best …
, I recommend you hire for today’s projects, not for tomorrow’s projects.Now that we are back in a candidate’s market, it’s even more important to hire the people you need now. You can’t tell who you’ll need in the future. That “guaranteed” project? I’ve seen many of them postponed again and again. The plan to hire someone now and make that person a manager in several months? That always takes longer.A more agile approach says, “Here’s what we need to do now. which of the candidates will help us get the work done now?” If these people are good enough to help you finish the work, they’re good enough to learn the new work.
August 8th, 2007
George Dinwiddie pointed me this post, I got rejected by Google - woe is me. Read through the comments; they are as illuminating as the post. Here’s the stated Google hiring strategy, Hiring: The Lake Wobegon Strategy.I don’t see Google’s stated practice of hiring above the mean as congruent with what’s happening in practice. It looks as if their strategy as implemented only looks for specific functional skills–not domain expertise or the interpersonal skills that really make an environment work. Sure, they may be hiring above the mean in some small ways, but they’re creating a mono-culture.Whether or not my conclusions are correct about Google and their hiring strategy, the one thing you can learn from this is to make sure your hiring strategy does not create a mono-culture. If you look for people who can work all hours of the day and night for months on end, you will hire young people, some of whom do not have the maturity to know when they’re creating technical debt. If you ask theoretical computation questions, you’ll get people who aced their Theory of Computation classes, but may not know how to release software. The riskier the work, the more diverse a team you need–not a mono-culture. (I discuss this in Successful Project Management.)We’ll have to watch Google (and other companies that hire narrowly), to see what happens. Be aware that the more narrowly you define “smart” for your environment, the more likely you are to build a mono-culture.
Labels: culture, hiring strategy
April 11th, 2007
If you’re a hiring manager, read Mike’s Life Is A Hire Way: 5 Tips For Startup Hiring. Great ideas, Mike! (And not just for startups.)
Labels: hiring decision, hiring strategy, interview, recruiting
March 1st, 2007
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
January 15th, 2007
Previous Posts