“Just hire great people” is spectacularly unhelpful advice.
There’s plenty wrong with the “just hire” part—hiring is hard, and there’s no “just” when it comes to finding the right person for a role—but I’d like to focus on the “great people” aspect. I suspect folks flock to this phrase because it sounds positive, humble, and uplifting: We hire great people! All of you are great!
But when you create a culture in which people are the secret ingredient, people can also be seen as the problem. If we don’t give our people the resources they need to succeed—like fair expectations, room to grow, and a place in the company strategy—they may shoulder the blame for not living up to the culture’s expectations of “greatness.”
There’s a way out of this trap. A central tenet of reliability engineering is the idea of a blameless culture: Rather than focusing on who “caused” an issue, engineers reflect on how the system itself can be made more reliable and resilient. We can apply that same mindset to building engineering organizations, examining the systems in which our people operate when something goes wrong.
To that end, I recommend incorporating the following questions into our hiring plans. While not an exact science, these serve as a check that we’re providing baseline structural support to new hires instead of relying on some mythical measure of superstar status.
Can we support this person’s ramp-up time?
Say an organization hires a brilliant person who’s never worked in a software engineering role before. They know how to code, but they haven’t used their skills in years. Still, the hiring team can see this person is capable, smart, and driven. Within a month of starting, they’re made the lead on a highly technical project with a massive codebase written in a language they’ve never used before.
This new hire flounders, trying to balance learning a new programming language with attending cross-team meetings, absorbing the codebase, and assigning work to other engineers on the project. The engineers are frustrated, and the new hire feels like they’re failing the team. Eventually, their manager hands the project to someone else. After this unwelcoming introduction to software development, they decide to transfer out of engineering.
This is a prime example of how a “just hire great people” philosophy can fail. While this person was capable of great work, the expectations put upon them in their first month were patently unfair. Had the hiring managers taken concrete steps to understand the skills required to successfully lead the project, they could have made different choices. Perhaps they would have given the project lead role to another team member while bringing this person on in a supporting role.
We all understand it takes time for new hires to learn the ropes, but we often don’t do enough to make onboarding expectations concrete. When you hire someone for a role in which they immediately have to perform at a higher level—for instance, expecting a new programmer to act as a senior tech lead—you’re essentially hiring them into a performance improvement plan. That’s why it’s important to determine whether you’ve actually set aside enough time for them to ramp up before they’re expected to start performing.
To create a realistic estimate, consider outlining a few projects your new hire might work on if they started tomorrow. (Don’t worry if the specific projects change by the time they start.) Detail the skills needed to succeed, then measure them against the applicant’s skill set, taking note of any gaps. For example: Have they worked on your codebase before? Have they used the tools, languages, libraries, and paradigms your team uses? For each gap, estimate how much time they might need to onboard based on how other engineers have performed. Does that time frame match your expectations?
It’s unlikely any one candidate will have the exact skill set you need—and even if you find this fantastical being, they’ll still need time to learn how to navigate your organization’s processes and structures. But by deeply considering what skills a new hire will need to have or learn within their first months of work, you’ll be able to set more reasonable expectations and clearly communicate and hire against them.
Can we give this person room to grow?
In my experience, hiring conversations often provide inflated promises of present and future scope and opportunities: You could be architecting a new system in six months! You could be leading a team within the year! But by making an effort to more accurately understand and communicate a role’s actual scope, we enable prospective hires to make informed decisions about their careers. Done well, this can lead to happier employees and higher retention.
Suppose you’re leading an overtaxed engineering team. Smaller tasks, like bug fixes and low- to medium-priority features, aren’t being addressed because the team lacks bandwidth. You decide to hire a new-grad engineer to help out, assuming the role will give them plenty of time to get familiar with your codebase, tools, and processes, as well as the nuts and bolts of software engineering. But the new grad ramps up much more quickly than you anticipated, and the small tasks soon become too easy for them.
In theory, this is great news—you’ve hired a capable engineer who’s exceeded your ramp-up expectations. Now that you have another strong engineer on the team, smaller tasks can be load-balanced across team members and you can give the new grad a bigger project to work on.
Unfortunately, though, it doesn’t always work out this way. Sometimes a team has just a few large projects with established leads. In this case, you might need the new grad to work on small bug fixes and features for the foreseeable future. While new projects will inevitably crop up, you can’t be sure when. That ultra-motivated new grad might become demoralized in the meantime.
This is where clear and transparent expectation-setting comes in. Not every new hire is looking for the same thing, and some people might be fine taking on a tightly scoped role for the time being. Better to find those people than to promise rapid growth, only for a new teammate to be frustrated—and potentially leave the company—when the role doesn’t align with their expectations.
Once again, we can use simple ballparking techniques to more accurately represent growth opportunities. As you’re creating your hiring plan, brainstorm a few realistic projects that would represent a step up for the role in question, and consider how long—six months, a year, two years—it might take for them to materialize. While hiring managers can’t predict the future, we can leverage our knowledge of the company’s goals and team trajectories to create a reasonable picture of what a new hire’s first year or so might look like. (And if growth opportunities in a role are extremely limited, you might not need to hire at all. Maybe there’s another solution, like temporary or part-time support.)
What roles do we need to succeed as a company?
It’s wonderful to create an environment in which people are given level-appropriate challenges with plenty of opportunities to grow. But a company also has to work. If a team isn’t achieving its goals, it may be sunset. If a company isn’t accomplishing its objectives, it may go through layoffs, reorgs, or fold altogether. These failure modes tend to disproportionately affect those with less power and stability. The CEO will likely make it through layoffs, while early-career employees are often the first to be let go. To provide a stable and healthy environment, leadership needs to hire against an evolving roster of required roles and skill sets.
This is especially true for startups. Imagine a fast-growing company in which team leads are given a budget to expand their teams along with the freedom to fill those roles however they see fit. There’s no pressure to hit goals on a given timeline and no definitive success metrics. This all makes for a relatively relaxed work environment—until the company lays off half its staff. Turns out, it’s burning through cash too quickly and isn’t close to meeting goals that would unlock further funding.
This, in my view, is the biggest flaw of a “just hire great people” approach—it doesn’t necessarily account for what the company needs, and can result in hiring talented people just because they’re talented. But being on a team that doesn’t particularly need your skill set isn’t only dispiriting, it’s also risky. These “great” but less well-matched folks are often the first to go during budget cuts or layoffs.
We can avoid this by accounting for how each role contributes to the company’s success in our hiring plans. Start by sketching out your team or company’s goals. (For example, perhaps you’re an early-stage startup trying to find product-market fit, which means you’ll need to ship new features quickly, test them with users, and see what sticks.) Next, consider the types of roles best suited to help you meet those goals. (Maybe you want to hire three senior frontend engineers, one product designer, and one product manager.) From there, run through some expected product development scenarios and imagine how these roles might work together. (Say your startup needs to create several prototypes in parallel, and you want the product designer to work closely with the engineers. Is one product designer to three engineers the right ratio? Would it make sense to hire design engineers instead? How does the product manager fit into all of this—do you even need that role?)
By staging these scenarios, you can edit your hiring plan. It might sound tedious, but meticulously modifying your plans in this way means you’re more likely to hire the people you need, when you need them. Every time you delete a role from your hiring draft, you’re potentially preventing someone from being let go later on. Once you’ve run through a variety of scenarios, you’ll arrive at a set of roles that are flexible enough to be useful even under changing circumstances.
Fault-tolerant systems for people
There’s no way to guarantee your hiring plan will get everything right—but that’s not the point. The goal is to make a genuine effort to verify that, given a set of reasonable assumptions, new hires are able to meet your expectations for success and find fulfillment in their role. Just as it’s impossible for software systems to be perfectly reliable, it’s impossible for every hire to be a perfect fit. But we can analyze the hiring system and make informed decisions based on estimates, likelihoods, and our knowledge of how our team and company operate.
The steps I’ve outlined here might seem intuitive, but they’re often overlooked as hiring managers scramble to fill vacated positions or create new roles to support an organization’s growth. Case in point: The painful hiring scenarios I’ve described aren’t pure hypotheticals, but examples drawn from real life. Time and again, I’ve seen how an absence of dedicated planning, combined with the undeserved influence of “just hire great people,” puts people—often those with the least power and security—into precarious situations.
Building better, safer hiring systems begins with recognizing that in a truly blameless culture, hiring isn’t about judging a person’s innate abilities. Instead, it’s about ensuring the person you hire can succeed in their role, has room to grow, and is equipped to contribute to your company’s goals. When a person isn’t thriving in their role, let’s examine the systems we’ve asked the individual to work within. Let’s seek out ways to make those systems more reliable. Let’s retire “just hire great people,” and instead create a great hiring plan.