When You Hire

Hiring is quite a fraught subject. What are the roles of HR, line management, and up-chain management? How do you know how to advertise, and where? Do you use internal recruiters, external recruiters, or no recruiters? How do you set a salary range, who negotiates salary with candidates, and how? Who participates in the interview process, and in what ways? Do you use in-house or external technical tests, or none at all? How much attention should you pay to which school someone attended or where they have worked so far? Should you only consider someone who has been in essentially the same role before? If not, how much difference in previous experience is too much difference?

Talk among yourselves and let me know what you decide.

Just kidding, but hoping to make the point that there is quite a lot to figure out. Let's start with first principles — what are you trying to accomplish with this pending hire? Let's say you want to hire someone to work in a code development or test role, or as a manager of such employees, since these are the kind of hires most of us are concerned with. To what purpose?

We need to challenge our reasoning.

I'm hiring to fill the hole left by Dave's departure. Not much of a job description.

I'm hiring them to be the technical lead on a new project. Could be a good reason, but why is this not someone who already works for you?

I'm hiring them to be the intern / new hire person who will do all the odd bits and pieces so the more senior people can focus their time on work requiring more expertise? Is this a real job or a dumping ground?

Am I hiring them to rescue the project / product / company? Or be the next sacrificial lamb when the company refuses to address the real impediments to progress?

Am I hiring them just to add capacity? Do you know what work they will do if they start tomorrow? And what they will likely be doing six months later?

I'm hiring them to bring in expertise that is not strong enough on the current team . Is that really a trainer, a manager, an architect, a technical lead, a project manager, an automation expert… and is the team ready to accept someone coming in from the outside as an expert?

We set ourselves up for a bad outcome when there is no clarity on all of the above and more, across the team. We have to resolve these issues before the ad goes out and the interviews begin. If your answer is something like: "But we are fast-paced … and we don't have time for … and I am already working on …" Then stop reading this article.

You will never have complete clarity on all of the above. It is also a given that things come up in the process of hiring that are not anticipated at the outset. The hiring manager has responsibility for making that new hire successful or for taking care of the consequences in the absence of success. Because of these points, the hiring manager must be allowed to take the lead.

Regardless of the many differences that exist across companies, this is invariant and non-negotiable. The hiring manager can delegate some initial screening to senior individual contributors, can work with HR to establish parameters, define the job and how it is advertised, and should ensure they are in sync with their boss on the goals and measures of success… but they must be the lead on the project called hiring . If you have any doubts about this, make a bad hire and see who they think is responsible.

"But I don't have time …" Nothing you do as a manager has more positive or negative impact on the business than who you hire. Consequently, this is your main responsibility. If you are too busy for your main responsibility, you need to make some changes. Nothing you do affects the business more than good or bad hiring. Nothing. No thing. Not one thing.

All of the questions above, and more are your questions to answer. If you hire the right people for the particular jobs you have, and the particular culture you have, they will amaze you in ways you could never predict. If you hire people who are a poor fit for the job or culture, you cannot manage (force, coerce, trick, encourage, train) them into being first class performers in that setting. Thinking that anything is more important than hiring is counter-productive.

* * *

Depending on the company, HR can be a huge help, a passive partner, or a minor (perhaps major) hindrance. If they can help you catalogue and answer pertinent questions, select your interview team, roles, and method, place effective ads, manage interview logistics, coach you on compensation discussions, and probe candidates for concerns in the offering phase, you'd be a fool not to partner with them. If they can provide none of those things, it's your job. If they get in your way, discuss that with them and go from there. If you think they should do the initial screening or the final reference checks, you are mistaken.

They can screen resumes if you tell them the kinds of backgrounds you have in mind. They cannot screen candidates on the phone because they are not software engineers. The entire set of questions they can ask to save you time, will at most save you minutes out of a process that spans weeks. And for that, you will annoy any really good candidate, and begin your relationship with them by signaling that you are not a strong enough manager to do your own hiring. More importantly, HR doesn't have the background to ask any questions central to whether or not this person is a good fit for the job, or for your team. The same thing applies to internal and external recruiters.

