An Engineering Manager's Guide to Hiring - Planning to Hire

Hiring, growing and retaining people are going to be your most important skills as a manager. Growing your team, not just grow in size but in ability and consistency, is the most accurate reflection of your management abilities.

If you're an engineer that's new to managing, it's important to shift from an individual contributor mentality and think about how you can use your time and energy toward making your team better instead. Spending time making each of your team members a little better is going to provide more value than if you focus on continuing to be an individual contributor.

In my last post (which due to a move and a job change of my own was quite some time ago, thanks for sticking in there!) I described some ways to provide career planning and advancement support for your team. In this post, I'm going to focus more on the hiring side.

Before You Hire, Review the Team

A trap I've seen many new leaders fall into is being told they have a budget assigned for hiring people for their team, and then immediately rushing to hire people with that new headcount before fully understanding what they need yet. This is especially common in startups which may not have a proper headcount planning process in place.

Unless you’re hiring for a completely new team, every hiring conversation for a team should begin by reviewing what the team has now. If an engineer leaves, the first goal shouldn’t be to replace that person with the same role; the first goal (after understanding why they left) should be to review the team composition and workload, and to re-evaluate what the team needs to be successful.

There’s a decent chance that the team composition and dynamics have changed since a previous person was hired, and so it’s important to review carefully. If there’s a team lead working under you, consult with them on what’s working well and what’s not working well with the current team’s capacity. If you have a product owner or project manager working with them, consult with them as well on gaps they're seeing.

Adding another person doesn't mean the capacity of that team increases the same amount, and it's reasonable to expect for the first few weeks after adding a new person productivity will go down as others help the new person get up to speed. So adding a person just because you can, should never be your goal. Identify a gap, and be clear about the kind of person and role that would help the team perform better.

Example:
An engineer with experience in Amazon SageMaker (ML Engineer) that can lead the building of models in the team and coach other teams on its effective usage (Staff or Architect level).

Define Success

Now that you have identified a needed gap (or if this is a new team identified a new role), it's time to define the role. I always start this process by defining success first. Put yourself in the future when you've already hired the ideal person and write down what they would have accomplished with the team. What work got done? How did their presence make the team grow? Write down 5-7 bullet points.

Example:
- Delivers a more efficient model building pipeline for the team with SageMaker
- Levels up the rest of the team on effective model pipelines
- Leads our technical effort to replace our existing Cortex pipeline to SageMaker
- Writes comprehensive documentation to make it easier for other teams to understand and use the model building pipeline.
- Works with our DevOps who will build and secure the needed AWS environment.

Now that you have an idea of what good outcomes look like, it's time to turn that into a one-paragraph summary of what success looks like for the role.

Example:
The right person in this role will be the technical implementation force behind our move from Cortex to SageMaker. They'll work with the DevOps team to ensure the environment is correctly set up, establish initial pipelines, document its effective usage, and coach their peers.

From here, write down what skills and competencies would be required to make the success you've outlined possible. If they're taking the lead on your new AI-based automatic appraiser for lunchboxes, what are the things they're going to need to know?

What this list is will vary, but I'd encourage thinking about this for each team and not just copying-pasting a long list of requirements. A good candidate cares more about the specific unique properties of the role, and trust me, bad candidates will apply regardless of how many requirements they don't meet. There's also good research that suggests that women will avoid applying for a job if they don't meet every requirement, but men will still apply. Making your requirements list too long can hurt your DEI goals.

Make Your Team Sales pitch

You have your skill requirements and a description of what success looks like for the role. Now it's time to flesh this into a full job posting. If your company has an HR or People team, they're likely going to want to be involved at this point. I always encourage engineering leaders to stay hand-on during the crafting of the job posting.

Aside from the definition of success and the skill requirements, you'll also want to share a short description of the team itself and their goals. Sometimes you can't get too specific for competitive reasons, but you can often describe the daily work quite well without going into specifics of the project itself.

In addition, share a bit of what's awesome about your team and company. This is often something that can be reused between roles. I also encourage hiring managers to include at least a few points about what isn't awesome, or isn't awesome yet. If the team is still small and finding the right way to do this, say that. If the company recently pivoted, share that too. Being up front builds trust and allows the right candidate to see how they can be a part of the future.

Now, you have a defined role ready to go live into the world. In my next post, I'll be diving deeper into evaluating candidates and running an efficient interview process from a small company (<100 total people) perspective.

If you have hiring processes you've found that work, share them in a comment to this post on my blog. If these newsletters have been helpful for you, share them with a friend!