Voices, Votes, and Vetos: Who Is Making the 100 Million Dollar Decisions?

Aydin Mirzaee (Fellow.app)  00:30

Jason, really, really great to meet you I have listened to an episode or two of your podcast and so I think you’re like 30 or so episodes in now right?

Jason Warner (Redpoint)  04:56

Yeah about I think exactly about like right around 40-38 or something a camera roll what we We recorded versus what we published and stuff, though, nowhere near the followership that you guys have built here. So congrats.

Aydin Mirzaee (Fellow.app)  05:06

Yeah, thank you. Well, it’s really cool to be able to do this with you. I mean, there’s a lot of interesting things that we can talk about, you know, for anyone who doesn’t know you, you’re currently the managing director at Redpoint Ventures, which is a venture capital firm. And of course, prior to that, you were CTO at GitHub. And you were also at Heroku as the VP of engineering, lots of engineering management experience. But one thing that we love doing on the Supermanagers podcast is to start from the very, very beginning, and get you to tell us about what were some of the early mistakes that you made when you first started to manage and lead a team.

Jason Warner (Redpoint)  05:42

I mean, those are obviously pretty embarrassing mistakes, but good to learn from type of deal. I actually managed my first engineering team, pretty young, I was about 22 years old, this was back, it ran as the.com, everything was imploding. So I joined a.com startup in 1999, right out of college, and was an engineer there, and then kind of worked your way up and eventually had a small team. And then that thing just went under, and I joined another company. And that company was an old legacy company trying to modernize their systems and move on. And I had more than modern way of working. And for whatever reason, they gave me a small team of like five people, which isn’t saying I never actually managed professionally before I’d run basketball and football leagues in college and started some or teams in college and started a couple of leagues and things of that nature. So it was, you know, I had some leadership background, I never managed professionally. And I remember, not one, one of the mistakes I made was not applying the lessons I learned from running teams and leagues to work. That was a major mistake I made and the other a bunch of other small mistakes I made that I think compounded, where I didn’t assert, I assumed that I was in a position more as a kind of like a navigator, I really didn’t get in and say like, Hey, we need to actually go do this, we need to push here, we need to not do this, we need to, I was hoping that everyone will kind of figure it out along the way. And that was a bunch of micro mistakes that compounded into eventually them saying, Hey, you probably shouldn’t do this.

Aydin Mirzaee (Fellow.app)  07:11

Yeah, that’s super interesting, I’d love to dig in, do you have a story or an example or something that you can share where maybe the team was wanting you to dig in a bit more, and maybe you didn’t at first, I’ve had

Jason Warner (Redpoint)  07:23

a couple of these throughout my career. But in that specific case, again, moving from legacy systems to more modern systems, I would go in, and I would say, Hey, this is kind of the approach that we tend to take in these systems. These are the types of tools that we tend to use, these are the types of thought processes we tend to think about here, you know, in my experience, which is limited, obviously, but you know, I’ve done this before this way here, this way there. And then you sit back and you try to hope, or you’re thinking in that moment that they’ll apply their many more years of experience, lessons learned to that same way of thinking or that or apply those lessons. Instead, you almost have to draw the picture along the way for them, you got to connect more dots. And I guess if I could play it back into a meta lesson was assumed that from where they were to where I thought we needed to go was seven hops, I was assuming they were going to apply all lessons to get all seven hops correctly, I needed to paint the picture and fill in five of those and let them make two leaps instead of seven leaps.

Aydin Mirzaee (Fellow.app)  08:20

Oh, that’s super interesting. So maybe you have someone on the team, maybe it’s someone that you hired, that you know, should be able to approach and get this across the finish line. But maybe there’s a little bit more work to do to build the contacts to relate things to draw some of the patterns and then really unleash them at the problem.

Jason Warner (Redpoint)  08:39

When you think about it. It’s kind of the proverbial meat in the middle, which would be, hey, you’ve got a whole set of experiences and contexts and things that I don’t have. I’m trying to give you this, I have all these you don’t have. So here’s what we’re going to do. I’m going to paint a picture one way, you’re going to try to apply the lessons, I’m going to get them out of you this way. And then in the middle here, that’s where we’re going to figure this out. Now it’s not the classic meet in the middle where we disagree. It’s more of a context of the situation what we have and versus don’t have, and try to get there.

Aydin Mirzaee (Fellow.app)  09:06

Yeah, that’s a pretty advanced good first mistake to make. So I really, really liked that story. So let’s talk about something that was very top of mind for you more recently. So obviously, in the engineering management world for a long time in the in the leadership world for a long time. And now you’re at Redpoint Ventures, I’d love for you to tell us about some of the lessons that you’re taking from your operating roles and applying to the world of venture investing and coaching teams or helping companies identify you know, rising star companies like what are some things that you were able to transfer learn into the new role?

Jason Warner (Redpoint)  09:49

I think a couple of things are applicable so obviously the technical and product backgrounds are plenty applicable I you know, the spaces I invest in, which are basically data, infra ml systems, all of those sorts of things. It’s all What I’ve built for the last 20 years, so that context is well shared, then obviously running teams have size, scale scope, and then to person startups to 3500 person teams or 3500. Person companies, you have all that experience. And you can apply that founders, particularly in the spaces that I tend to travel, love, that combined experience, you know, a lot of times it’s first time or second time founders. But if it’s a second time, maybe they haven’t gotten to a 3500 person company, you know, and they’re technical in their own right, but maybe that’s a scaled system, the size of Heroku, or GitHub, and you got to apply those lessons and help them navigate this. And so, again, you’re going back to that seven hop destination type of approach, which is like, here’s what I expect will happen next. And then once you get to that point, here’s what a world of possibilities that might happen after that. And so here are questions I would ask are the ways I would approach that, that is very applicable. And obviously, with engineering, background, engineering, and technically minded founders very much appreciate the approach, and it resonates with them. Now investments, the truth is that VCs don’t we use really investments from you know, we, hey, we invest in a company, and the company goes and executes. And we’re really, essentially, a coach and advisor and a cheerleader. So in reality, my job is 100 times easier than it ever has been, which is you find incredibly talented teams, you unleash them, and you give them like moments in time advice, and try to like navigate them through that it’s just, it’s an easier job. Now, the mindset shift for me, in reality, in this job has really been to stop thinking about product, I have always had to step back and say, I need to stop saying what I would do with this product. If I was in this company, that’s what I’ve been doing for the last 20 years. And I actually have to stop, I have to exclusively listen and figure out what the founders want to do and where they want to take that. And if it aligns to how I think the world is gonna go or, you know, then we have a back and forth on this. But I can’t project my own hopes and wants and dreams for that product, or what I would do or where I would take over the next five years, and invest on what I think it should be. That’s been the biggest transition for me,

