Below is an email I sent out to everyone at Infer in August of 2016. I’ve made some changes to clarify terms that the general public might not understand. Read only the bold sentences if you want a summary.
A little over a year ago Yang [one of the cofounders at Infer] asked me my opinion on the hiring process for the Data Analyst position, and I didn’t have a thorough answer at the time, but I said I would think about it. I have a tendency to take a long time to think something through, but when I’m done I usually feel like I have a crystal-clear answer. And I think that is what has happened in this case: I feel like I have a crystal-clear answer on how to think about hiring.
First, some background information:
In the process of organizing the wiki, I have noticed that there is a branching structure that a company will have in its wiki as it grows.
At the top level of a wiki, you specify general responsibilities and general tools. These are things that you expect everyone at the company to know. At Infer, tools that everyone has to know how to use include Gmail, Google docs, meetings, lightning talks, and the espresso machine. A responsibility for everyone at Infer would include something simple like locking up if you’re the last person to leave the office, or adapting to “the culture”, which is just the collection of all the unwritten rules that people follow. For example, one of these unwritten rules is that when someone on the sales team closes a deal and hits the gong, you stop what you’re doing (if your work isn’t urgent), applaud them for their accomplishment, and then listen to the announcement. If someone continually didn’t do that, they would be breaking an unwritten rule. (Tangent: Right now, as the name “unwritten rule” suggests, these rules aren’t written down, but I think they should be, because it can make it easier to debate their merits. For example, my working from a conference room seems to be breaking an unwritten rule to only use the conference rooms for meetings and phone calls, but that’s an unwritten rule I think should be debated. Right now we don’t have an organized way of debating these rules; writing them down on the wiki would give us a place to debate them.)
Aside from these general tools and general responsibilities, the wiki / company also starts to branch into different teams as the company grows; so, at Infer we could divide the teams up in different ways, but one way to describe the teams would be to say we have an Eng [Software Engineering] team, a DA [Data Analyst] team, a Sales team, etc. And like a branching tree, each of these teams’ wikis has the same structure that the wiki section for the company-as-a-whole had: each of these teams has responsibilities that everyone on the team needs to be able to do, and there are tools that everyone on that team needs to know how to use. For example, on the Data Analyst team, the machine-learning-model-building part of our internal web app is a tool that everyone on the Data Analyst team needs to know how to use. But it’s also a tool that’s kind of specific to the Data Analysts: SEs [customer-onboarding specialists] and engineers and SDRs [sales-meeting getters] are not messing around with that part of our internal web app as much. As for responsibilities: it is a Data Analyst responsibility to build a [machine learning] model. That is a responsibility that’s kind of specific to the Data Analysts; that doesn’t mean that no one else can build a model; an Account Manager could jump into our internal web app and build a model, or one of the engineers could jump in and build a model, but it’s kind of specific to the Data Analyst team.
The same pattern of “Responsibilities / Tools / Teams” continues as the company grows, with each of these teams branching into further subteams. For example, I think that Eng has started already to break into separate teams, so (as far as I can tell) we have the Machine Learning team, which has its own tools and responsibilities that apply to it; we have the Dev Ops team, and they have their own tools and responsibilities that apply to them, we have a Front-end team, and they have their own tools and responsibilities that apply to them. And similarly on the sales side, it quickly branched into the SDR team, the AE [sale-closer] team, and perhaps also the SE team and AM [customer-subscription-renewal specialist] team.
</background information>
Why am I bringing all this up? Because it applies to how you do hiring. When you’re hiring, you need to figure out which responsibilities and which tools you need that person to take on. And you can use the wiki (or at least this way of thinking about responsibilities / tools) to get a comprehensive list of what this person needs to be able to do and what you should measure them on.
So, for example, let’s let’s say we have a very specialized position, like being on the ML team on Eng. If you’re hiring someone for the ML [Machine Learning] team on Eng, you could compile a list of all of the responsibilities and tools of the ML team, and all the responsibilities and tools for Eng in general, and all the responsibilities and tools for the company in general, and that’s your list of requirements. Those are the things that the person needs to be able to do. And this includes cultural responsibilities like being proactive, communicating well, etc. All of those cultural responsibilities can (and I think should) be specified as responsibilities on the wiki.
Once you have that list of requirements then you simply devise tests for each of those requirements; you can you come up with some series of tests that measure that person’s proficiency on all of those different responsibilities and tools to see if the person will perform well or not. And again, when you hear “responsibility”, you might be thinking of things like “How good is this SDR applicant at cold calling?”, but it also involves cultural responsibilities like “How quickly can this person learn new tools?”, or “How much will this person encourage his coworkers?”. (Tangent: Again, all of those things can (and IMO should) be specified. It makes it easier for employees to figure out how they should be behaving to get promoted, it makes it easier to gauge when someone should be promoted, and it makes it easier to figure out who should get hired and where they should be slotted.)
So, that’s it. This seems to me to be a very clear and systematic method. I felt confused about hiring in the past, but this way of thinking about it makes perfect sense to me, and it makes it very clear to me what I would need to do, step-by-step, if I was going to be doing hiring. I think that if you document responsibilities and tools in this way, and if you come up with tests for measuring all of those things, then that seems like a method for hiring that will work pretty reliably.
PS:
It seems to me that this way of looking at hiring lines up very nicely with the hiring advice that Ben Horowitz gives in his book, “The Hard Thing About Hard Things”. He says that before you hire for an executive position you should do the job yourself for a while, because then you’ll be in a better position to understand what the person must be able to do, and you’ll know what kind of test to use to gauge their ability to take on that responsibility. Once you know what you need the person to do, you then develop questions to test for those abilities. I think what I described above is just a more-explicit version of the requirements-gathering part of the hiring process he describes.
STEP 1: KNOW WHAT YOU WANT
Step 1 is definitely the most important step in the process and also the one that gets skipped most often. As the great self-help coach Tony Robbins says, “If you don’t know what you want, the chances that you’ll get it are extremely low.” If you have never done the job, how do you know what to want?
(…)
The very best way to know what you want is to act in the role. Not just in title, but in real action. In my career, I’ve been acting VP of HR, CFO, and VP of sales. Often CEOs resist acting in functional roles, because they worry that they lack the appropriate knowledge. This worry is precisely why you should act— to get the appropriate knowledge. Indeed, acting is really the only way to get all the knowledge that you need to make the hire, because you are looking for the right executive for your company today, not a generic executive.
If you found this interesting, you can follow me on Twitter.