How to Hire Marketers Like Vercel, Auth0, & Laravel

Today, we're talking about a topic that every single company, Gonto and I have advised, which is dozens. Every single one of them asks us about this. It's about how to hire fantastic employees and retain them and actually keep density of talent, density of trust as you grow and ignore all the hiring frameworks that your VCs are going to tell you to do. Okay. So last week there was no dev tool marketing news that we saw. We just saw deeply photos. So we decided this week, and you know, part of that was I was traveling and you're starting to get back on the saddle for advising, but we decided we're just going to talk about a topic that always comes up when we're advising. It's how to hire great people and build great orgs at startups and specifically dev tool startups. I think we have a lot of thoughts here, right? We do.

And we do have a lot of thoughts on Ghibli as well, but those we're not going to share.

Off topic. Exactly. We're not going to share today.

Right off the bat, when you were at Auth0, you were like employee number 10, right? Yes.

And how big was your org that was reporting it into you at its biggest?

So yeah, when I joined, it was just me. First hire of marketing was DevRel. I was doing DevRel. When I left Auth0, the team was 92.

That's pretty big.

It was a very big team.

When I joined, I've joined a few companies, a few dev tools, GitLab, Neo4j, Vercel as one of the first couple of marketers. I was first at Vercel and first at Laravel, all under 50 employees. And before Vercel, I grew a couple of teams up to maybe five, six, seven people. And then at Vercel, peak was 55 people. And then I gave away the SDR team and I gave away the DevRel team and shrunk it back down. When I ran

marketing at Vercel, which was after you, it was a lot lower than 55.

Yeah. Yeah. Well, because there wasn't DevRel, the SDRs weren't in there anymore. And there were a couple of cuts, you know, as the post-ZIRP days have done. Exactly.

So tell me a bit about like, how do you think about who should be the first hires and how should you think about your org when you're the first marketing hire?

I think we're both going to agree on this. There's no framework, there's no playbook that you should follow exactly. And if you follow exactly what your VCs tell you or your board members, the people who haven't truly operated, I think you're going to fall into some traps. And the common traps are, so I guess I'm not saying what you should do. First I'm saying like, this is the common advice, the common advice is, oh, you need a person for content and or product marketing. And usually your advice to get like some sort of like specialist on one area, and then they want you to fill in these different buckets. You know, all the classic titles in marketing, there's product marketing, there's demand engine, there's dev rel, there's ops, et cetera. Would you agree? This is the common advice.

I agree with that. I think in general, they give you like specific structures for everything. And I'm with you. Like, I don't think it makes sense. I'll give two examples, like one from Auth0, one from Clerk, both of companies. But interesting how the hiring patterns were completely different. But for Auth0, we started first, as we talked in some other episodes, doing like habits research, like understanding developers, what did they do on their day to day? What did they care about? What did they want to learn about identification, what they didn't, blah, blah, blah, blah. What we learned there was that they didn't give a shit about authentication and that they would search on Google if they got stuck, if there was a problem or something like that. So based off of that, we started to write content that was not about Auth0, but rather about how to do auth in React and Angular, et cetera. That started to work. So then the first two hires were actually developers whose only job was to write content. They would be DevRel now, probably. But back then, I would say we didn't even count them as much as DevRel because they only wrote content. There was no YouTube, no Twitter, no conference, no nothing. It was content. Eventually, we had a lot of content, but we couldn't really understand what was working and how to improve it. So the next hire was a data person who helped us build a data warehouse. And it's crazy, but at Auth0, the data team reported into marketing because I was the first one who was like, we need data. And eventually it was a team in marketing. But in the beginning it was, we have nobody, so let's start building it at a data warehouse or something so we can measure it. So then it was a data guy. And then we started to get more and more and more, but very weird structure, even weirdest data team existed in marketing. I actually gave the data team to engineering when we were at 60 mil in ARR. So a lot later, I would argue. At Clerk, it was different. For them, the strategy that worked the best, which we talked in other episodes, was YouTubers and working with influencers, getting YouTubers, etc. So the first hire that we discussed with Nick about doing was a person who actually managed YouTube and YouTubers. And that's it. I don't even know what the role would be called, like influencer, manager, maybe I don't even know. But Alex started doing that. Then his role expanded into other things and we started to hire other people to do other stuff. But the first hire was your job is to manage our YouTube channel that is working right. Just so that Nick, who was the head of marketing, actually now had time to explore and try new things. My main recommendation is you need to hire people so you actually get time again to be creative and to experiment. And once you find something that works, you again hire somebody to then again, you have time to be creative and experiment.