Aydin Mirzaee (Fellow.app)  11:56

that’s super interesting, because I would imagine a lot of people want to know your opinion on what you would do and what you would do with the product, I’m very

Jason Warner (Redpoint)  12:03

happy to give and have that conversation have more has to do with I can’t invest on the thesis of what Jason would do here, guys, it’s actually quite fun. And in fact, I have lots of recurring meetings with founders of really awesome companies exclusively to talk about the product back and forth, I might do something, how I might see it, what I would navigate, you know, all that sort of stuff. It has less to do with that engagement, which I think is super invigorating, quite fun as more to do with, you know, when I go to my partners, and I say we’re going to invest in this because I would build this, this would be possible with this company.

Aydin Mirzaee (Fellow.app)  12:35

And I wonder from an investing standpoint, what are some signals that maybe you’ve seen in engineering teams that you have coached or product teams that you’ve coached or interacted with? Is there anything that is a signal that you found of, oh, this is a really great team, and they’re going to be able to execute on this mission?

Jason Warner (Redpoint)  12:54

There’s a couple of I mean, this is the same sort of mental makeup, I think, for greatness in general, I think given you know, if you apply it to different domains, and you see this, but I’m going to exclusively talk about what I am professionally experienced in which would be product engineering company building teams, and that approach, and then founders obviously now and that sort of thing. So one, first and foremost, it’s I don’t know, but I’ll figure it out. Let me go and really dig in here. There is an attitude I think that some engineers can fall into. And I’m not going to obviously use a one side of the fence of the other, which obviously is never the truth, but let’s just use it for the conversation here. One would be, that’s not possible. And the other is, if it were possible, here’s the 100 things that need to go right to make it possible and like figuring it out, one of those is a stop, it’s a block, it’s basically if you’re in profits, and know the other is I don’t know, but I’m gonna go figure it out. So it’s an attitude approach to that. And all great founders, in my opinion, are on this side of the fence that I’ve seen, I mean, because you’re effectively trying to bring something into the world that shouldn’t exist in the first place. So you have to have this sort of attitude, you got to have a more positive orientation, get things done type of approach to that. And I think a couple of other things that are in similar vein to that which would be again, I mentioned positivity, I think that’s actually something that you need, you’re going to be pragmatic, but you’ve got to be on the positive end of the spectrum. And the reason why is because you’ve got to have some sort of this hopium approach to like building a company in the first place, you’ve got to think that you’re going to do the impossible. And that either comes down to a couple of different things. But I found that the ones were maybe it’s also a little bit of bias on my side in terms of like the ones I like to work with. It’s a positive orientation. It’s a positive worldview. It’s an approach that says like, again, like, Yeah, that’s awesome. Like, that’s a hard problem. Let’s go figure it out. And I’m yeah, like totally, that’s a roadblock. Like I can’t wait to dig in with you on that sort of thing.

Aydin Mirzaee (Fellow.app)  14:43

That’s very interesting. And there’s a saying, which is nobody wants to follow pessimists. And it’s really hard, right? Because sometimes, being an optimist can seem unrealistic and being a pessimist can be seen more practical. And engineering in particular is a lot about practicality. And so Oh, my question is does a lot of this, would you say that the same sort of worldview that you’ve developed now on the types of founders and technical founders to work with? Do you think that translates well to say hiring engineering leadership? So for example, you want to go hire a VP of engineering? Is that something that you asked for or look for?

Jason Warner (Redpoint)  15:19

I do. And this is actually, I think, another mistake that I made a long time ago. And I talked about this on Twitter at some point. But let me use another analogy, like another spectrum kind of approach here, which is I call it competence, confidence spectrum. And I would say that all of us, as engineers, we want to be taken seriously, we really want to be known for our acumen or abilities, and all that sort of stuff. So we tend to be on the competence side of a spectrum, we really want to be approached and thought of in that way. And once you’re inside the engineering ranks, like this is the thing that really matters. And when you’re talking to other engineers, when you’re you, you have to as an example, like when I joined Heroku, or GitHub, like one of the first things I had to do is make sure that like the senior engineers, the people who mattered and that approach really took me seriously and knew I knew what I was doing in that regard. I think when it comes to engineering management, you’ve got to be able to balance both sides of that I think most people should learn that competence is not something to be shied away from. However, confidence without competence becomes this thing that we all in the industry, particularly engineers just cannot stand to be around. And unfortunately, I think a confidence without competence side of the spectrum has been rewarded. For 15 or so years inside Silicon Valley, we’ve talked about this at length on Twitter and stuff. So engineers tend to never want to be booked here. So they almost skew from being like taking strong opinions or forming what like my classically be booked as like a competent side of the spectrum. And so they end up over here exclusively being seen as well, it depends and pragmatic and all of that sort of stuff. And I usually I want to advise people and this is something I have tried to take to heart myself, as you have an opinion, you have a way in which is going to work, you have a thought and where it’s going to go, even if it’s caveat it, you’ve got to find a way to be articulate in that. And you got to find a way to push it and get to all that but be taken seriously as a competent side, but have some confidence in your approach and your way, you’re going to say it to folks. So again, like a classic way it would be I call this the competence competence sandwich, like I want to if I’m an executive, I’m talking to somebody else inside my organization, I’m going to open up a little confidence like, yeah, I understand what’s going on here, I totally have this, here is what we’re going to do. And you lay out in a competent sort of way and an approach and a plan. And in that approach and plan, it’s going to be rather pragmatic, but it’s going to have some nuance, but you’re not going to overwhelm them with the world of possibilities that can go wrong here, you’re just going to say, and I got this, and then you’re going to end that. And they’re going to move away to the famous Maya Angelou quote, which says, People forget what you said, but you remember how they’ll remember how you made them feel. And this is the heart of what I’m trying to say here, which is, I want people to walk away saying, I’m not exactly sure what he said, because it was like past my depth. But I know they’ve got it. I know that team there has it. They’ve shown me they’ve got the competence, and they have the confidence to go execute on this.

