The founder’s guide to making your first few hires — Steven Bartel on recruiting at Gem & Dropbox

 So I thought one place we could sort of start this conversation. I'm hoping to sort of broadly cover what you figured out in terms of building an early team. So maybe not the, the 50th or 70th hire, but the first and second and 10th and 15th, and you've written a bunch about this in the past, but was hoping to kind of explore that in our conversation and maybe a place to start would be, when you think more broadly about talent that is hugely successful in that fourth seat or six seat or seven seat?

What's kind of different about that type of talent relative to when you were maybe operating at scale previously, if there is anything.

 That's a really great question. for early stage hires, thinking founding team members, The number one thing that I always come back to is doers, right? People who are actually gonna roll up their sleeves and, and get stuff done. I think there's also a certain scrappiness in the early stages.

That's really important. And in general, as opposed to at a later stage company where you need a lot more process, it might be more important to align with cross functional stakeholders in the early days of starting a company. You just need people who can do and build, What has that taught you about recruiting out of very large companies into call it the first 10 hires? And I think this is like a, a, a, a really interesting debated topic amongst early stage founders and CEOs. do you put it in the don't touch pile? Do you put it in? Absolutely. And what you need to do is get really good at filtering an evaluation in that pool, um, because you both have kind of this maybe bias towards action scrappiness dimension, you also have risk tolerance.

 And what does it say if somebody spent the last seven years at a certain scale of company? Um, but I'm curious when you think about recruiting somebody that came from that world into a five or 10 person company, what are some of the things you figured out, or what are the points of view you've, uh, developed.

 first of all, if you're a startup founder trying to build out your founding team, you might not have the luxury of always picking and choosing where you hire people from. Right. So you might actually have to. Expand your lens and hire people from big companies or hire people that have startup experience or hire people straight outta school.

 Right. It's so hard as it is to build out your founding team. So I, I don't necessarily think that it makes sense to apply a ton of filters on big company versus small company when it comes to, to hiring. I think the things that you need to make sure of are different depending on where somebody's coming from.

So if you're hiring somebody from a big company, I think that you absolutely wanna be transparent and give them a really great picture of what is it like to actually work at a small startup to make sure that their expectations are aligned. Cuz actually the, the place where I see this stuff go wrong is less about bringing on somebody and they can't figure out how to do the job.

It's actually more that they don't wanna do the job. Or that they're leaning away from certain types of important work to be done. that's where I've seen it go wrong more often is, is actually that you're bringing on folks that didn't know what the job was and then don't end up wanting to do it.

Um, so I think setting expectations is a really key part of that But then outside of that, I think there's still ways to really understand and test for people who are builders. Right? Folks actually rolled up their sleeves and, and built things potentially from scratch or maybe earlier iterations of things at larger companies versus somebody who took something and, and scaled the fifth or sixth iteration of it, or somebody who was really effective at working through others. which isn't really an option at a small startup

 Do you think about early stage interview process as being different in any way based on what the person's experience was, meaning that you have two candidates and you're hiring for the fifth engineer on your team. And one spent the last eight years working at two big cap tech companies. The other had, uh, two early stage startup experience.

When you think about those candidate personas, do you think about evaluation in different ways or it's all standardized in

 a little bit, um, on the edges. I, I, I definitely think there's there's room to test for slightly different things that you might be more concerned about depending on where somebody's coming from. But actually we did something completely. Non-conventional at gem for our first 10. Hires. And then we figured out how to scale it and it continues to be very non-conventional, but we actually had a lot of our early hires come and work with us for a day or two days, or if they were free and in between jobs, we'd just say, Hey, come, come work with us for a few weeks and really understand what is it like to work at a startup?

And actually the, the funny thing was this was a lot less about evaluating them. It was a lot more about them getting comfortable with joining our small startup and really understanding what that would look and feel like, uh, coming from a larger company but the added benefit of that is they gain such a clear understanding for what the role would be, 

But we also. Got a lot of signal on just hands on experience. What would it be like to work with this person? And now we, we weren't able to do this with everyone. Uh, a lot of people that interviewed with gem had full-time jobs, but even in those cases, we would actually have them come and work with us for a day, if possible, um, even to get, get some of that signal on both sides.

