Two Questions

As I've written about in the past, I think managers should put a very high value on recruiting. Beyond just being active participants in the process, I think teams should really own their own recruiting efforts, from sourcing and outreach to the interviews themselves. Over the last three years of working with rad folks like Sabrina and Tom (who have both now fled BuzzFeed for Thailand if that tells you anything), we iterated a bunch on our interview processes, even beyond what Sabrina details in that series of posts. We created robust spreadsheets to track and report on hiring efforts, trained our team to handle each stage of the interview process and made a bunch of other improvements that we felt were pushing our hiring practice forward.

And yet...

One area we constantly struggled with, however, were candidate evaluations. We had a strong desire to base our hiring decisions on how a candidate matched up to the expectations we laid out in our role documentation. But while that felt right in terms of creating a level playing field, we had a hard time aligning that with how we framed what feedback we wanted from our interviewers.

At first, we adjusted every feedback form so that it gave people fields for every category in our role document. Besides, being way too many areas to reasonably evaluate, our interviewers from the Product and Engineering org were frequently unsure of how to evaluate some of the more design-focused skills in their evaluations. We weren't giving them enough guidance to know what we expected, and in lieu of that they felt pressure to make calls about visual design or design patterns, simply because they were in the form.

After that, we tried forms tailored to each type of interview. However, this wound up being just as bad as the previous idea. It turns out, that what we wanted interviewers to focus on with each candidate varied based on the candidate, their level, and what we'd learned about them so far in the recruiting process.

On top of all that, the rigidity of using our role documentation verbatim for writing feedback was starting to hurt our ability to hire candidates. If we were attempting to hire a mid-level designer, all of our feedback would be about that particular role description. There wasn't much nuance regarding how someone might fit into a particular team, nor how they'd perform at a different level than the one we were interviewing for. Additionally, we noticed a downturn in the tone of the reviews themselves. People frequently wound up focusing on how people didn't fit the role descriptions rather than how they did (and the odds of someone who doesn't work at BuzzFeed perfectly fitting our role descriptions is slim-to-none in the first place!). This caused us to say no to a number of candidates who may have actually been successful at a lower level. In our pursuit of better process, we'd forgotten the desired outcome: hiring people who could help BuzzFeed ship great products.

Stepping back

So, we changed it.

Last summer, I was reading The Alliance, a book by Reid Hoffman, Ben Casnocha and Chris Yeh, about how LinkedIn has changed the way it thinks about recruiting, hiring and retaining their teams. One recurring theme that struck me over and and over, was the idea that the employee-employer relationship is a two-way street: the employer (me, the company, the Product Design team) is looking for help with something (a product area, a project, a skill gap on the team), and the employee is also looking for help (more responsibility, development of particular skills, a bigger project than they've done before). Successful employer-employee relationships are built when the two align on helping each other, a trade of sorts. The company gets help in the areas they need, and in exchange they help their employees achieve what they're trying to get to.

The book gets more specific and you should definitely read it (I make no money if you click the link above!), but that idea really stuck with me. When I started thinking about our recruiting process, I decided to try re-framing it with two questions in mind:

• What skills does a particular candidate have that our teams and projects would benefit from?
• What is a candidate trying to achieve and are we set up to help them do so?

As a test, I left everything else exactly the same about our interview loops: we still had a pre-huddle and gave folks topic areas we wanted covered. We didn't ask them to change what they were asking or how they were asking it at all. We simply, in the post-huddle after the interview was over, asked each person to answer only those two questions above.

Simplicity works

The result has been pretty amazing. Not only are our feedback loops more positive than they were before, but they give us a ton more information about candidate's strengths and potential focus areas. This allows us to define a particular role in terms of what that exact product area or team needs rather than what our role document dictates. In other words, we can look for a candidate who fits the shape of the team and project, rather than the shape of our role docs. This gives us a ton of flexibility when hiring, and has led to a lot better decision-making (in my opinion, time will tell).

It's also been a good reminder for me that we should be mindful when iterating on processes. Looking back, it's clear that I thought we should iterate simply for the sake of making the process itself "better." Thinking about it now, there are many times I have fallen victim to the lure of making a particular process better. It's fun to iterate on a process! Particularly for design managers, since it scratches that creative itch and gives us something to refine. But in absence of solving a real problem or chasing great outcomes, improving processes can be dangerous and easily lead to narrow thinking and esoteric systems. It's common to find yourself having built a system that, while impressive on the outside, is unsuccessful at achieving its purpose. And while adding process is easy (too easy!), reducing it can be extremely difficult.

Now, I find myself stripping away processes that I've created for the wrong reasons, going back to an old UX exercise from my designing days - cut until you feel you can't and then cut a little more and see what's revealed. Now, when I think about a new process or change to an existing one, I ask myself, "Will this help us achieve what we're trying to achieve? If it makes us slower, is that trade-off worth it?" I approach any addition critically, and any reduction with curiosity rather than the other way around.

I guess, after all, management really is just like design.