Aydin Mirzaee (Fellow.app)  17:57

And they have to have the competence to of course, right.

Jason Warner (Redpoint)  18:01

Of course, that’s the route that but I think engineers by trade have that they’ve got to find the other side of that fence to be able to articulate it. But without overwhelming, maybe a non technical or less technical audience with a world of possibilities, which the only thing they’re going to hear coming out of 15 different ways in which this thing can go wrong is this will go wrong. Yeah.

Aydin Mirzaee (Fellow.app)  18:20

I love what you said. And I haven’t heard that before. And I really like it, which is the confidence competence sandwich and the way that you described it, I think it’s a great playbook for how to communicate how you’re going to go about different things. So one thing I did want to ask is, this is true that especially in the world of engineering, I think in many disciplines, teams are looking to work with someone or they like having a manager or a leader that they feel is technically superior to them. And you know, this is obviously a difficult thing to do all of the time. So I guess my question to you would be, what kind of advice would you give to a manager that gets parachuted into a team, and they have to earn the respect of the team? And there may be some really great and super technically competent people on that team? So how do they establish the competence with that team to then gain the confidence?

Jason Warner (Redpoint)  19:16

So this is an interesting dilemma. Because if you think about this at scale, so let’s just take the GitHub context, as an example here, you know, there’s a couple 1000 engineers inside the company when I left, and my background is distributed systems and infrastructure and develop tools and GitHub Heroku canonical, like these are the technical technical type of things, right. But my background is not front end systems, and GitHub and Heroku, both known for having amazing dx and UX and design and all that sort of stuff. So if you think about it, and one side of the fence, even me as the CTO of GitHub, probably could sit down with the infrastructure team and probably still hold my own. And a lot of these conversations, maybe I can’t program the same way I could 10 years ago, but you know, the seniors in the staff level are gonna be like, Yeah, this guy knows what he’s doing. I can I’m probably talking my way through the front end, but anybody who knows, react or whatever the front end of the of the moment frameworks are, and all that is in CSS and depth and all that, they’re gonna poke holes in me in like two seconds. And so I’m never going to be technically more superior, excellent or whatever, and their specific domain, but across the spectrum of technology, I’ve at least gain that trust, right, I can show a competence, and a depth and a past, that should at least be taken seriously. Now, the problem is that at scale, that makes sense, you know, inside a GitHub or even further Microsoft, or Google, you know, you know, SVP of engineering, or whatever it is, you wouldn’t expect them know, every single departments be excellent that there’s just going to be some sort of a residence that can happen inside an individual engineering manager, particularly maybe a first time or a second time running one team, I believe what you’ve got to do there show that you do understand that domain. So it’s difficult for, you know, if someone’s going to be a front end engineer, and then they’re gonna be plopped into like the ML group, as an engineering manager, that’s actually difficult to go do because you, unless you have some sort of a background there, it’s difficult to have that conversation. So I do think that you’ve got to show some depth in that way. Now, it’s unlikely you’re going to be the best programmer on that team. And I don’t think that’s necessarily what you need to go do. But you need to understand the problems that they have and encounter, and really, fully internalize those things. But even more than that, I do think that you’re going to have to have some sort of depth, because one of the main jobs you’re gonna have to be able to do is say, no, no, we’re not going to go do that. Because that’s not appropriate for our context here. And that, to me, is where you’re going to have that first moment of, do they actually think I know what I’m talking about? So it’s never in the yes, it’s always in the know. Because yes, is easy, no, is hard. And so I think that to build up that trust, you’ve got to build it up by showing small, incremental ways throughout the process. And you’ve got to, you know, another quote I have is like, if the worst time to introduce yourself to your neighbor is when your house is on fire. So by the time you get to your first major, no, you have got to have built up some credibility with those folks on the team. And that in the way you do that, is by being involved and engaged in some of those discussions and adding things but not dominating, but adding, and then, of course, correcting like, Hey, we’re going off this way, we’re gonna kind of go over here type of deal. And like, again, it’s additive types of things. And if you have enough of those, by the time you say, No, you’ve been taken seriously. But if you don’t buy time, you say, No, people just kind of go around you. Yeah,

Aydin Mirzaee (Fellow.app)  22:28

you know, I heard this thing, once were using the word no is like a bullet. It’s a very powerful bullet, you want to use it, but you don’t want to use it too often. So you have maybe a handful of those a year, and you want to use them wisely. And obviously, adding is easy, like you said, saying no is hard. And so it’s a very powerful thing, and you have to be careful on when to use it. One thing that I think is also relevant here for us to talk about is just on this topic of you know, hiring more senior talent, what are some things that you’ve learned in hiring more senior engineering talent? So now that we’re especially talking about both the confidence aspects and the competence aspects, are the things that you look for, in a, say a VP of engineering radically different than what you would look for in say, a director of engineering? Like, what are some of the differences in your mind?

Jason Warner (Redpoint)  23:22