Yes. So I think first principle identified is what triggers a hire. And I think what I'm hearing you say is when there's something that you're executing on, and it's working, then that's a good time to basically buy your time back or buy your founder's time back or buy someone else's time back and allow that person to go do something else creative, new, experimental and basically lock in this activity. Because if you don't hire for that thing, like let's say events are working well, like let's say as early DevRel or I guess content is like a good one. If you're doing lots of content, but then you're being asked to do more and more strategic work, you're going to write less, you're going to make less YouTube videos, whatever. So you need someone where that's their job. They're locked into it so that it doesn't get lost.

It's more than that. Like that is one part that I agree. The other side, I think, is when you're doing something and executing and that execution is 90 percent of your time, you don't have time to generate chaos to be creative. And what I mean, chaos is let's try 10 different shit or talk to people or have some serendipity or something like that. So I think you're buying not only into somebody who will manage and improve it, but also you're hiring somebody so that you have enough time to get serendipity and actually be creative with something else.

Yes. You and I love creating a little chaos. Now, I want to say something here, because a common mistake I see is people think they need to keep executing on something because they were doing it and they're like, well, I need someone to do this. But actually, it's useless. Actually, sometimes you've been writing content for nine months and nobody visits the pages. The pages aren't ranking like they've got no SEO power and it actually doesn't matter. And you can just stop, not hire anybody for it and move on. If there's no support for an activity in your org, then just stop doing it. And you don't like the mistake people will make sometimes to say, well, it's not working, so I'm going to hire someone to make it work. No, just forget it. Find something else to do. Something else is obviously working in your business. Like, go do that more.

I don't see you, for example, when we were going from 40 to 80 mil in ARR, we got stuck, meaning we weren't growing as much in sign ups, in contact sales, and we were not going to hit the 80 mil in ARR. So we made something that was crazy back then. It was an idea from Jared Waxman, actually. An idea was called Code Yellow. The idea was half of the marketing team, which again at this stage was probably 50 people. So 25 people would stop doing what they do on their day to day, and they would only focus on four specific projects whose only objective was to drive more sign ups and contact sales. So half of the team stopped doing what they were doing because in the end we weren't growing as fast. And after doing some experiments, trying this out after probably three months, we started to grow again and we ended up being able to go from 40 to 80 mil in ARR. And one of my biggest regrets running marketing at Auth0 was that after we saw that this worked, we moved everybody back to their original team because we were having requests from sales and like, oh, I'm not getting the collateral that I'm asking because product marketing is doing this. We are not sending the emails that we should be sending because marketing ops is helping with this project. We're not improving the website because growth is working on this. And in the end, we caved in, I caved in and we sent the team back to do what they were doing. And Auth0 did well because then we did it again in like 80 to 160. But my question is, if we would have kept the team doing this crazy structure instead of agreeing to the pressure, maybe it could have grown even more. Maybe it could have been even better. Like, I don't know. But I think about that all the time. Like in that space, I caved in to the pressure to follow the org structure,

caving in that pressure. It's so it's the easy thing to do. I caved on it also related to sales pressure. Sometimes I'll make this little claim to fame, but I'm the first person I know of that had a RevOps title like way back in 2017, there weren't RevOps titles. I told my boss, hey, I want to own all of these functions. He's like, let's call that RevOps. And then it started popping up years later. I don't know if I set a trend or if I was just an anomaly, but whatever. So then years later at Vercel, I'm getting those same kind of complaints because sales people always complain. And I made a mistake of basically hiring a more the new traditional RevOps team. And I formed it in the same way that I was seeing other people form RevOps teams when it's like, hey, dare I say, you basically invented RevOps, like, why are you doing it like everybody else? That was a huge mistake. And I should have known, don't cave to the pressure, do things the way that you know is right, and don't add functions and people and headcount where you haven't seen it necessary.