We actually had a lot of people self-select out of joining our company in the early stages because they realized that a startup just wasn't the right thing for them.

 That's interesting. So to pick that apart a little bit, I guess two things pop to mind when you think about, uh, a candidate coming into, and let's just say a one day job simulation co-working what percentage of the time did they opt out? Versus what percentage of the time when a qualified candidate came in, did that experience give you net new information about that person that made you feel like they weren't a fit for

 It's a good question. So I, I will say that our approach to building out our early founding team was to do a lot of hiring from our network. And so a lot of the folks that we were bringing on board to do one day or two day or three week work trials were folks that we knew and, and we at least knew of their reputation and they knew us.

Um, so part of it was, was just alright, like. There's a little bit of, um, trust on both sides. Let's just see what this would feel like in practice. Now in practice, I'd say two thirds of those folks, maybe self-selected out of joining gem and a lot of times it wasn't necessarily gem. It was just, oh, wow.

This is, this is what it's like to be at a really small startup I might actually optimize for something different. And then, um, we absolutely got some signal on some candidates as well. And I'd say maybe a third or a half of them, we decided to not move forward with, but this, I think the signal that both sides got from a process like that was way higher than anything you could ever get from.

Whiteboard coding or, working through a few algorithmic pro problems over the course of a few hours. Um, now I share all of this, knowing that it's, it's, it's pretty actually UN unconventional and I, I don't necessarily have a playbook for recommending that, that every startup founder, founder do it.

Um, but, but that's actually how we hired our founding team for the most part, our first nine or 10 engineers.

 I think when you talk about, I mean, the extreme case of this that you're getting at is contract to hire, but I think it's interesting kind of this middle ground, this one or two day, um, kind of working together, you know, most founders are like, well, the very best candidates have multiple offers and they're not gonna do that.

If you, if you had to guess, if you, if you weren't doing so much referral based recruiting or in network recruiting, do you think that can work or maybe as you've started to scale and modify this, do you think people's intuitions around that may be wrong?

 I think that an approach like that mostly works for referral based in, in network hiring, which, which I still believe for your first 10 hires, building out your founding engineering team is generally the right place to focus. Um, there, there are different versions of this that, that we've refined and scaled over time.

And now we have a, I think a three or four hour. Pretty hands on, uh, coding exercise. That's standardized. Everybody goes through the same thing. I mean, the early days of jam, we were doing this, this wild thing where we would come up with a different project for every single person that interviewed with us.

And oftentimes some of these projects would even ship to real customers, which was kind of wild for an interview process. Now, I will say it was a lot of, uh, extra work from the full-time engineers at gem to make those projects successful a lot harder and more work to, to get those across the finish line than if they were to just code them themselves.

But so, so really it was a device for letting people learn about what it would be like to work at an actual startup. Um, but then over time, we, we did refine that and shorten it down to a couple hours, uh, real hands on coding exercise with several checkpoints with. Different interviewers. So to speak across the team where you would actually collaborate on real problems and do a code review and stuff like that.

Um, so there, there are ways to scale that and, and really boil it down to just the core pieces. But I don't know that we would necessarily would've landed there if we started from scratch. I think that was largely an evolution of, of this thing that we tried and had a lot of success with in the early days of having people just come and try working with us.

 On that point, when you go back to those first 10 hires and you kind of did these one or two days, or maybe a little bit longer projects with them, uh, how did you architect that time? Um, and was it sort of a very, you know, Sally's coming in on Wednesday? What is she doing or how was that crafted?

 Yeah. We, we put a lot of prep and thought into it. we had a running list of projects that we thought would be. Good projects for candidates to bite off. Um, we had to actually put a lot of time and energy into making sure that it was really fast to get your, your dev set up And, uh,

 Yeah, I, I was curious cuz I think sometimes it takes a day or two for a new hire or more just to get set up from a development environment

 it's really funny. One of the little side benefits of doing it this way was our dev setup would always take, you know, 10, 15 minutes max at any given time. Cuz we knew we we'd have candidates that needed to get going fast. 