I’ve classified let’s just take the all that kind of levels and bucket them into the straight up title. So we have manager director, VP, as an example. One of the ways in which I tried to frame this so I can actually answer this question is that you have a manager, and some people think of director as manager plus, plus, I like to think of director as VP minus minus. So now that we have that out of the way, what I tend to look for is a manager, I want someone who’s basically going to be that pack leader, it’s kind of like, Hey, this is what we’re the company is going this is what we’re supposed to be doing. This is how we’re going to get there. Let’s fill in the blanks, let’s get it done. That’s the line. And the manager is effectively going back around to all the other pack leaders and saying like, hey, we still on track, we still over like all that sort of stuff. If you think about like that country hiking and with 15 Different groups of people who are supposed to be kind of like commonality going in the same direction, but are off on their own for whatever reason type of deal. That’s what a manager does. A director has to be above that. But a director has multiple versions of those. So it has to be kind of above and spouting out this finding out forward and ahead and spouting out back towards like whatever base camp you might have, or all that sort of stuff, but they have to be doing it in some sort of an abstract way. And then VP obviously is like really setting up like all the different directions and all that sort of stuff and then executing on any of them, but they’re making sure they’re all kind of going in path. The skill set I want in a VP is I really want somebody who is hyper technical. I want hyper technical across the board. And I want people who get stuff done like their orientations, hyper technical, get stuff done, and then kind of get out of the way when they don’t need to. Now the difference here is that I want people also understand this last context importantly, VPS don’t get paid to make Every decision VPS get paid to make 100 million dollar decisions. And that might be four of those a year type of deal. But in the meantime, what they’re doing is they’re making four of those one weight or 100 million dollar decisions that only they can make rest of time, what they’re doing is making sure everyone else is making the decisions that are appropriate to that. And so it’s not that they’re not doing anything else, what they’re doing is making sure all the other decisions are getting made, but appropriately, and then they’re pressure testing those decisions to to a degree, but they’re not making, they’re just making sure that they’re getting made, and they’re getting made well. And if you take that all the way down the chain, you can understand what the jobs are.

Aydin Mirzaee (Fellow.app)  25:32

Yeah, that’s a super interesting approach. It’s almost like they’re designing the system through which the decisions get made. And then they kind of exception handle for the really, really major ones.

Jason Warner (Redpoint)  25:43

And one thing I would caveat in that right there is, I do see that there’s a failure mode that I see some VPS, particularly first time VPS take, which is they will sit down and they will talk about process a lot. And I think this is an overall orientation for first time VPS. And what you really want in that situation is you want like either that old Silicon Valley cliche, which is like strong opinions weekly held or something like that, what you really want is you want kind of like a loose ish, sort of a process you really want speed or safety are like there’s a bunch of orientations that you should pick, it’s not the process, the process must support the orientation you’re after. And in that way, there’s no perfect process. There’s no perfect org structure, there’s no perfect XYZ, you just have to understand if the orientation you want is what you’re getting.

Aydin Mirzaee (Fellow.app)  26:26

Jason, this sounds like a really important insight. Is there an example that you can think of, even if it’s real fictional, where there may be an over reliance on process.

Jason Warner (Redpoint)  26:36

So again, like another mistake I made probably over 15 years ago at this point was when agile XP, all that sort of stuff started to pop out, you said, Hey, we’re having an execution problem. And these things seem like this panacea type of approach is like, Hey, this is what we’re gonna do. Like, this is what we got, like Toyota systems and all that sort of stuff. And you get into it. And what you realize is that you don’t understand how to execute in the first place, but you don’t understand what you’re after, too. And you sort of you become reliant on mechanical portions of quote, unquote, process burndown charts or sizing meetings, or all this sort of stuff. And then you get embroiled in debates over what was it a t shirt size, XL or a t shirt size? L, what do we define as t shirt size, XL versus L? Oh, wait, hang on a sec, how do we handle like, all of a sudden, you’ve lost sight of everything along the way. Now, this feels important in the moment until you get more experienced, and you realize all that stuff is performative. And so this is where I start to rail on OKRs. And it’s not that I don’t like OKRs, I think they’re an amazing aligning tool. But if you ever find yourself in the middle of an executive debate, where the entirety of the last two hours debate was whether or not that was a K, or an R, which happens all the time, you know, like, hey, who was that? No, is that okay? Or is that an R, let’s debate like whether or not the words are right, and like the orientation of the sentence is correct. We’re starting to lose the plot. Again, most companies, in fact, I would say that the majority of companies that any of us who are listening to this are going to work in can literally work off a one sheet of paper of aligning literally. And then what you can do is like a one sheet of paper approach of each team can say like, this is what’s important to us. And this is how we’re going to execute. I give them on my Twitter, which is just Twitter, Jason C Warner, I have a pin tweet from DJ Patil. He used to be the work in the White House. And he’s got this picture he drew. And I think one of my prime jobs in any engineering leader, any leader in general, is to simplify. There’s a picture of it if anyone wants to go and see this, or you can put on the podcast, it says, dream in years planning, months evaluate and weeks ship daily prototype for 1x, build for 10x, engineer for 100x. What’s required to cut the time and half what needs to be done to double the impact. Now getting like that is not an execution plan. That is not how you’re going to operate day to day. But it’s an important reorientation to simplify everything that we have these discussions around. And I find that that right there the over reliance on process the OKRs, we start to lose sight of the simplicity or the need for simplicity or a simplifying effect that we should be having on our companies. And if any leader I’m not talking to engineering leader or CEO out any leader, our job is to actually do that our job is to simplify these things. And their job is to say we’re going over here, here’s how we’re doing it, we need to get out of our own way.

Aydin Mirzaee (Fellow.app)  29:12

