An engineering manager shares how hiring can be complicated behind the scenes. He says:
"I'm leading a team that was on auto-pilot mode for some time. I recently made a decision to hire a great candidate that the team was not sure about. I found that the team's objections were not on solid grounds, and we could've lost the candidate to another company (he had other offers).
The CTO and HR backed me, saying that we can take into account the team feedback, but they don't get a deciding vote. This led to some team members feel hurt, and we ended in a heated discussion. I'm 100% sure that the new candidate will be an asset to the team. I'm planning to have a chat with the team and explain my rationale and try to have an amicable discussion. How could have I handled the decision better?"
- an engineering manager trying to do the right thing"
The Challenges of Hiring and Hiring Panels
Hiring is challenging to do: after talking with someone for a few hours, you need to get enough signals to decide if they could be a good fit for the team/company for years to come. It's a big decision for everyone involved: not just for the company, team, and manager, but even more so for the potential new hire.
The cost of a poor hire is high, especially at places where it takes a long time of months to onboard. This is a reason Big Tech is notoriously conservative in hiring people: a bad hire takes a long time to notice, can cause morale issues, plus Big Tech tends to get enough candidates to not worry about not hiring people who might have worked out otherwise.
Committee-driven decisions are also almost always conservative. In a group setting, all it takes is someone to voice a concern, and the group can quickly change its position to be skeptical. Especially for decisions that could carry lots of downsides - like hiring the wrong person - group decision making can result in most of the "maybe" cases turning into a "no". Debrief panels - the discussion where all interviewers share their thoughts on hiring and come to an agreement - mirror this behavior, in my experience.
Debrief panels are common across Big Tech, and it's yet another reason for conservative hiring outcomes.
Make it Clear Who Decides and Who Can Veto
I personally believe in accountability for good decision-making. If someone makes a decision: they need to own the consequences of this decision. Hiring is no different.
Who will own the final hiring decision? It should be the person who will live with the consequence of a good or a bad hire. It should be the person directly responsible for the person: their manager.
Will the hiring panel do regular check-ins with the new hire? Will they do their performance reviews? Will they put together promotion cases? Will they get a poor performance review for mismanaging the employee in question? No. This will all fall on the manager for the new person.
Leaving the hiring decision just to the hiring manager can be risky, though. Many hiring managers are inexperienced: I was one of these managers after I became an engineering manager. I didn't have much to fall back on, beyond gut feelings, to decide if someone would be a good hire or not.
Some companies compensate for this by adding a second, experienced person to the hiring loop who has the ability to veto a hire. At Uber, this person was what we called the Bar Raiser: a long-tenured manager or engineer who had extensive hiring experience behind their back. Amazon uses a similar role.
Once it's clear who can have the final say - or veto - on hiring, things become more simple. Everyone can share their observations and suggestions, but the decision - or veto - comes down to the people who need to make this call.
In this case, there was no "person with veto", though this manager was smart to get a second opinion from the CTO and HR. If there had been a veto, that would have come from there.
Use Disagreement to Educate People on the "Why"
Ignoring a group decision on hiring is not the way to build trust. People put in a lot of time and effort for hiring because they want to make sure the right people join the team. You need to respect this effort and make sure their voices are heard.
Why is there such a big difference in viewpoint between team members and you? What is the root cause of objections not being on solid ground? Is the team over-indexing on areas that don't really matter to get the job done, like how fast this person coded? Or are these team dynamics that will matter, like poor communication?
Do take your team seriously and come to a conclusion they can understand. And be flexible in changing your mind if their reasoning is correct and has information you were missing.
You might want to take this disagreement to clarify what the expectations for a hire are, to invest in training interview panel members, and to coach people on how to gather signals during an interview.
You Cannot A/B Test Hiring, So Take Some Risks
For most engineering disagreements, you can fall back to trialing decisions by prototyping, A/B testing, or timeboxing working on something.
Not with hiring.
You'll never know if a person works out on the team unless you hire them. Similarly, you'll only know if you hire them.
I am a big fan of betting on people while giving them the support they need in their growth areas. So I encourage people to take bets on hires - but also work with both the new hire and the team on addressing the concerns.
Was the concern about coding? Have a plan on how they'll brush up on the language you use with the team, and ask someone on the team to mentor or pair with the new joiner. Was it about communication or some other soft skills? Take the lead, as the manager, to give feedback and have them act on it.
Spend more time preparing for their onboarding and tracking their progress after they start. While many organizations spend a lot of time on hiring, onboarding is often an afterthought. This is a mistake, as a great onboarding tends to make a huge amount of difference for a hire to succeed.
Listen to your team, but know when you take risks, and bring the team with you when you do. Good luck!
This post is part of the Ask the Engineering Manager series. Have a question on career growth, as a software engineer or engineering manager? Ask it here. Read other parts of the series here.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.