Um, we would have conversations with folks before they, to. Give them a little bit of an overview of what to expect and, uh, share a little bit more about the technologies we use and stuff like that. So there'd be some prep. Um, and then there would be check in points. I remember that was really important.

Uh, we would check in an hour or two in make sure that they had dedicated time for, for questions and, uh, to unblock people as they're getting going. Um, there would be a, a check in point about a third of the way through about two-thirds of the way through, and then near the end, there there'd be more of a code review, and ideally we'd have time to do a iteration based on some feedback there as well.

 When someone came in for one of these projects and you reflect on sort of how you all operated or behaved was, is it, was it a completely normal Wednesday? Were, were you thinking about salesmanship and Sally's coming in and we need to get her excited about what we're doing at. Like what was sort of the interplay between business as usual versus this is a sales and marketing activity.

That's gonna commence at 8:00 AM or 9:00 AM on

 That's a really, that's a really good question. And the experience would vary a little bit, but my approach and I, I think something that served us pretty well for a lot of the folks that we were evaluating and, and trying to convince to come on board was actually to try to give them as, as clear of a picture as possible of what it would be like to be on the team.

And so if we had a candidate in, on a Monday, we would absolutely invite them to our weekly standup for 30 minutes to start the day. And they could just feel like they're a part of the team and hear everybody's updates. If we had an exciting prospect conversation on a Wednesday, We might do a little bit of a detour and say, Hey, why don't you come right along this, this customer or this prospect conversation?

And I, we would've no clue how that conversation would go but a lot of the times, like the reception to our product would be really strong or, or there'd be some really interesting thing that we could learn. And we could debrief a little bit afterwards and just give them as much of a taste as we could for what it would actually be like to work there.

Um, the, the types of things though, that we did gravitate towards over time, which were more for the candidate and not just a part of like every day company, um, tended to be around things like, uh, dinner. So, you know, if we had somebody come and do a day of working with us, or two days of working with us or a week or two of, of working with us, we'd try to do at least one dinner with the team so that they could get to know their, their teammates social.

 given your point about largely pulling from various forms of your network for those first 10 hires and kind of looping back to what you were talking about in terms of, um, you know, hands on doers, builders, et cetera. Was there anything that, you did to sort of identify those people in your network, or let's say you worked with a hundred people closely at Dropbox before you started and you sorted those by those that you thought would be the best fit other than them being sort of scrappy builders.

 Was there anything in your own little internal algorithm that helped you sort that talent for the people that you thought could be a really great fit?

 I think that given the product that we build. Given a lot of what needed to be done at gem. We oftentimes were starting with a lot of the people that had pretty strong, full stack experience. I think that at, especially at large companies that the larger you get, the more specialization there can be.

 So if we had to stack rank, that would be one of the things that floated at the top in terms of folks having a little bit more of a breadth of experience. But with that said, if we knew of a really talented topnotch infrastructure engineer, we absolutely talk to them.

and see if we could get them excited about the job, which would be talking to customers and building full stack. Product end to end. And generally we felt that if, if they were strong engineers and we could get them excited about the job to be done, and they were able to come in and do a full stack project with us, that was, that was somebody that I would, I would make a hiring decision on any day.

 How did you develop your narrative for the company in the early days, the narrative that you used to recruit talent? And I'm particularly curious because I would think it face value. Hey, we're creating some recruiting software for sourcers and, you know, blah, blah, blah, blah, blah. When you think about the craziest, most ambitious technical folks that you know, out of the gate, I'm not sure that, you know, connects with them immediately. And so other than I'm sure many of them were drawn to you, you had interactions over a long period of time. Did you have a specific narrative or a way that you went about selling the opportunity when maybe this one sentence description, wouldn't jump off the page for really ambitious technical folks.

 Yeah. So I. The things that we shared with candidates to get them excited about gem. It was different from the pitch that I was used to at Dropbox at Dropbox, we could talk about all of the, the hard technical problems that we had, the scaling, the infrastructure, supporting hundreds of millions of users, right?

