23 Jan 2021
The most impressive thing we built at Accompany was our team. Years from now, what I’ll recall most fondly won’t be the product we created or the outcome we had, but the incredible people I got to work with. Assembling such a high quality team was super hard, so I’d like to capture here how we went about it, focusing on the very first step: sourcing great candidates.
Our best source of candidates, by far, came from within our own personal networks. This is an amazing bit of bootstrapping to see in action: our first key hires landed us our next key hires, and so on. Once we hit a critical mass of like minded individuals who enjoyed working together, a positive feedback loop formed, attracting more like minded individuals in turn.
This is not a particularly novel idea, and lots of super stacked technical teams (Dropbox, for example) have talked about leveraging it in their early days. What I hadn’t heard them talk about (beyond “call up all your friends from MIT”) was how exactly to go about it.
We discovered a few key ingredients.
First, it’s essential that your first few hires be absolutely phenomenal. Do not compromise on this in any way! Since the first key hires will seed the next N hires, if the first are even slightly suboptimal fits, those next N will be too. Happily, the opposite also holds: if the first key hires are phenomenal, their referrals will be, and in a way where the value they add is multiplicative, not just additive, thanks to the magic that happens when you get these kinds of people together in a room. So be extremely intentional in making these first key hires and do not compromise in any way.
What does it mean for a hire to be absolutely phenomenal? This will look different from startup to startup, depending upon the kind of company you are building. But there will be shared traits:
The best way to be certain that someone possesses all of these attributes is to have worked with them before and/or known them for a very long time; ideally both. Which speaks to why recruiting the first ten hires or so (let’s call it the founding team) from within the founders’ and existing team’s personal networks is essential.
Once you have assembled the founding team, amazing candidates unfortunately do not just start magically showing up at your door. Drats! You have to get the founding team organically recruiting their friends and colleagues to come join in turn. This was a really big barrier for us to break through at Accompany. It ends up that getting people to tap their personal network is a tall order: they have to let the startup become a part of their identity, tie their reputation to it, and spend a lot of time and energy outside of their official job description on recruiting.
How do you overcome this? Like most challenges startups face, the answer is straightforward but difficult: hit growth and make it a fabulous place to work. If your startup is going places, and if getting there is fun, the referrals will follow. You’ve made it easy for everyone. The founding team would almost feel bad not recruiting their friends, and their friends will really want to be recruited.
That was how things unfolded for us. After some initial success where the founding team recruited friends purely on the mystique of a pre-launch startup, things stalled out. This coincided with when we entered into the Trough of Sorrow after we launched. Once we found product market fit and started to grow, people resumed recruiting from their personal networks.1
Even then, though, the actual practice of recruiting is a ton of work and takes discipline. Everyone has a million things to do, and especially for hackers, anything other than, well, hacking, feels like a distraction. So you have to rewire your own brain and the rest of the team’s to recognize that recruiting is real work, and to be very intentional about making time for it. Once a month, we’d sit down with everyone 1:1 and brainstorm who they might check in with, and how we could best tailor our recruiting process to that candidate’s needs. This could range anywhere from just getting coffee to inviting them to come meet the team over lunch to actually having them interview with us, if the timing was right. It was always all about the candidate and what would be best for them, given their current circumstances.
To that end, you have to treat these referrals with extra care. High quality referrals do not grow on trees! You already know the candidate is phenomenal — that’s why they’re a referral! And yet for some reason, it’s all too easy to lapse into the default of just sending them through your standard interview track. This is a mistake and a waste of everyone’s time. (Not to mention embarrassing for the person referring them.) Instead, you should treat them like a very special guest. Invite them to come have dinner with the team2 to let them gauge if they’re as excited about you as you are about them. If they are, invite them to come hack for a day (or more!) to test run what it’d really be like to work at your startup. This lets them pair program with a few different members of the team so that everyone can really get a feel for working with each other. For us, this ended up providing way more signal than a standard interview would have, and referrals loved it for the same reason. As an added bonus, if the referral did decide to join, they’d hit the ground running because they’d already started getting up to speed during the test run.3
Lastly, and underlying all of this, is that you have to be patient and hold the long view. Everyone will be looking to refer the two or three most talented individuals they know, and such talented people are rarely available. They’re almost always already working on something super interesting and pretty committed to it. That’s ok — you just take them whenever they’re ready. It’s the only way to get them, and it will be very worth the wait.4 But when they do become available, they tend to decide quickly. It’s too late to start the process then; you have to have already done the work.
So just focus on building a relationship between them and the rest of your team. Let them know that the door is always open, and that you’d love to work together some day. This approach is extremely liberating because it aligns your interests with theirs. It lets everyone be their authentic selves, without any of the awkward or superficial pressure that so often creeps into recruiting.5 And it grows the relationship beyond just recruiting: even if it doesn’t end up being the right fit, you’re now allies and can help each other in any of many ways down the road. But it more often will end up being the right fit, because by genuinely caring about what’s best for the candidate, you naturally nudge your startup towards being the answer.
The happy coincidence is that it’s best not to scale beyond your initial founding team until after you’ve found product market fit anyways. When you are still seeking product market fit, agility is more valuable than top cruising speed. You have to be able to craft experiments quickly and extract just enough information from them to determine the next ones.
A smaller team makes it way easier to rapidly iterate on the software itself. But perhaps more importantly, a smaller team can better handle the turbulence that comes with finding product market fit. Since those first few hires are practically cofounders, they have the fortitude for the uncertainty and enough equity to stomach it. The opposite is true for a larger team: it takes a lot of persuading (as it well should!) to set a new strategy and get everyone on board with it. By the time you’ve started turning the ship in the right direction, you should have already learned it’s the wrong direction and moved onto the next idea… You need to be a small band of X-Wings, not a lumbering Star Destroyer.
We made the mistake of hiring beyond the founding team pre-product-market-fit, and it sucked on two fronts: it was harder to recruit great talent during that period, and it was harder to remain nimble as we did. So wait to build out the team until you’ve found the crank and just need to turn it faster. Another benefit of this is that since you have no idea how long it will take to find the crank, hiring less extends your runway and buys you more time to do so.
I’m not saying you only need the founders in order to find product market fit (though this does often seem to be the case) or that you’ll only face this problem at the genesis of your company. Even big companies seek product market fit for new features and products… it’s not called company market fit, after all! So you’ll have to figure out how to keep your startup ethos imprinted in your company’s DNA as you scale in order to keep finding new cranks. But you’ll also have to turn to more successful entrepreneurs running much bigger companies for advice on how to do that ;) ↩
This was very natural for us to do, because we did team dinner every night. Which worked great, because most of the team was on the hacker schedule and so didn’t really trickle in until noon anyways. Team dinner allowed everyone to hack uninterruptedly without worrying about making plans right up till 7pm when food just “magically” showed up. (It would often go ignored for another hour as everyone kept intently hacking, presumably figuring they’d knock out just one more thing…)
Dinner was a great time to blow off steam, bounce ideas, get help on some code (laptops often featured prominently at our office’s kitchen table), etc., before getting back to our desks and coding till midnight… or beyond. It also created this magical rhythm where people wanted to have something new, even if tiny, to show off at dinner each night.
The reason team dinner and working late worked so well was that a) it was completely optional, and b) everyone really wanted to do it. This shared team conviction is one of the luxuries that comes with an early stage startup, where a tiny group of extremely talented individuals are all working together pursuing outsized upside.
But, things change, and as we scaled the team and expanded out from this kernel, we had to adjust. To new employees, dinners sure didn’t seem optional, and at some point people stopped wanting to stay for them. My gut reaction was to intransigently cling to team dinner: this is what makes us who we are! Thankfully, clearer heads prevailed and we found a better solution: just switch it to team lunch. Most of the same benefits, none of the downsides, and we still offered dinner for anyone who wanted it. ↩
There are of course a bunch of caveats with this. This approach takes up way more of the team’s time, so you should only do it for referrals that you know really are phenomenal. It presumes the referral has the time and the preference for it; if they don’t, just stick to your standard interview track. And it introduces some entropy, because you have different modes of evaluating candidates. In the end, though, it’s really a special case: it’s for candidates you already know are so good that it’s more like they’re interviewing you. Hosting them for a hack week is a wonderful, fun, and organic way to convey why your startup is great. The last caveat is that this is way easier to do in the early days when you’re still tiny, and gets harder as you grow (as is the case with most informal processes). ↩
One referral joined the team three and a half years after we first started exploring the idea! We just had to wait for the stars to align. ↩
When I was once looking for a new role, I was debating between two startups. Both seemed promising. The CEO of the first invited me to dinner only to be dismissive of concerns and questions I had about her company, pressure me into joining, and insist that I make my mind up in the next few days. The CEO of the second invited me out to lunch, where we earnestly got to know each other and explored the idea maze of what her startup currently was and potentially could become, for what snowballed into an entire afternoon. We ended with her declaring that she wanted to hire me right away, but that I should take my time deciding and that the door was always open. Which do you think I walked away feeling more eager to join? ↩