Hey, before we move on to the rest of the episode, if you’re an engineering leader, whether manager, director, or VP, all engineering leaders know that one on one meetings are a powerful tool for team engagement and productivity. However, not all leaders know how to run these meetings effectively. That’s why the fellow team just released a comprehensive guide on the art of the one on one meeting for engineers. It has over 60 pages of advice from engineering leaders at organizations like Apple, MailChimp, Stripe, GitHub, Intel, and more. We’ve also included expert approved templates for you to apply immediately to make your one on one meetings that much more effective. So head on over to fellow dot app slash Resources to access the guide And the exclusive templates right now will also link it in the show notes for you to check out there. But you can go on over to Fellow.app slash resources to get the guide and the templates today. And with that said, let’s go back to the interview. To one question that I have is, and I’m trying to figure out how one can diagnose such thing. So if you’re arguing about whether it’s an objective or a key result, or if we missed or we overperformed, and you’re talking about the minutiae, and the details, that’s potentially a sign that you’re missing

Jason Warner (Redpoint)  30:33

the forest, right? This is The Billion Dollar question or the whatever an executive should be paid dollar question, right? This is that old joke, which is, the plumber charges $10,000. For five minutes of work? Well, it’s not it’s $1 for the fix, and $9,999 for knowing where to take the pipe type of deal. And unfortunately, that’s my answer, which is this actually, it comes with that experience, it’s knowing that you’re in that moment. So there’s moments in time when debate is needed as moments in time. And it’s kind of that back and forth. And this is where I think unfortunately, even me right now, in my 40 year old self, who’s been doing this for so long, is going to look back at my fit my 50 year old self is gonna look back and say, Jason, you didn’t have it all figured out. I understand in the moment now that I understand that I don’t have it all figured out. But you have to do your best. And the best is to say, does this actually matter? And at the end of the day, most things don’t actually matter. That’s where our value comes in, is understanding that no, this is actually something that really matters to senior engineers listening to me here, we got to avoid the pedantic debate about like, hey, this linter isn’t really important, or this little thing over here really matters when at the end of the day, it doesn’t matter. But there will be a set of decisions that actually really do your job is to figure out which ones matter and which ones don’t. And to avoid the discussions and avoid the embroiled in a debate and getting into the ones that don’t matter. You just let them go. But it’s a stop the line is to say, No, this one matters. This one is the one we’re going to talk about right here right now. And this actually takes gumption because going back to the OKR. Example, sometimes, and I found myself in this situation, others want to, I’m not the CEO, I’m not the rest of the executive team. And you might be the most experienced person in the room. And you might have to one, let some of that debate go because it doesn’t matter, or stop the line, and tell everyone else in the room like Sorry, I’m gonna have to do this. This matters right here. This one, this one matters. And it might be against everybody else. But that’s what we’re getting paid to do. That’s why we have the senior or the staff or the sea in front of our titles.

Aydin Mirzaee (Fellow.app)  32:31

Yeah, it’s so easy to get caught up in the day to day the processes, you know, the motions, the checking of the boxes. But sometimes it really takes that person to have the balcony moment and step out and say, this really matters. This really doesn’t matter. And you’re right. That’s one of the hardest things to do. But I liked the idea of the $400 million decisions a year. And so that’s a good way to think about it. One thing that you you know, I have this quote from you, where you say, if you think you disagree with someone, assume you misunderstood them, and ask more questions. I’d love to hear how you came upon that. And why is that a good approach?

Jason Warner (Redpoint)  33:12

So if I remember the context of when I said that, when I believe I said that in the context of probably remote work? Yes, I’ve been remote for over a decade now. I did GitHub, remote, Roku remote canonical remote. I’m still remote with red point. And I what I believe to be true is that while we as engineers love async communication, which I think is quite good for what I call the institutional memory of things. One of the things we also like, is synchronous text based communication. So like the slacks and the Microsoft Teams of the world, and IRC back in the day. And I have found that these are actually while they’re needed for remote work or massive detriments. And they’re detriments because they tend to allow people to completely not hear each other. So my people always say like, well, how you can escalate this is, you know, good go through these simple paths. And mine is always a short circuit. It’s literally if I think I misunderstood somebody, I literally pick up the phone, and I call them and I say, Hey, I think I misunderstood that, can you walk me through it. And I don’t go from there to a threaded conversation to a let’s write it, doc to it, nope, I skip all of them. And you jump to the highest fidelity thing you can find. So if you’re in the same office, you literally go find it an office, if you’re remote from each other, you pick up the phone, or you go into video. And as you can see, you know, in this too, I’ve learned to be a lot more expressive, because that’s part of being remote. You have to be expressive in that I’m trying to find those high fidelity types of things and get to the root of it. It’s all about speed, time and understanding. I want to understand that person as fast as possible with as little miscommunications as possible. And again, like I think that while slack and teams are great tools, we’ve become reliant on them and ways in which I think they’re they’re not one they’re not meant to do. In two, they’re actually massively detrimental to the operations of a company.

Aydin Mirzaee (Fellow.app)  35:04

So let’s talk about an example. What’s the statement that maybe if you read the reply that you received that you would just straight up call that person? Well, I

Jason Warner (Redpoint)  35:13

mean, I think like, it tends not to be and like they’ll say, decisions or so you’re gonna get into like a higher fidelity, but it’s going to be like, just a random comment as an example. And it might like, some random comment about like, Hey, we’re gonna go do this or something like that. And instead of started debating, like going back and forth about like, Hey, why, what were what that sort of thing and a lot of people say you want to have that out in the open? No, I still don’t want to have that on the open, cuz I misunderstood. I’m not gonna try to beat it in there, I want to go have that conversation and come back and recap. And that’s an important feedback loop mechanism, come back and recap it. But really where it comes down, I think, too, is like this threaded model, these communications happen that people just keep losing context. And so I would say anytime you think somebody misunderstood you, as an example, I’ve taken it to be more proactive mindset. If I think I misunderstood somebody else or don’t fully understand them, I will call. But in reality, like, think about it this way, if you say something and someone else, you think someone misunderstood, you don’t try to explain yourself anymore in that moment in text, jumped to the phone. And then you come back and say, Hey, we talked offline, here’s what we talked about. And here’s where what we broke down that way. And so like I said, of those types of things actually going to be high, could be like, someone just asked about the linter a versus linter B debate, like we can get into this over the pros and cons and all that sort of stuff. But at the end of the day, you jumped to the phones, I don’t think this decision matters, it’s literally like aspirin, do I take two or two, it takes you three, it doesn’t even matter. Just take your aspirin and move on. Because we got bigger things to go do. So pick it and move. Pros and Cons are not going to change the trajectory of this company. And that’s ultimately we’re going to do but that person might say, well, it’s really important for the project health, like, great, you have the decision, pick one to move. But I want that decision done in like the next five minutes.