So we had to find a very different, unique reason to join gem, uh, from what I was used to at Dropbox and what from Nick, my co-founder was used to at Facebook. But the things that we got people excited about were were different.

We got people really excited about learning about all the different aspects of building a business. We, we attracted a number of people who thought they themselves might go on to start a startup. One day we found engineers that were excited about learning more about talking to customers and riding along sales calls and customer success calls and learning about fundraising and how to operationalize a business. And one of the, actually the, one of the core values that emerged out of all of this was, was this value of transparency, which, you know, we believed was the. really important for, uh, building a successful company because it meant having a, having a transparent company means everybody has as much information as possible to be able to do their jobs effectively.

But the side bonus, the side benefit for a lot of the early funding team was they would get a lot more visibility into how companies work and, uh, gain this unique exposure at a place like gem, where if they wanted to one day they could go on to start their own company.

 How did you convey those things to candidates? And was it as simple as, Hey, if you join here, you know, you're gonna get to not just be an engineer, but be more holistically involved in the product building process or the company building process, or did you package this up or, or, or sell it or have it land with candidates in a specific way?

 Yeah. We, we talked a lot about this with candidates and. I mean, we would go as far as to have candidates sit in on prospect conversations and customer conversations to get a taste of what that was like during their interview process. So it wasn't just talking at them about how we were gonna do all these things.

It was actually walking the walk and giving them a taste. the other thing we did is, is we had candidates talk to one, you know, once we had that, that early inception of a founding engineering team, once we had those first 1, 2, 3 incredible founding engineers, we'd, we'd set them up to talk directly to each other. And, um, you know, the next candidate we were recruiting could hear about these unique things and, and why these other founding engineers joined and how all these things had become true for them.

So it was a little bit of showing and then a little bit of. Telling through the people that had already joined.

 I'm curious, you know, you are effectively the first hire of the company as the founder and CEO. And so why do you think you've had such outsized success? Or if you look at your own abilities or past. What is it about you that you think in enabled the, both the success of the company, but you to be successful as a founder and CEO?

 Wow. Uh, never really thought of myself as my first hire, but I GU I guess I was the founding engineer, number one. Um, uh, no, it's really interesting. I, I think that for me, the, the thing that's helped me be successful and, and continue to be successful in scale in my role is I'm always learning. Um, actually at, at gem I've I've had to.

Pick up so many new things. My background is engineering, but at gem I've actually focused almost all of my time on the business side, sales, marketing, customer success, people, finance BI ops. And so for it, for, for me, it's, it's been really key to wrap my head around so many new things that I've never seen before and, uh, constantly be learning.

So I, I think I owe a lot of my success to some incredible mentors that I have outside of the company who have helped help coach me on all of these different aspects, every step of the way.

 Uh, maybe on that point and we can kind of take a, a quick, uh, left term before we come back to some of the early hiring conversations. one of the topics that I've, I've long been interested as the idea of commercial orientation. Um, and I think in product folks and engineers, it, it tends to be a population of, of folks that oftentimes actually don't spike in, in kind of commercial orientation, or how do you take a thing and actually sell it in a scalable, repeatable way, I'd be interested to hear more about your journey from engineer engineering manager, to product builder and business builder. And were there certain unlocks that you figured out along the way, that you think had an outsized impact or allowed you to actually cross that chasm in some way.

 Yeah, there's one big thing. And I think this can make up for a lot of a lot of things early on. Even before we started gem, I internalized the importance of talking to customers. And I think I owe a lot of this to one of my close friends and, you know, who's ultimately become a mentor of mine. Uh, Spencer S skates he's he's the founder and CEO over at amplitude.

And I loved to pick Spencer's brain in the early days and how they got amplitude off the ground and what they did. And he would always come back to customers. You know, Steve, go talk to customers, Steve, what are customers saying? Oh, they don't like that idea that you're thinking about. What do they like, what are their top three priorities?

And, there's this trap that a lot of us, as, as technical folks fall into where we're really comfortable building product and writing code. And there's this trap that we fall into where we dream up a product we could go build, or some technology we could bring into the world in search of a problem and go build it and hope people will come.

