Knowing is Half the Battle

Know What You Need in Your Software Engineers

Each role on an engineering team is unique. Sure, you might have multiple backend engineers who all write Python, but they’re not all doing the same thing. One might specialize in optimizing the performance of the API, while another delivers features day in and day out. One might delve deep into the database, while another loves to set up durable queues.

If you’re a software engineer hiring manager, especially at larger companies, when you get a requisition, it’ll probably look like Backend Engineer II, Python. You might even get a job advertisement that comes along with it. That job advertisement will miss all of the nuances of the role and can set up the applicants and the company for failure. Instead, conduct a role analysis that dives deep into what the team actually needs and build your process around that.

Isn’t that a lot of work?

I’m sure there are plenty of you saying that this is way too much work for the volume of engineers you need to hire. When you’re hiring 100 engineers, you can’t possibly slow down the process and delve into the granular characteristics of each part of the team. Besides, people need to be adaptable and learn new skills. And yeah, they do, but you also need to give the person who will inhabit this role a semblance of order and the tools they need to succeed.

So, my take is this—if you’re hiring someone, you want to hire once. If they don’t succeed, you’ll hire someone else, and now you’ve done it twice. If you have time to do it twice, you have time to do it right.

Doing it right means a few things:

• Know the Whole Stack
  Knowing Python is great, but you should understand where the person will have gaps. Do you use Jenkins, but they only have experience with Bamboo? Great! (I mean, poor them for having to use Bamboo, but it's great that you know this now.) Knowing this helps you figure out how to onboard them more effectively and get them up to speed quicker.

• Manage Expectations
  You have expectations in your head about what this role entails, but you might not be perfectly clear about them. You need to be explicit about those expectations if you want your new hire to succeed. Someone can’t meet expectations or exceed them if they don’t know what those expectations are.

• Stakeholders
  Stakeholders’ expectations are just as important as yours. If your product manager thinks that the new hire will double the delivery speed of new features, you should know that (and probably disabuse them of that notion) before the new hire gets caught up in it.

• Know the Team’s Gaps
  Where is the team struggling right now? Do they need someone to jump into another team’s API and make changes? What about someone who can refactor and document legacy code? Look for someone who fills the niche you need filled.

• Know the Team’s Culture
  Don’t make the mistake of hiring someone who’s a carbon copy of the existing team members. Diverse teams solve problems more effectively, but you need to know the culture of the team before you can select someone to add to that culture. Do you have one person who dominates the team? Add another strong personality to the team to ensure you’re getting more viewpoints on how to solve problems.

• Know the Company’s Culture
  Is your company skewed toward doing things fast and doing them independently? Make sure your new hire knows this going in. Are you more about building things to last and getting stuff done collaboratively? Same deal.
  Note: your company’s value statements aren’t your culture. Saying that you value “strong opinions, loosely held” doesn’t get to the heart of things that actually matter when you’re hiring someone.

So, it is a lot of work.

Yep, it sure is. But even if you have 100 engineers to hire, you’ll need to do all this work eventually anyway. You can put it off until the person is in the role and trying to figure it out, or you can do it upfront and give them a better shot at knowing what they need to do and when they need to have it done. And for some of these things, you need to know them upfront, or else you’re definitely setting them up to fail. Needed a strong personality for the team, but you hired someone quiet who wants to build consensus? You can try to coach them to be more assertive, but the likelihood of success is pretty low.

Know what you can trade off.

Once you know what the role requires, know what you can trade off. You’re not going to find someone who magically ticks all of the boxes. Be clear about what’s important to you. Things like communication style should be high on the list because that’s tough (or impossible) to change. Knowing all the bits of the tech stack should probably be at the bottom, though that will depend on the role.

Tradeoffs are key for the hiring process. If you want to hold out for the “best” or “perfect” candidate, be prepared to wait forever to find them. While you’re waiting, your team is suffering, and you’re losing out on opportunities. Be realistic about what matters and what doesn’t to make sure you balance time-to-hire with the goodness of fit. Be ready to accept someone who isn’t ideal and train them unless you lack the resources to train them.

Now you’re ready to hire.

Now that you’re armed with this knowledge, go create your job advertisement. You won’t be able to fit all of this in there, and that’s fine. You’ll need it for the interview process and for onboarding, too.

Don’t wing it.

Hiring is the most important thing you do as a manager. Getting it right can mean success or failure in some pretty outsized ways. The wrong engineer can cost thousands (or millions, if you get it really wrong), and they can derail entire projects or even whole companies. Spend a few hours upfront gathering information, and then be thoughtful and deliberate about your process. Your new employee will thank you, and you’ll save your company a bunch.