Aydin Mirzaee (Fellow.app)  36:48

Yeah, and I think that’s a good response there, which is, you don’t necessarily have to get involved in every decision. But maybe you can help point out who will make the decision, or at least how it will be made whatever the process is, and then set a timeline, make sure it’s done, and then move on.

Jason Warner (Redpoint)  37:04

I think that’s another important aspect of a healthy company, which is I’m also not a believer and consensus driven decision making. I just don’t think it works particularly at scale. I do believe you have to understand who is making which decision how they’re making which decision and when and where. And they have responsibilities inside that construct. But it’s simple. This person has got owns that decision. Here’s the timeline, there are people who need to be will be consulted and informed and all that there’s that RACI model, I call it voices votes and vetoes, who has voted to this who has a voice into this and who has a veto, like understanding how those decisions are going to get made

Aydin Mirzaee (Fellow.app)  37:35

just on this topic of decision making. Sometimes you’ll have someone who’s super competent, rises up the ranks, progressively more senior roles. And they’re a go to person, right? There’s a reason that they got there. And people ask them for their opinions, they usually have really great opinions and really great value to add. But then it gets to a point, especially in a leadership position that maybe they become a bottleneck. Now maybe there’s like an over reliance on that person’s opinions. And so I’m sure you’ve had this in the various organizations where people come to you, what should we do here? What should we do there? How do you handle those situations in light, pull yourself? Yeah, so.

Jason Warner (Redpoint)  38:12

So again, like in the totality of things that I’ve done wrong in my career, this is actually one as well. So you know, that’s the luxury of having a long, successful career as you made a whole shit ton of mistakes, right? Well, the way I’ve tried to think about this is different now than what I did 10 years ago, particularly because of some mistakes. So what I think of part of my job is, again, to make some of those decisions, but to make it and build it. So as I build the company that doesn’t become overly reliant on me. And so I’ve called this, you know, training the neural net, I need to help people make decisions or learn to make decisions as I might make them better, they have better context better information better, but I want them to start going through the process by which I would approach something. And so there’s a lot of mechanisms by which you can do this. There’s one, you know, the one on ones and a team group settings and the product review meetings. But effectively, what I’m trying to do as a Delta company, is to build this neural net resiliency, eight will make its own decisions, I’m going to be surprised like a neural net, I’m gonna be surprised by some of the outputs, but most likely positively and what it learned and what it was able to do if I did my job well of tuning and training and giving some sort of feedback mechanism to it as well. And effectively, that’s what I think I’m doing when I’m building a company. I describe a company as a massive distributed system. It’s just a lossy or version of it. And at the end of the day, I want it to look like a very large language model, neural net that is making better decisions that any one of us could possibly made. This is really

Aydin Mirzaee (Fellow.app)  39:33

interesting, particularly because, by the way, I love the building a neural net, especially these days, and we should touch on GitHub copilot as well. But the thing that I wanted to ask is, was there anything like how do you teach good decisions in this way? So for example, are there documents or ways of showing how we made a decision in the past so others can learn from it because people come in and out of organizations to write there needs to be some sort memory. And this This is,

Jason Warner (Redpoint)  40:01

this is what I think of the institutional memory. This is where I think like async communication is really important to write down that. I think like, if you went back, one of the things that GitHub was seemingly good at was using GitHub to build GitHub. So you can go back and look at past decisions. And it was all in GitHub. So I can go look at one atom kicked off and see what that thread look like and what some of the decisions were. And we kept that going forward. So you know, after I joined GitHub, we built you know, actions and packages and security and advanced security and alerts and modify notifications and co pilot in the, you know, the search beta. And so you can go back and look at those things as well. Now, there’s many different mechanisms by which I believe you could teach that. So the institutional memory is an important aspect of things. But you could be a document based organizations like the six pagers from Amazon, you could be a in person you could do there’s a lot of different mechanisms. But the important one is that when you’re done, you memorialize it, you put it out there so that people can learn from this. Now, how I tended to build organizations was, you kind of were putting it all together, you’ve got there’s a moment in time, when you have presentations, there’s a moment in time when you have paid sick pagers, or we did one pagers, or there’s a moment when you have demos. But the most important in my estimation over time was this idea of these feedback loops. And so you could call them product review meetings, which is what we ended up calling them at GitHub, but it was like weekly meetings with various groups, they would come in and showcase what they’re working on. And I would walk through how I would approach thinking about it. It wasn’t like, here’s what I would do. It was alright, have we considered the customer? Have we considered the impact on this? Have we considered this, like, hair in the back of my neck from experience means that like, hey, maybe this is going to the system won’t scale this way that looks like that looks like a real right heavy approach? Where are we writing this to? Like, what does that mean? And you’re like, I don’t know, Jason, we know that we got that because you asked that same question on actions. And we understand that you’re like an a care about how that’s going to work. So we’ve already considered like that sort of, like that sort of thing, is what I mean, but going back to training the neural that you’re giving those reinforcement loops, and you’re giving it, then you’re writing it down as being memorialized in the various layers, and they’re weighted. And you understand well, in a project that looks like this, at this stage, the next logical outcome from this, and like, you know, the neural net is actually a fantastic analogy for building companies. It really is, if you break it down and understand what happens inside there.