And I, I, I think that's where a lot of. Folks go wrong. And, and because me and Nick, we were very well aware of this blind spot of, of having a lot less commercial experience, we told ourselves that before starting anything at all, we would go talk to at least 50 customers.

about the, the problem that we're trying to solve, how we're gonna solve it. And we would hold ourselves accountable to having pilot customers lined up and ready to go before we even wrote a single line of code. And what we tried to do is swing the pendulum in, in the complete opposite direction and lean into the part where we were worse at and knew least about I find the topic of talking to customers in the early days and as you're scaling a business, one of those things that make sense, but if you look at a founder and CEO's calendar on a weekly basis, it doesn't reflect the importance of that. And why do you think that is.

I think that for a lot of us, myself included until, until I did a lot of it, talking to customers can be pretty uncomfortable. It can be pretty discouraging. I remember the first many conversations we had with customers actually, before we landed on gem, we would get so excited about different ideas of things we could build.

And, um, you know, how we were gonna change the world and we would walk into a customer conversation and it would fall completely flat or they would get disinterested. Or we couldn't get to one or two folks coming out of 30 customer conversations who would be willing to sign up the pilot. 

So it was uncomfortable. And I think that there can be this urge to focus on actually the, the things that you're good at, the things that you're comfortable with instead of the things that are hard and, and most important and at least that was my personal experience. And that's my theory 

 So, so if you were to create, uh, Steven's five minute class for how to talk to customers or talk to your first 50 potential customers, right? You're an engineering manager at company X, and you're thinking about building something from scratch, and you agreed with the idea that I'm gonna talk to 50 people before I do anything.

What's sort of the few minute class on how to actually do that in the most effective way possible.

 Oh man. And I wish I, I wish I had this class. when I was getting started, cuz so much of this we learned by trial and error and just doing different things. Actually the, the number one. Piece of advice that I would give is, is just to get going you could theorize and think about it and, and try to put all sorts of structure around it.

 But there, there really is no substitute for just getting, going and, and going and talking to customers and, and trying things out and seeing what works and seeing what doesn't. And Hey, if your first five, 10 customer conversations are a flop, you can go file in five or 10 more to talk to it's , it's not like you're ever gonna run outta cus potential customers that you could talk to.

And if that's the case, your market's probably too small so you might have bigger problems to worry about. But if I were to think back to some of the learnings and things that we converged on from those early days of talking to customers, I think that we, we generally did converge on a few phases to these conversations in the first wave of conversations, maybe with the first 10, 15, 20 customers, we would spend a lot more of our time.

learning about their world and validating the problem that we were thinking about solving and whether it was actually a top priority. And I think that ended up being pretty important because if you jump straight into the solution space and don't spend enough time on, is this problem even worth solving, you might be missing the higher order bit.

There. One thing that we would always do as we were validating the problem statement and, uh, just learning about their world and their priorities is plant the seeds that Hey, like, we're really excited about this. We're gonna go talk to 15, 20 more customers. And if they're all feeling the same pain point that you're talking about, we'd love to circle back and get more time with you to walk.

you through our learnings and, and talk about how we're gonna potentially approach solving this problem. So you can always tee up that next conversation to jump deeper into potential solutions. So we did that and the second phase would be a little bit more about how are we gonna approach this? What are some of the value props we're gonna focus on?

Um, and then that would tee up the third phase, which is . We didn't have a product, we hadn't wrote written any code. So how do we actually bring that to life and convince some people to sign up as pilot partners? But we did, is we just built ball balsamic mocks? Are you familiar with the tool balsamic?

 I, I feel like it's less en Vogue, but probably five years ago it was the, it was the Figma of

 I don't even know if it was in Vogue back then. I, I just, I didn't didn't know about any other software and.

 um, but one of the things I do love about balsamic is, is that it is low fidelity and kind of by design. So, so people don't expect higher fidelity, good looking mocks. And you could literally, uh, mock up a few core workflows in a few hours in balsamic. And we would show that to customers as here's the MVP that we're gonna build you and try to convert, to getting folks to say that they would be pilot partners 

 When you think about that early process of talking to customers and refining the value prop and refining the early product and understanding what's going on in their world. Did any of those ideas translate over to the way in which you thought about recruiting the early.

 Mm. Yeah. I mean, one of the advantages of building recruiting software and working with so many amazing companies is we had a ton we could learn from our customers about how they were hiring that translated into how we, we built our early team. So being in the recruiting and town acquisition technology space.

