Hiring the right person to be your new boss
It’s not an uncommon situation, and it’s not necessarily a bad one. Sure, you’ll lose development time getting this new person up to speed. But with careful handling, you can turn an org chart shuffle into eventual productivity gains.
Nudge your way into the hiring process
The first and most important step is to try to get in on the hiring process. Asking your departing manager or your future boss’s future boss if you can sit in on the interviews for the open position may seem presumptuous, but in the three times I’ve tried it, I’ve yet to be turned down. Frankly, I suspect that technical managers are excited just to see any organizational interest that extends past bit shifting and byte code in their developers. Whatever the reason, you’ll probably be pleasantly surprised at the ease with which you can get your input counted in the hiring decision.
If your request to participate in the interviews is met with something less than enthusiasm, respond with gentle pressure. Perhaps ask if, instead of joining in on their interviews, you or you and some development team cohorts could conduct your own interviews with management’s favorite candidates. Remind them how important it is that the development team be able to relate to this person. Perhaps even hint that they’ll get more detailed status reports (the oh-so-valuable currency of the developer/manager relationship) if the new manager and the development team have good rapport.
If you don't get the clearance for an interview, you might as well break at this point. The rest of this article isn’t going to help you. Just start polishing up your documentation so that you can make a good first impression on your new boss. But if you’ve gotten the okay to join in the interview process, it's time to talk goals and how to achieve them.
What it takes to be a good technical manager
When listing the attributes of a good manager, it’s best to start by identifying the function of a good technical manager. It’s not providing direction, focus, guidance, or any other popular euphemism for micromanagement. Rather, it’s acting as buffer between you and the layers of management above. So your objective when interviewing a prospective manager should be to determine the candidate's suitability for that purpose.
Speaking the language of management
Proper management buffering requires the right combination of traits, some of which are almost mutually exclusive. Of the utmost importance is the candidate’s ability to speak the language of those who would be his or her peers and superiors. This is the easiest trait to find in a candidate. Indeed, upper management is usually quite happy to provide a seemingly endless string of candidates just like themselves.
If you should wind up with a boss who doesn’t have this skill, you’ll have an ineffective buffer who can’t keep upper management at bay. That's why I recommend against fighting for someone who is more developer than manager. Such candidates will almost certainly be a pleasure to work for, but they frequently don’t have the political savvy necessary to stave off those above them in the food chain. Fortunately, it's unlikely that you'll be presented with a candidate who’s more developer than manager. The candidate’s future boss will usually weed this sort out.
Speaking the language of developers
If the ability to communicate with peers and superiors is the most important trait to seek in a candidate, the ability to communicate with developers is a close second. Some development experience, no matter how distant, is a big help. A COBOL cowboy from the 1970s might not know much about compiling RMI stubs, but he or she understands that there's a difference between a developer and a highly paid data entry clerk.
Fluency in developer-speak is an easy check box to fill in. Simply engage the candidate in a discussion about any of the topics with which the average developer has at least a passing familiarity. These range from CPUs to language comparisons to The Simpsons. Your candidate needn’t be able to sustain a 15-minute dialog about each of these subjects, but if you’re zero for three, it’s time to start figuring out how you’re going to phrase it when you advise a pass on this person.
Strength of will
Talking to management and talking to developers covers the interface requirements of the development manager position, but a translator who merely relays messages between development and upper management isn’t quite what you need either. A true buffer will be someone who can offer organizational resistance. When the CTO decides that a new feature is needed so urgently that all other work must stop, you need someone there with the ability to speak the language and the strength of will to politely say, “No,” to his or her own boss. It's true that a stronger manager might mean your being held to commitments and deadlines with more frequency and pressure than you’d like, but you’ll smile ear to ear the first time you hear, “My team’s good, but that’s impossible.”
Identifying a candidate with sufficient strength of will is undoubtedly the trickiest step in the process. If you were interviewing future coworkers or subordinates, you’d be able to give them a little guff—for instance, correcting them on something when you know they’re actually right and gauging the response; but this is your future boss. You can’t push too hard without running the risk of starting with points against you. Ideally, you'll be part of an interview that includes your current boss, who will tweak the candidate a little. Barring that, you’ve got no choice but to drop the subtlety and ask, “Can you tell me about a time you stood up for your development team in the face of pressure from upper management?” If you get puzzled silence or a “why would I do that?” look in response, start working on a politically sensitive way to torpedo the candidate.
Thanks, but I'll pass on this one
This brings us to the most delicate part of the whole process: politely declining a candidate. The person within your organization making the final hiring decision is going to be seeking your input. If you like a candidate, your task is an easy one. Praise that person in as glowing a report as you feel comfortable giving and be sure to focus on traits that will appeal to the person making the hire/no-hire call.
But if a candidate isn't what you’re looking for, you’ve got to be careful in how you say it. While you can’t say you don’t think the candidate will fight for the developers, you can call into question qualities you’re in a better position to evaluate than upper management, such as sufficient technical knowledge. Or you might mention differences in general development methodology. Above all, do it verbally. A candidate might become your boss despite your reservations, and you don’t want him or her to ever see what you said. A third-party retelling of your comment can be explained away, but an e-mail can last forever.
If things go well and luck is on your side, you’ll be a few months away from a gelled, functioning development team. If things don’t work out, so be it. Industry turnover is such that you’ll probably get to try again in six months.