Aydin Mirzaee (Fellow.app)  42:12

It’s a really great way to look at it. And yeah, for designing the system, making sure that the feedback loops are there is obviously really important. One thing that I read on LinkedIn recently, which I thought was really cool was, you know, one way to continuously learn in your career is when you see successful things. And you know, someone doing something that ended up being a successful project or successful decision is to chat with them and understand their train of thought and how they arrived at that place. So this is something that I wanted to ask you about, for, you know, the GitHub co pilot, we’d love to know the quick backstory of from beginning to you know, where it is, as a ship product, like How did that start as an idea? Was it hard to get people aligned on on that, and what happened in the mechanics in the background from thought to shipping.

Jason Warner (Redpoint)  43:02

So COPPA is interesting, there’s a little bit of a needed backstory here, too, which is, GitHub obviously had known that it was sitting on a goldmine for quite some time with the data, but we didn’t understand for many years, probably what to go do with it. And you know, and there was various efforts in place, but you probably see the first real like, Hey, we’re gonna try to build machine intelligence code amplification, I would call it type of things in what we call the security alerts, and advanced security eventually, which is where a lot of this stuff started to really come in. And the idea was, give developers augmentation, give them their Iron Man suits, or their exoskeleton type of approaches. And that’s what we were thinking, you know, like, I gave a presentation to the board and the executive team at the time about what we would do with the data. And it was like, I don’t know, I don’t know exactly how it would come out. But it would be about taking the developer and putting them in an exoskeleton, putting him in an Ironman suit. And then what happened is, we acquired a company post acquisition at GitHub, we’re building like what I would call like features like small little features that would kind of like point to this post acquisition, obviously, vs. Code is in the family. We did an experiment with VS code online, which became Code Spaces. And we acquired a company called simile. The CEO of that company is somebody who is named ooga demore. He’s a great person in the space, and he was working on security. I was forming the office of the CTO, and UGA came over with me as the one of the founding members of the office of the CTO. And I said, Okay, what do you want to go work on? And he says, I really want to figure out how we use our data. I really, I have a thought. And he described it similar to Ironman super, like much more specifically. And we said, Great, let’s go figure that out. And he had a founding engineer to with him. And they just did just cranked on that they said, you know, experimented with UI and various approaches and all that sort of stuff. But the thought process was, again, like, literally, like just accelerating developers experience at the turn of the keyboard 10x 20x 30x what they could do with the data, how they could short circuit learning loops and the thought process on a lot of this was what’s the best way to present this information to the developers newgen team, and there was only six of them. I believe that totality of the office of the CTO when we incubated it, and then rolled it into larger GitHub, experiment with many different ways. But he also asked like, was this hard to get people on board with? Well, no, in the office of CTO, we kind of had carte blanche to do whatever we wanted to go do that was the nature of the office of the CTO. So we just kind of did it first. And by the time we showed it to anyone outside of GitHub, like Nat Friedman, who was the CEO at Siena, like from the get go, but by the time like Satya, or Kevin Scott, who’s a Microsoft CTO saw it, it was already going to be one of those things where we had to stop them from trying to ship it the next day it because, ready, so we knew it was one of those. So our goal was to make it as good and acceptable from the get go there. Kind of hold people back, actually, yeah, and

Aydin Mirzaee (Fellow.app)  45:49

you kind of said this in passing. But I find that using analogies that you can visualize the exoskeleton, the Ironman suit, those are tend to be really good ways of communicating ideas that stick that are viral, that people can get behind. It’s really cool to hear you describe it that way. So time for questions from the audience. And you know, the first of these questions is, what should executive engineering leaders look for in a mentor? I know you’re big on mentorship. And when you’re looking to find a mentor, say even for yourself, how do you go about figuring out who you should get as a mentor.

Jason Warner (Redpoint)  46:28

So I think this is tough, because why I’m big on mentorship is because I don’t think that there’s a lot of great ones out there. Right? Maybe that’s only because of my own situation where I felt like I didn’t have much throughout my career. If I were to look back and talk about the one person who I thought was, what I got out of them. What I look for in that was this person was definitely I think, in this situation smarter than me. But they weren’t technical. They weren’t an engineer, they were just, they were overall like they saw about the world. They thought about how to position how to price how to bring things around how to you know, like all that sort of thing, just the way they thought about I wonder what was unique about that situation was it rounded me out in a way that I wouldn’t have done if I was just an engineering mentor as well, this person basically took me from a CTO to a CEO. That’s what effectively I’ll become, at some point, if I ever go back into into work. And it was interesting that that was what ultimately I needed. I needed to hit my own next level of leadership in general was, it’s not about technical leadership anymore. You’ve had that for 10 years. It’s about all these other things, in totality of who you’re going to become.

Aydin Mirzaee (Fellow.app)  47:31

That’s super interesting. And I’d love to dig in. How did they do that?

Jason Warner (Redpoint)  47:35

They didn’t know, you know, this guy, this guy. His name is Adam Gross is good friend of mine. Now he’s my CEO Heroku. And interestingly, he is one of those people that is, like hot or cold with people, like some people love them, some people hate them. And he didn’t know he was doing this for me, I just watched him. And we had some conversations about how to build Heroku. And that that’s what the context of these were. But the way in which he approached the problems, the way you could see him thinking about this. And then you know, he was one of those folks who’s just super articulate. He’s like, annoyingly good to get and telling stories, and all that sort of stuff you can watch. And if you’re very inquisitive, but also observant, you can see what was happening. That’s what I took away from that. And as we became more friends, I would ask them questions. And I would go back and forth on different topics, and really talk about how to engage with them in different situations on and he’s just one of those situations. So I go back to the observant nature, I think the curiosity observing nature, because you, you could have that from other contexts like before Adam, how I did that was I would read everything I could on great coaches around the NFL, or the NBA or other. I read biographies about professional leaders and what they were doing the thought process that you mentioned earlier about what they thought in that moment, like the problem set, and how they’re gonna approach it. You know, and it wasn’t about the outcome. It was about that in time moment.