Similarly, neither HR nor recruiters can do reference checks because they are not engineers, and they are not you. While it's a rare candidate who gives a reference who will spontaneously say anything bad about them, there is a world of difference between a strong reference check and a weak one. A non-expert will not be equipped to peek under the covers. You can. When the reference says, "She was great at blah," you know what blah is. You know if being great at blah is no big deal, or something exceptional. Your unplanned follow-up questions will prove to be the value of making the reference check. This brings up a closely related point. Actually do reference checks!

You should have several people interview each candidate, preferably back-to-back over the span of a few hours in a single day, or two days in the same week. (If a candidate flames out early, you should make some excuse for curtailing the rest of the interviews and save everyone time.) Don't let each person ask redundant questions because you have not discussed things ahead of time. This wastes your opportunity to learn more, annoys the candidate, and because it lacks competence, it signals to your candidate that you lack competence.

* * *

Based on the strengths of the people on the interview team, decide who will focus on architectural knowledge, coding hygiene, testability, maintenance, performance, security, dealing with a tough technical decision, dealing with something emotionally challenging at work… the list goes on. Have each person cover one to three of the areas you consider salient for the job.

This is a good time to note that interviewing is a two-way process. Candidates, however much they may need or want a new job, are also checking you out. Your own twin goals are to assess them, and to have them leave feeling incredibly eager to work with you. Assuming it's true, you want them to go home feeling that yours is a culture they will do well in, that they can do what will be required of them, and that they will learn from working with people like the ones they met in the interviews . This last part is the strongest emotional component of getting an engineering candidate to want to become part of your team, to begin with a great attitude, and to face any initial setbacks or drudgery with resilience.

If you put two team members in the same interview, they can take turns. The one doing less talking at a given moment can often make observations missed by the one more verbally engaged. It can also give a view of how the candidate deals with multiple points of view and multiple people at the same time, a real-world work skill we need to use frequently. A three-way design discussion will demonstrate your and the candidate's collaborative styles to each other. It will also give insights into your candidate's on-the-fly knowledge and thinking that is hard to uncover in any other way. Give a lot of "points" to those who shine in this context, and run away from those who fall apart in this real-work activity.

Immediately after interviews if possible, but definitely quickly, get the team together to discuss each candidate. Especially for busy teams, details of discussions with candidates can be forgotten, and recollections of multiple candidates can mush together. To avoid more junior team members just following the lead of more senior members, have junior members speak first. To avoid junior members learning not to speak at all, ensure senior members are respectful where they see things differently. (This is a good general practice across many contexts, to develop your junior teammates, as well as your more senior ones.)

People are usually uncomfortable discussing compensation. As you might guess from things said above, addressing that discomfort is absolutely in the hands of the hiring manger, not HR, not your boss. If you cannot politely and directly ask a candidate what they are currently earning and ultimately make the actual offer compelling, get help. It's your job.

"Hi. I want to be your manager, your leader, spending years telling you what to do, evaluating you, having employment power over you, and I am too weak and queasy to discuss your compensation so I'll just go hide in the corner while someone else does that." No. Not a winning move.

If you are interested in a candidate, say so. Indicate likely next steps, and matter-of-factly ask about their current (or most recent) compensation. Be prepared for them to ask in turn for what you have in mind to pay for this job. Know the answer before you start any interviews. Don't make any promises — it's too soon in the process, but give an honest indication if their expectations are roughly in range or if finding common ground on compensation is likely to be difficult. Later, when you make the offer, you will have already established that you are comfortable in that discussion (huge courage and leadership points for free), and that you know what you are talking about. That goes a long way toward moving the candidate to "yes" with a minimum of last-minute negotiations. If they respond badly in this pre-discussion, that's a strong indication that you should not hire them.

I have not answered all the questions I raised, which are themselves only a representative subset of all the questions there are. Deciding which questions are most pertinent and getting them answered is your job, in the context of each particular job opening.

We often get to (have to) choose between two or three people who might likely to work out well. Cultural fit will result in people amplifying each others' contributions. Talent (intelligence, attitude, and problem-solving of a type suited to the job) will result in learning new skills and improving existing ones. Domain knowledge is important, especially if the point of a particular hire is to bring in focused expertise. Without the right problem-solving smarts, it's a short term fix (or not even that). And without a cultural fit, its value can be eaten alive by negative impacts on the team and on the individual. So, when you get to pick, choose cultural fit over talent, and talent over specific knowledge.

Happy hunting!

Featured:

Sep/Oct 2016