So what we're saying, I think, is don't hire specifically what everybody tells you, like start testing things, trying things, and then start hiring. Ideally, your first hire is somebody who is willing to test and do multiple things, which is why I always say like first hire for DevTools should typically be growth or DevRel or both. And then from there, you expand on where you see it's working because growth and DevRel can be both huge jobs in the sense that they can do and try so many multiple things that eventually you start picking something specific. And I think we also both agree that org frameworks are probably not the best fit for your company. Like I think about these like founder mode and manager mode, org structures are great for manager mode, for founder mode, org structures suck because maybe you have you can do something better, something unique, something more special. So thinking about that, I think makes a huge difference. And the last thing I'll say is everybody asks me about frameworks. And if frameworks really worked every time, everybody would be successful. Frameworks don't always work. They depend more on how you try new things or how you improvise. I'm a big believer in improvisation. So just don't just blindly follow those frameworks.

Yeah, strongly agree.

How do you test people like so you started to build your team. You're not following the org structure. You're not following the frameworks, but you hired two people that you think are the right role that you need to hire. However, because these hires are weird because it's a new thing. It's something different. It's something unique. How do you test people? How do you know if they are working out? If it's not, how do you think all the first 90 days?

Yeah, well, let me start even there or even at the hiring process, because I think a lot of people do these like evaluations or tests or presentations now. And I have one simple hack. Let me give you all a framework that works every single time. Guaranteed. I'm just kidding. That's not what we believe. But this type of thinking has really helped me with a lot of hires. It's helped with the two things I'm always telling the hiring managers that work for me are to always think of density of talent and density of trust. And part of that second part, density of trust, is how can they take feedback? So a simple example is when you're hiring a writer. Often there's a written test of like, hey, can you write a blog on this topic, whatever? And I think too many people judge the first draft that they get. I don't actually care at all what that draft is like for me. The real homework is I'm going to go through that first draft and I'm going to leave three types of comments. I'm going to leave one comment that's just like, hey, reword the sentence to exactly this basically accept suggestion and move on. The second comment I'll leave is a, hey, I think you could reorder this or like, I think you should revisit the doc and kind of like, you know, something still specific, but a little more vague. And then I'll give a third type of feedback, which is totally vague. Like, I don't like this paragraph and then I just leave it at that. And what that does is if the person, one, the person has to want the job because they're going to go and work with this feedback. And two, you're going to see on their second iteration, how did they respond to your feedback, which is basically exactly the type of feedback I give in real life in that job. Like I'll tell people you got to reword this. I'm an Oxford comma guy, so that better always be an Oxford comma, whether you like it or not. And then like, I don't like this whole half of a page. Can you do it better? And then I go do another thing and like that's what it's going to be like working with me. And you can find a way, I think, in every like interview to see how do people handle feedback and a little bit of chaos and so on. So that's kind of my first answer to your question, which wasn't really about the first 90 days. It was about even hiring them. I don't know if you do feedback back and forth like that in hiring.

I know exactly the same, but I'm personally a big believer on exercises for hiring. Like everybody can fake an interview. It's hard to fake an exercise. And when I say everybody, I mean it's like it's not just ICs, it's going to be my director of product marketing or VP of product marketing, my comms person. Like everybody gets exercises. And how I think about it is I always do two different exercises. One is very specific. So it has a lot of data, a lot of specific things. And it's like, what would you do in this case? And it's more about to see the resolution and see what they do. The other exercise is always something abstract, like we're going to ship a new feature. These are our docs. How would you position this? How would you think about this? That's, for example, for product marketing. And what we check there is not just the final outcome, but rather the questions like what questions do they ask to clarify things, who they talk to, how they think about it. And in a lot of cases, we care more about that than the final outcome. But we do try to give them the most specific questions. So for us, it's not as much on the feedback. It's more on how they think about it, how they question, how they tackle a problem, how you try, how they try to solve it. What are the steps that they are taking? I do do what you're saying sometimes on interviews where they tell me something. And even if I agree with the thing, it's like I want to say something like, no, I think that's wrong. I'm just stay quiet to see what they do, if they double down or not or whatever. It sounds brutal.

It sounds brutal, but you have to do it because guess what? That's going to happen on the job. Like you can't be the thing about an interview. Anyone can fake an interview on both sides. And if you're faking it, if you're not actually helping represent what the job's going to be like, then you're also going to get false positives in working for you. And you're going to hate how they react. Like some people are like, this person can't take feedback like, well, did you try giving them any feedback? Did you try jamming with them at all in the interview process?