Aydin Mirzaee (Fellow.app)  48:49

I know that today, you have a flight. So you have to end on the hour sharp. So I want to get through some more rapid fire questions from the audience. One of them is there seems to be interest in this a lot of interest in this idea of building a technical vision for your team for your company. And you mentioned that a lot of things in GitHub are recorded. And GitHub, I wonder is there either at GitHub, or another place where you have an example of what you know, futuristic vision for the product, or for the engineering team looks like that people can learn from

Jason Warner (Redpoint)  49:20

Yeah, this handle is actually really, there’s no template, but it’s actually pretty straightforward. I can’t do this quote, and I just can’t do it. But it’s the whole, don’t teach a person to build a ship, get them to yearn for the best sense of the sea, and all that sort of stuff. It’s very simple to talk about, like, what might be in five years, but you have to route it back into a moment in time, skill or thing. So what is what is lacking in that boat is you still have to actually teach somebody to build a ship, you have to actually get them to yearn for the vastness of the sea that’s inspiring them that’s gonna get them on a mission and get the passion there. But they still need the skill to go build the ship. That’s actually a core skill. So inside of an organization, a lot of folks will say I’m the vision person or I’m the strategy to person and that’s just like we’re going to talk about all the things are going to be out there. But you actually have to pick a starting point, you actually have to have an opinion, put a flag in the ground and go and say, This is what we’re going to go build next on the path to that. Because the challenge you’re going to have, whenever you’re doing these things is that there’s too many ways in which you could get to the same destination. So you’ve got to pick almost something that puts you on at least one of those paths. And there’s a lot of things involved in that. And that’s where the executives job is that strategy. You know, there’s, there’s two things that we should equally talk about. There’s product strategy, and product sequencing, and they’re both vitally important. And that to me is what the template is talk about what you’re going to build, why you’re gonna go build it, who you’re gonna go build it for how you’re going to find value in that, what what you’re going to pull out of that. And then what comes next, why it comes next. And that is what will get you there. Yeah, and

Aydin Mirzaee (Fellow.app)  50:46

this is so important, because I think like you said, people will actually yearn to be inspired in that way. And they want to know what comes next. They don’t want to

Jason Warner (Redpoint)  50:55

thing though, is to give someone passionate without an outlet. If they’re super passionate, and have no ability to put that into practice, that is frustrating for people. So you have to get a concrete, you have to put this product strategy in place and say we’re doing this next.

Aydin Mirzaee (Fellow.app)  51:09

Yeah, that makes sense as well. So one other question here is, what advice would you have? You know, GitHub was obviously a larger company officer CTO carte blanche, like you said, you’re for other teams that want to have an outlet to experiment with strategic initiatives? How do they go about advocating for that within their companies? Or how can teams be structured to allow for that.

Jason Warner (Redpoint)  51:32

So a couple of things that were different about that situation that I recognized, one is obviously I had a ton of tenure and earned a ton of trust. And, you know, I was the person that GitHub for three and a half year period, or whatever it was three year period. So I was in a very privileged situation, just to do whatever I want to do for the rest of my tenure there. I don’t advocate people ever take that approach, it just tends to not work. So you’re in a different situation, I think you have to earn the right to go do that. So one of the company has to earn the right, sometimes you can’t talk about what you’re going to build five years from now, because you’ve not actually hit that or curve or earn the right to even have the next six months of revenue are one of yours. So you got to understand where you are in your own curve there. The other is, I don’t believe you should try to sell, I believe you should try to show and so if you think you have something that you want to go do, it’s important prototype something literally for four or five days. And literally and again, like, you know, half of this is gonna three quarters of the thing is gonna be fake, but figure it out, even if it’s figma, to be honest with you, it’s like, show what might be possible and say, Hey, this is important. Here’s what I think is important. Do I have runway to for like two people even just to go do this for the next three weeks? Here’s where I want to go proven three weeks now where almost everybody fails on this. As I say, it’ll take me two years to build this. No one’s gonna sign up for that, particularly earlier stage companies, nobody will sign up for that. Even GitHub sighs we weren’t going to sign up for them.

Aydin Mirzaee (Fellow.app)  52:51

That’s, that’s a good pitfall that definitely to avoid, you can do a lot inside of figma. So definitely a good good first step. Jason, this has been super insightful. We’ve talked about so many different things. We talked about the four major 100 million dollar decisions that BP should make in a year building the system training the neural net companies being your own nets, how you built the exoskeleton of GitHub, copilot, and so much more. The final question that we asked everyone who comes on the Supermanagers podcast is for all the managers and leaders constantly looking to get better at their craft. What final tips tricks or words of wisdom would you leave them with?

Jason Warner (Redpoint)  53:28

Oh, well, I think you know, I have a half written Twitter, Twitter and Twitter thread and like, I like how to be excellent in general. And I think if you really want you were, if you really want to be great at what you do, and you want to improve on that use that to become an information amalgamate or get to be excellent at information amalgamation. But the skill that you have to develop after information about amalgamation is the ability to understand bullshit, you got to be able to throw away bad advice, including mine, like if you’re listening to this, and it doesn’t fit your context to say, hey, you know, I like that, but it doesn’t fit my context. I’m gonna learn a lesson possibly from it, but it’s not going to be specific or whatever. And so you got to be able to amalgamate the information, distill it, figure it out and put it in your own essential systems and frameworks or neural net if you’re doing that and, and do and that’s a continual process and the the best of the best, or the best information evaluators and the best information distillers

Aydin Mirzaee (Fellow.app)  54:19

to be an information amalgamate or Jason, that’s great advice and a great place to end it. Thank you so much for doing this.

Jason Warner (Redpoint)  54:25

Thanks for having me.