Austin Hay: preference

Transcript context

…So, the first thing that I always gravitate towards is just intellectual curiosity. And I know that's very, maybe a little bit overrated, but I think you can tell pretty quickly if somebody's just interested in the world and learning things. And the thing about third party tools is you are constantly learning. You'll never be an expert in everything because there's way too many tools to be an expert on, I forgot what publication, I think it's MarTech editor in chief or something. There's a publication that I subscribed to and everything is classified as MarTech and the diagram is huge, like cover a wall. Now I don't believe everything like that is MarTech, but even if a fraction is, there are way too many tools in technology to ever be an expert. So, you have to be both very interested in learning and very willing to quickly learn if you want to be in the space. And so I generally look for intellectual curiosity as the first sign. The second thing that I think helps people a lot who have intellectual curiosity is they're scrappy in engineering. They might not be the best engineer possible, but they know how to get around. They know JavaScript, they know Python, they can read API documentation and make an API request. They have enough base knowledge to basically understand how to solve a problem that an engineer might do even if they themselves are not an engineer. Now obviously you can get lucky sometimes and you'll find the engineer who never wants to be an engineer again and decides to move into something less technical. And in those cases they're super powerful, but I haven't met a lot of those people in my life. And also there's just some business dynamics to it. You could probably make more as a backend engineer than as a MarTech guy. So, you probably just pursue the pathway that makes more money. It's like a little bit of a utility function. So, I look for intellectual curiosity. I look for basic engineering scrappiness. And as a side note, I would say lots of people out there, the advice that I give them is you don't have to go get a software engineering degree. You can teach yourself, I am self-taught. You can take a coding academy online. I think you get enough knowledge through being able to do web programming or some type of backend programming. So, I would say it's not more than a six-month investment for anybody to really get the skillset that's needed. Obviously once you get the skillset, you can build upon it with years of experience afterwards. But if you're new to the space and you're in marketing ops and you want to get more technical, or if you're a user acquisition manager who did paid performance, but you're like, I really want do things end to end. You can just go pick up some software skills and you probably are going to be pretty dangerous from that. And so those are the two things I gravitate towards. There's obviously many more, but those are the first two. pick up some software skills and you probably are going to be pretty dangerous from that. And so those are the two things I gravitate towards. There's obviously many more, but those are the first two. The questions that I like to ask is what does I like to ask people how they prepared for the interview. This is not, I can't take credit for this. My wife told me about, gave me this idea and I loved it. I think it was a16z partner. But I love the question because when you ask, hey, how did you prepare? You're really asking how does the person think? How did they plan? How did they take things seriously or not? What did they read? What did they do? And if you have to prompt them to tell you all the things they did, then they're just not a systems thinker. But if they're like, hey, actually I read these things, I did this. I woke up, I went for a run. The more interesting complex the answer, the more interesting complex the candidate. And so I love the question because it just gives you a really good understanding of the person on a whole, like right out the gate. And then the other question I like to ask is I like to ask, so you're coming in tomorrow to our marketing tech system and by Friday you have to write up a report on all the things we should change. What do you do? And I like to ask that question because it pretty much signals out people who are biased versus not. People who have tooling biases will immediately just like, we should implement this tool because I used it before and I really like to hire people who are not tool specific, who are more tool agnostic and they think about tools as being things to solve problems as opposed to tools being things that you just solve because you've already solved it one way. This isn't a gripe and it's certainly not intended to slice at PMs, but one of my observations of a lot of PMs is they just pick the tools they've already used before because it's easy and it's a shortcut for them, which I understand, but problems are not always the same. So, tools shouldn't always be the same. So, I like to pick people who think about the problem set and the solution space more and they ask questions about what problems you're trying to solve, which I think is much more of an actual PM mindset of trying to work backward from the problem as opposed to just taking the problem and regurgitating stuff that you already know. Are there any flags you look for that tell you maybe this person isn't someone you want to be working with?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.