So my right hand at Auth0 was Carrie Oak. She's now the CMO at Okta. And I remember that I did something like this. And then first week she sent me a doc with some demand gen idea for developers. And my answer was, this is shit. That was it. That was my only answer. And then I gave her like more specific feedback, but she was like, what the fuck? In the beginning. And then eventually we both got used to working with each other and she was telling me like, I always know where I stand with you because I'm always going to speak my mind in some sense. So making people understand that I think is key. Every time I hire somebody, I always give them like a four or five bullets on how I work with them, what I expect and why. Just to set how we're going to interact or work together.

I love it. Yeah. One of my my first phone call with a woman that I've worked with at three companies now, I just told her about a problem we were having with like a Salesforce thing. And she immediately started jamming and I went, yeah, we already thought of that. That's not going to work because of this. And then she kept going. She kept ideating. And I was like, okay, we could totally jam with her. Anyways, let's think about the first 90 days though, because that's where, that's where the rubber really hits the road. So there are three, I think three problems that can happen. One, you might've messed up in the interview and you might've missed something and this person could be bad. They might not be able to actually execute the job that you needed to do. And if that is the case, your first 90 days is when you should do it. I actually tell people, especially because sometimes there are jobs that you need to be filled. You're not a hundred percent sure on the person you've interviewed a ton. You're not sure you're ever going to find a hell yes. Well, just put something on the calendar on their 90th day with the interview committee and the people who are working with them. And you can decide, I've only let go of, I think one person while doing that. And I've been pleasantly surprised by like others, the second reason why they might not work out.

Sorry to interrupt. I do something similar, but I put something in the calendar on the first 30 and then on the first 90 days, mostly just for myself to remember, like I hired this person 30 days ago or 90 days ago, but I think I'd fire like four or five with this. So maybe I'm either meaner or I'm worse at hiring than you.

Or I don't know where you're better at making a mistake. I think there's a good phrase that gets floated around is you can't be perfect at hiring. You can be perfect at firing. As brutal as it sounds, like we're here to get the job done. So then

I always told them, like we have a fire fast ideology. If you feel that somebody is not working out, we fire them ASAP.

Yeah. And the best gift you can give to your team is great coworkers. Nothing drives away great people than bad coworkers. That's what flipped the switch for me. I used to be very patient and try to rehabilitate people. But you don't have time to rehabilitate because your best people will leave. You'll miss your goals, et cetera. It's better to remove, not rehabilitate. A second reason why you might have to let someone go on the first 90 days is you might have messed up on the need for the role. There might not actually be the need for that role. Maybe you find out, huh? Yeah, our content never has really worked. This person's maybe doing a good job, but we actually don't need this role. And sometimes you can rehouse the person. I'm talking about rehabilitation. Don't do it. Removing. Yes. And then there's rehousing, which I've also done to great success before. So sometimes with those people where you're like, this role isn't working or they're not working for the role, but actually there's something else that they could do that would be great or there's not. And you've got to remove them that, you know, can kind of suck either way. Those are the two main things. I think I said three earlier, but I'm only thinking of two.

Last thing I have on hiring is I think there's going to be some times where people are really good, but you do not like them. I've had that multiple times. And I actually think it's important to hire people that you do not like or that you feel are extremely different to you reporting to you, because if they are really good at their job, which, for example, I have one situation on this, like they were good at their job. And I would hate some of the comments they made, but we needed to hear those things out and we needed people that were slightly different to us. And I think as your team grows, this is not for the first few hires, you need to hire people that are not like you and potentially people that you dislike as well.

Well, and to dig into that a little bit, there's a difference between maybe not like being someone's friend or seeing someone as your friend at work, but trusting them. Right. A famous relationship is the MythBusters guys. You remember MythBusters? I love MythBusters. They actually hated each other, like they didn't hate each other, but they had this mutual respect for each other's work and working together, but they just like sometimes just did not get along. And it's kind of like this interesting thing that one of them, Adam Savage, talks about a lot is they had such mutual respect, even though sometimes they would just drive each other crazy for their personalities, but they still had trust. And so they still had density of talent, density of trust. And so they had success like this whole podcast was about how to hire better at the very start and at the very most important stages of your company. And if you get this right and if you get really good at finding density of talent and density of trust, then success becomes inevitable in a way, because any team can respond to like a Gonto code yellow, like all hands on deck to fix a growth problem and they figure it out. And so many companies miss that, I think.

Agreed. Thank you, everybody, for joining. And if you have feedback or thoughts on this weird episode, please do share them. Thank you.