Like I think even more than most founders, Nick and I leaned into putting in the hours and putting in the time to building an incredible founding team, um, both on the engineering side, but also on the go to market side with some exceptional talent, um, because building the right early stage founding team, that's the foundation upon which the rest of your hiring is going to be built.

And it's what it's, what can really propel your company forward. we knew from the early stages that, yeah, we'll, we'll have a career site that we can direct people to, but. Posting a job. Like that's, that's not gonna be how we hire. That's not gonna be where we get a bunch of applicants.

And so we knew that lesson from early on, I think a lot of founders maybe don't realize that though, is that actually early stage hiring is all about going out there and finding people and pulling them in versus waiting for them to apply. But, you know, that was also the core thesis behind gem . And, and one thing that we, we, we learned from all of our customers.

 One of the things that I think is, is kind of interesting about both you and Nick is that you each kind of had a couple internships, but basically had one formative technical experience

 you at Dropbox and Nick at Facebook, how did you figure out what are the things you wanted to take from those companies and apply at gem versus back to first principles or do it differently.

 because at that point in time, Kind of the 20 10, 11, 12 sort of that time was both when Dropbox and Facebook were the most dominant brands, the Silicon valley, darlings of that generation. And I would think it would be easy just to do a lot of copy paste copy.

 Well, we did it this way at Dropbox. Well, we did it this way at Facebook. Um, and so I'm interested. Did you intentionally think about what are the things we want to take versus not?

Or was it a kind of a much more organic process for you

 we did actually, there was some, uh, or organic process to it, but there was also a lot of intentionality behind it. And let me just maybe share a few examples Facebook. A lot of the way the product was built and the way that folks made decisions. And I interned there. So I know a little bit of this but Nick was there for a long time, so you can speak to this even better than I can, but Facebook was very, ship off and shipped fast and then run experiments and rely on data to make decisions. We actually, we loved the ship off and then shipped fast. And that actually became one of our core values around velocity.

Um, but Facebook as a large consumer company, and to some extent, Dropbox as well, had the luxury of having hundreds of millions or, or billions of users. And in, in that world, you can rely a lot more on experiments and data to make decisions, whereas for gem. And I think for a lot of B2B SAS companies, relying on customers and talking to customers is, is the right way to make decisions.

So, so that led us to a second value at gem, uh, around customer focus at Dropbox, a lot of our decisions, at least while I was there for new products were design led. Um, and actually apple works very similarly to this. where a lot of the way they build product is, is design led. Um, and I think that can make sense for certain companies where you kind of need to figure out new products and, and do it based on a lot of vision.

Um, but, and, and where you have to do these big releases, that roll out to tons and tons of users all at once. And, and for, for Dropbox, it was actually really important that when we ship stuff, because we had so many users that it worked out of the gate and because we were dealing with people's files and data, like attention to detail was really important for gem though.

We decided that we wanted to be more scrappy than that, um, and that we would make as many of our decisions as possible by going and talking to customers and understanding what they want. And that actually we'd be okay with. Not sweating every detail because that might slow us down a little bit. I wanted to loop back to where we started and, and pick up the thread on some of the, the early things you figured out around, um, hiring. And one of the things that you sort of talked about at a high level was the fact that a, a bunch of the early hires just came from people that you had interacted with, or were somehow in your network.

Photo of Steven Bartel leaning against a wall

632273d19f63dd3efb36e218

 Gem co-founder Steven Bartel shares tactics for recruiting the first 10 hires, from sourcing and nurturing passive talent, to structuring interviews.

The founder’s guide to making your first few hires — lessons from Gem & Dropbox

Gem co-founder Steven Bartel shares advice for the first 10 hires, from sourcing and nurturing passive talent, to structuring interviews.