Matt Mullenweg of WordPress on Paul Graham’s argument that we the government needs to grant far more U.S. visas for software engineers:

I agree that the US deserves dramatically better immigration policies, but in the meantime I’m confused with the head-in-the-sand approach most tech companies are taking simultaneously complaining that there are lots of great people they can’t bring into the US, but being stubborn on keeping a company culture that requires people to be physically co-located.

Recruiting is about tradeoffs. One of the easiest ways to expand your pool of potential applicants is to remove the requirement for physical proximity. Managing a fully or partially remote team is a different and in some ways more difficult job than managing a group of people who all show up at the same office every day, but seems more feasible than changing U.S. immigration policy to make it easier to bring more engineers from overseas to the Silicon Valley.

I’ve read two really excellent posts about hiring engineers lately. Both of them are aimed at adding nuance to the discussion of “hiring the best.” The first, from Cate Huston in Model View Culture takes this on directly in her essay, We Hire the Best. Here’s her rephrasing of “hiring the best”:

Among people we know, we hire “the best” (as determined by our subjective process), who are willing and able to work in a specific place (or remotely), and who accept our offer.

She then goes on to survey the space that exists between “the best” as defined by the company itself and the candidates who wind up accepting offers. That space also happens to be where most of the industry’s worst hiring practices live.

Jocelyn Goldfein’s piece, How To Hire Engineers: Step 0, What To Look For, goes on to demolish the idea there’s a definition of the “best engineer” that works for choosing who to hire in the first place. There are a large number of positive characteristics an engineer might have, and some of them are in opposition with one another. Building a good team is about assembling a group of people that collectively exhibit all the strengths you’d hope to see.

The risks of emphasizing a few strengths to the exclusion of others are high. Here’s one end state:

If you elevate your “hiring bar” to religious status, and represent, say, coding speed, not as a means to the end of shipping great software, but instead as the gold standard of What It Means To Be A Rockstar, you’re going to have a lot of trouble hiring for anything else. Your existing team (who have all been selected for coding speed) will view this as “lowering the bar” and the consequences could be severe — anything from griping and loss of morale, to blocking or undercutting new hires, to quitting.

I have seen this happen, and it’s not pretty.

As a manager, I think it’s important to think about the next hire rather than the ideal engineer. What does your team lack right now, and how can you address it by hiring someone? Maybe you need someone who’s more collaborative, or maybe you need someone who really likes to dig into deep problems. Maybe you need to hire a more junior person to take some work off of a senior person’s plate, or maybe you need to hire a senior person to tackle big projects. When it comes to hiring, you have to blend these requirements with the attributes that you consider to be non-negotiable and then apply those wishes to the pool of candidates who are available.

It is incredibly tempting to think about hiring the way colleges think about admissions – ranking the candidates and hiring the “best.” This is a very common approach to scaling up the hiring process at tech companies. I don’t think that it’s the path to building solid teams as opposed to groups of solid individuals.