Hank:  Today we're talking about a topic that every single company, GTO and I have advised, which is dozens. Every single one of 'em ask 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 gonna tell you to do.

Okay? So last week there was no dev tool, marketing news. That we saw, we just saw ghibli 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 gonna 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? 

Gonto: We do, and we do have a lot of thoughts about Ghibli as well, but those, we are not gonna share. 

Hank: Off topic.

Gonto: Exactly. We're not gonna share today. 

Hank: But when you were right off the bat, when you were at Auth0, you were like employee number 10, right?

Gonto: Yes. 

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

Gonto: 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. 

Hank: That's pretty big. 

Gonto: That's, it was a very big team. 

Hank: Yeah, when I joined I, I've joined a few companies, a few dev tools, GitLab, Neo4j, Vercel, as like one of the first couple marketers.

I was first at Vercel and first at Laravel, all under 50 employees. And before Vercel, I grew a couple teams. Up to maybe 5, 6, 7 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.

Gonto: When I run marketing at Vercel, which was after you, it was a lot lower than 55.

Hank: Yeah. Yeah. Well, 'cause there wasn't DevRel, the SDRs weren't in there anymore and there were a couple cuts, you know, uh, as uh, the …. are done. 

Gonto: Exactly. Um, 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?

Hank: I think we're both gonna 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 gonna 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 gen, there's DevRel, there's ops, etc. Would you agree this is the common advice? 

Gonto: I agree with that, and 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 how it's research, like understanding developers, what did they did on their day to day, what did they care about? What did they want to learn about authentication, what they didn't, blah, 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, 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 DevRe; 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 the 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, data warehouse or something so we can measure it.

So then it was a data guy. Um, and then we started to get more and more and more, but very weird structure, even weirder is the data team existed in marketing. I actually gave the data team to engineering when we were at 60 mil in a ARR, so a lot later um, 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, et cetera. 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.

Hank: So, first…

Gonto: My main recommendation always 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 ex… experiment. 

Hank: 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 lockin this activity. Because if you don't hire for that thing, like let's say if events are working well, like let's say as early DevRel may…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 gonna write less, you're gonna 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.

Gonto: It's more than that. Like that is one part that I agree. The other side I think, is when you are doing something and executing and that execution is 90% of your time, you don't have time to generate chaos, to be creative. Like, 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 are buying not only into somebody who will manage and improve it, but also you are hiding somebody so that you have enough time to get serendipity and actually be creative with something else. 

Hank: Yes, you and I love creating a little chaos. Now, I want to say something here. 'cause 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 is say, well, it's not working, so I'm gonna 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. 

Gonto: At Auth0, for example, when we were going from 40 to 80 million in ARR…we got stuck. Meaning we weren't growing as much in signups, in contact sales, and we were not gonna hit the 80 million ARR. So we made something that was crazy back then. It was an idea from Jared Waxman actually, and the 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 signups 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 million 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 again, like 80 to 160.

But my question is, if we would've 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 into the pressure to follow the org structure.

Hank: Mmm 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 Rev Ops title. Like way back in 2017. There weren't Rev Ops titles. I told my boss “Hey, I want to own all of these functions.”

He's like, “let's call that Rev Ops.” 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, I'm getting those same kind of complaints, 'cause salespeople always complain, and I made a mistake of basically hiring a more, the new traditional Rev Ops team. 

Gonto: Yep. 

Hank: And I formed it in the same way that I was seeing other people form Rev Ops teams. When it's like “Hank, dare I say, you basically invented rev ops. 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.

Gonto: 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 dev tools 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. Then eventually you start picking something specific. And I think what 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, and I'm…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, on how you improvise. I'm a big believer in improvisation, so just don't just blindly follow those frameworks. 

Hank: Yeah. Strongly agree. 

Gonto: 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 about the first 90 days? 

Hank: Yeah, well, let me start even there, or even at the hiring process. 'cause 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. Uh, that's not what we believe, but this type of thinking has really helped me with a lot of hires. It's helped with, uh, 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 gonna go through that first draft and I'm gonna leave three types of comments. I'm gonna leave one comment that's just like, “Hey, reword this 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 gonna go and work with this feedback, and two, you're gonna 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 gotta reword this.” I'm an Oxford comma guy, so there 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 gonna 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 dunno if you do feedback back and forth like that in hiring.

Gonto: I don't do 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. Like it's not just IC’s, it's gonna 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 gonna ship a new feature. These are our docs. How will you position this? How will 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 do they think about it? And in, in enough cases, we care more about that than the final outcome.

But I do, we do try to give them the more specific question. 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 do you try, how they try to solve the, 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, I'm gonna say something like, “no, I think that's wrong,” and just stay quiet to see what they, they do if they double down or not, or whatever.

Hank: It sounds brutal. 

Gonto: …a couple times. 

Hank: It sounds brutal, but you have to do it because guess what? That's gonna happen on the job. Like you can't be… The thing about an interview, anyone can fake an interview on both sides. 

Gonto: I agree. 

Hank: And if you are faking it, if you're not actually helping represent what the job's gonna be like, then you're also gonna get false positives in working for you and you're gonna hate how they react. Like some people are like, this person can't take feedback. I'm like, well, did you try giving 'em any feedback? Did you try jamming with them at all in the interview process? 

Gonto: Exactly. So my right hand at was Carrie Oak. She's now the CMO at Okta.

And I remember when… 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. Um, 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 gonna speak my mind in some sense.

So making people understand that I think is, 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 gonna interact or work together. 

Hank: I love it. Yeah. One of my, my first phone call with, uh, 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 gonna work because of this. And then she kept going, she kept ideating. I was like, okay, we could totally jam with her. 

Anyways, let's think about the first 90 days though. 'cause 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 'cause 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 gonna find a hell yes. Well just put something on the calendar on their 90th day, uh, 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… 

Gonto: Sorry to interrupt. Yeah, 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 fired like four or five with this.

So maybe I, I might, I, I’m either meaner, or I'm worse at hiring than you.

Hank: Or I don't know. Or you're better at making a mistake. I, I think there's a good, 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.. 

Gonto: I agree.

Hank: Get the job done. So then… 

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

Hank: Yeah, and the best gift you can give to your team is great coworkers. Every, 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, 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. 

Gonto: 100%. 

Hank: A second reason why you might have to let someone go in 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, 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. Like, 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 gotta 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. 

Gonto: Last thing I have on hiring is. I think there's gonna 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, in Auth0 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. 

Hank: 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?

Gonto: I loved MythBusters. 

Hank: 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, um, one of them, Adam talks about, 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 cold 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. 

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