Episode 23 | What Motivates Engineering Leaders?

Jason: [00:00:00] The scoreboard in Silicon Valley is almost primarily led by money. And so it's, it's tough because you have people who, are high up on the scoreboard because of how much money or what their net worth is, but they're actually terrible, one humans maybe, or possibly, two, terrible leaders or the combination of the two. And there are definitely people worth multiple billions of dollars who you, they should never be in charge of humans ever. 

Welcome to the developing leadership. The podcast for engineering leaders were Eiso Kant and Jason share their lessons on the ins and outs of managing software teams on today's episode, Jason and Eiso explore what motivates engineering leaders they chatted about how engineering value creation is different from other functions, what role ego plays as a motivating factor, how to deal with the shitty humans that stroll around Silicon Valley and more. As always this episode comes with accompanying show notes, with a deep dive, into the main topics, mental models and key moments from the episode. Find them at developingleadership.co [00:01:00] and linked in the episode description.

Eiso: Hey everyone, we're back again with another episode of Developing Leadership. Jason and I have a special episode, just the two of us again today, Jason, it's been a while since we've done one, just us. 

Jason: It is, and it's fun to be back. Just the two of us, cuz. I think we can go into some really interesting directions when it's just the two of us, and, maybe we can get into a rant episode or we can get into an education episode who knows, but we'll see where this goes. 

Eiso: Let's see where it goes. So I was just telling Jason, before we started recording that I had someone gave me a question today that really stuck in my mind. And I thought it'd be interesting to, to talk about it, which is, you know, what motivates engineering leaders to do their job? Like what do they ultimately want to achieve? 

When I got this question, I was actually taking a break between meetings sitting out in the sun and it was coming in on slack and I started writing and I kind of realized that the first and foremost thing is that every single [00:02:00] engineering leader at some point was a programmer, right? We were all at some point building and writing code. And if we go all the way back to that very initial moment when we first started programming, it was because of the love and magic of being able to build something out of nothing. Like that first time you, you write a piece of code and you see something pop up on the screen, with the first game that you write, and I personally think that there's like two inflection points from engineer to engineering leader to, let's call it second layer motivation engineering leader. The first inflection point is when you go from engineer to engineering leader, and to be honest, I'm almost willing to say that, that the motivation there really is that you go from the love of being able to build things and continuously learn and like, you know, gain all this like insight and knowledge to the love of wanting to share it with others.

Your motivation becomes like I, I was an engineer, but now I'm a team leader an EM. And I wanna [00:03:00] share this knowledge and experience with others, combined with the fact that it's again another challenge, right? Like I think this notion of like wanting, continuously wanting new challenges and learning the shift from engineer to engineering manager's the other.

But then I think there's a second moment. And I'm curious how you think about this. Is there's a point where you go from an engineering leader, maybe it's from being an EM on a single team to becoming a senior EM, or maybe it's the first time you're, you know, a Head of Engineering at a smaller startup, where at some point you go from not just wanting to share your knowledge and, and loving the challenge of like doing something new to, again, back to loving to build.

But this time you're realizing the organization is your product and you kind of go back to that love and motivation of building. So this is a little bit how I was thinking about it. So I've been curious to hear your thoughts on if this resonates with you. 

Jason: Yeah. And so I think just going back to my own history and some others, I would say that. Let me just detail a little bit about how I got into this in the first place too. This was the late nineties, early 2000's. And [00:04:00] I was, you know, working at a couple various companies. And I remember I was elevated to tech lead, then team manager early, like really early, really young. 

And it was basically out of necessity. No one was on the team, all that sort of stuff. And I remember thinking to myself, "okay, well, this is. This is a chance to do things right." "Right." And it was interesting. Cause you're trying to apply your engineering knowledge to the systems and things of that nature. And I think it was. It was a good idea and principle, but it was a better idea in practice because it was actually not what the job really, a hundred percent entailed that was like a minor portion of the job, you know, making the, the tooling efficient or the systems "correct", or things of that nature.

And in fact I wasn't that successful at that job. I was only mildly successful at that. And then in fact, went back to an IC again for another 5, 6, 7 years before I took my next management job. And the next management job was more out of necessity because of how poor the manager we had in place was, and the team being frustrated.

And [00:05:00] then basically saying, "Jason, we need you to go do this, go talk to the manager, go talk to the CEO. Like we need someone to step up or we're all gonna quit." That sort of thing. And that scenario, I look at it as more of a survival mechanism, if that makes any sense. And that was a completely different situation.

And in fact, I think that one was more. It was almost a better approach because I basically went in saying: this isn't about the systems. This is about the people and about building out the structure, the organization, the efficiencies of the team itself, as well as the prioritization and bringing some sort of structure around that. And that became, you know, that was real first step to me becoming an engineering leader over the next 10 years or so.

Eiso: I'm wanna dig a little bit further, right? Because there is the, you're saying the necessity in wanting to make things more efficient, but if you really go back to like the, those first moments you were about to become your first Tech Lead. I dunno if you can remember that far back, Jason, not calling you old here, but what, what, what was, what was going through your mind, right? Like what, what were you [00:06:00] feeling? What did you want to achieve? Like, what was it that like more at almost a, like a primal level? What was like, what were the feelings that you were having?

Because I see a lot of people go through this step. And one of the things I hear all the time, by the way, and it absolutely amazes me. I see this from the first time someone becomes a Tech Lead to the first time they become a director, "I don't even know what my role is now, what to do. Like I have uncertainty, like, but I'm excited at the same time about the learning. On the other hand, I'm absolutely terrified because I don't really know..." 

Go back a little bit. If you can remember that far on, on how it felt at the time.

Jason: The very first time I remember, I remember it was fear, there was some fear involved cause you don't know what you're supposed to be doing, particularly because you don't have great examples and no one really has great examples. I feel like in the industry overall, this it's their few and far between, so I wasn't quite. And the first time you have to run a team meeting or run, whatever, no matter how many times you've seen one, it's different when you're in that seat for the very first time.[00:07:00] 

The other thing I thought about was what am I supposed to care about? And what I did care about, I was an efficiency junkie. I was, you know, my, my editors, my Emacs setup, my all my bash and terminal systems and things of that nature, like all the dot files. I really cared very deeply about those. And in some ways I thought that tech leadership was a scaled version of that. So if I could do that for the build systems, if I could do that for the pipelines, if I could do that for all blah, blah blahs, and this is way back when, before things were as modernized as they are today. 

But that's like one day a week job type of deal. If you understand what I mean by that, that's like, that's not a four day a week job for an engineering manager, tech lead. And I think I quickly realized that too. Then I realized once I did have that, that dawning moment of like, "oh, okay." I had no idea what it really entailed. 

And so that's when I, you know, we use a lot of sports metaphors here I go back to, I remember going back to it in that moment too, thinking about, well, if shooting is just one thing in [00:08:00] basketball or, you know, blocking in football or, or hitting in baseball or something like that, what's the rest? What is the actual job of a coach? And that's to put the systems in place, the entire system. Like the team philosophy, the offensive one, the defensive one, what type of players we want, how we're gonna coach up or down our players, et cetera, et cetera. And, I realized in that moment that I had no idea what that meant in this role.

And so I had to research it as much as possible and, and study it or, or go, you know, figure it out. And, you know, honestly it took me a while to figure it out because I, I never had a good manager up to this point. I never, and I never really saw what a CTO was supposed to do or whatever. I just didn't really have anything in that, in my life like that. So I just had to kind of like put it all together over the course of a couple of years. 

Eiso: I'm almost gonna skip over the fact that I find out today. You're an Emacs user, not a VIM user, so, well, no, 

Jason: yeah, you definitely Emacs user, but I, I still use Vim on the command line all the Vim controls on the command line.

Eiso: Okay. Okay. Okay. Fair enough. So for, for anybody listening, we cover the [00:09:00] whole audience here between Vim and Emacs. I am a, an avid Vim user, but I, I, I definitely the dot files. , there's a point where you have to give that up, but it's, it's heaven. 

You, you mentioned there, there was this moment, right, of being an engineering leader and then going back to an IC for six, seven years. What was it in that experience that made it take so long for you to go back into engineering leadership? 

Jason: The truth of it is that after you fail at something and I, I do think that the first time I did, I kind of failed at it. You always wonder if you're actually made for it in the first place, or if you really want it again, and you kind of, you kind of fall back to something more comfortable as well. So I kind of, that was part of it. The other side of it was I really didn't care for it in the beginning, and I was really young and I, and, and the very first time I did it, I was managing people 20 years older than me, which was really weird. It's kind of a strange thing. 

And I've always continued to manage people mostly older than me up until, you know, now I'm in my [00:10:00] early forties and, you know, don't manage anybody as a MD anymore. It feels like. Yeah. But that was a little strange. It felt like, you know, quite a bit of, "no way I, I should actually be doing this. Who the hell put me in charge? Like, why is this a thing?" So I didn't really want to gravitate towards it again. 

And then there was an, an element of just, again, like not a lot of interest in going back to it, cause I had other interests I wanted to go do, and this is gonna sound really bad. And, and I, I know this is gonna sound really bad. I actually didn't care for the companies I was working for at the time, too. Okay. And I didn't, and when we don't care, you start punching clocks. And I, you know, I was young, my wife was in Medical school, then residency. We had a lot of stuff going on in our lives. I was working for some like podon companies in Phoenix, or like in Connecticut before I moved out there. And just like, I just didn't care about them. And so I was would just start punching clocks and doing other things. And I was doing a lot of stuff on the side and programming or development, and that's what I cared about. I cared about the night stuff. 

Eiso: It's funny because we started this [00:11:00] question with motivation and I, I didn't mean to turn this into a, a shrinking you on the couch conversation, but, what is interesting, right, is this notion of like, you have to care, and I think, I mean, this holds true for lots of different roles, but I think when you, when you look at engineering leadership, no matter what level you're in, it, there is a sense of like, you need to be proud of what you're building. And I think that's the product, the team, the organization, you need to actually, you need to give a shit. Right. And there's other roles where, where people might be, you know, massively driven by money. I doubt that the, you know, a trader on, I dunno, commodities on Wall Street, like deeply cares about barley, but in in engineering, we can't go around it. 

So if you, if you try to break that down, right? The motivation part it's obviously learning there's like caring for, for the organization and what you're doing. Yeah. I'd love for you to talk a little bit about ego. Like how, how does ego play in like recognition from others? Like how, how was that for you? Yeah. And how do you think it plays in for others?

Jason: [00:12:00] So the very first time, I went into Engineering Leadership, the first time I went into it, post this, and when I basically the very, very, what I consider the start of my engineering leadership journey was at a startup in Phoenix. That's the one where the Head of Engineering at the time was not doing it well and we were all kind of frustrated with it, with that person in the company as well. And I did like this company. I liked it quite a bit. I liked the opportunity and I liked the people on my team. I was friends with a whole bunch of people. 

And so the motivation in that one was I really like that company. I really like what we were doing. I like the people and I really wanted to help in that way. So that was like my main motivation. I don't think there was ego involved at that time. That was that again, that was a little bit more survival. Quickly after that though, you started, I started to realize that I was quite good at this, like the, the time on the bench, studying it as I was doing it, and then, you know, getting better, you know, made me more confident, but also just, , some time and seat and all that sort of stuff. I started to realize I was good at this. And even if I was unsure about how good I could be at [00:13:00] it, I knew I, I had some, some ability to do that the job well. 

Later on, more in like probably the Heroku days, like midway through the Heroku days. And definitely in the GitHub days, there was some ego involved and not in the ego in the negative sense. I say ego in the positive sense here, which is I started to realize that I could probably be all time good at this job. And at that point, you realize, you wanna see how far you could take it, if that makes any sense whatsoever.

And the other side of it was right around the Heroku and then definitely going into the GitHub days too. I had some people who wanted, who basically tried to negatively motivate me if I wanted. And I try to turn into a positive, which is like, you know. You know, people, people could be real shitty in Silicon Valley with the way things they try, the way they treat each other. And, some of the things that they'll say to you are just like astounding. And so, you know, I've got a, I've got a person or two tucked away in the back of my brain when I was working at GitHub saying, well, "I'm gonna show you" that I can do [00:14:00] this thing. You know. 

Eiso: Let's just call it right. The shit list of people, right? The people who said the things that just, I mean, they should never be said to anyone else in any, you know, normal setting. How do you deal with them? Right, because it's, and, and you're not wrong on calling out Silicon Valley for probably having a, an over indexed on, on this.

Throughout your career, how were you dealing with it and how was it affecting you? Because, and I think this goes even beyond engineering leaders, this goes just to human level, but it's something that for sure a lot of our listeners have to deal with as well. 

Jason: I mean, this is probably one of the, the harder ones, because the scoreboard in Silicon Valley is almost primarily led by money. And so it's, it's tough because you have people who are high up on the scoreboard because of how much money or what their net worth is, but they're actually terrible, one humans maybe, or possibly two terrible leaders or the combination of the two. And there are definitely people worth multiple billions of dollars who you, they should never be in charge of humans ever. And in fact, there are people who have unearned success in that, then it's just pure luck. [00:15:00] And in things of that nature too. 

But, you know, taking all that aside, a lot of times you gotta draw motivation from other things. And that, for me, what I realized was that I can just use that to, to draw motivation from similarly, maybe how Kobe and Jordan had to make up things in their own head about people they were playing, at some point too. I mean, Kobe and jordan are uniquely driven in basketball and they would make up stories sometimes about somebody on the opposing team, just to find in the moment motivation. Silicon Valley, weirdly, I don't think you actually need to make up stuff because there'll be enough people who try to put you down over the course of your career. No matter how successful you are, and the more successful you are, the more people are gonna try to put you down. 

It's a weird thing, which is, you'll have a whole bunch of people who tell you and blow smoke. And then there's a whole other bunch of other people who are really upset with the fact that you are having success. And they're going to do things maybe not to your face, but to other people. And that's, you know, that's been something that I've had to try to figure out how to deal with throughout the, probably the last seven years or so. But it's kind of [00:16:00] strange because when that happens too, it's not people who you wouldn't care that they're saying those things, it's weirdly the people who you, who, still have influence in the industry. And they're gonna start saying stuff, you know.

Eiso: It's an interesting situation, right? Because like you said, it's completely correlated with success. At the same time, I like to think that for within engineering leaders, 

Jason: you know, me, it's never the entire engineering leaders, by the way, it's not the engineering leaders that like, I, I, I should say I've never experienced it from engineering leaders.

I've experienced it from almost every other leader in organizations, but engineering leaders. 

Eiso: I was about to say, and this is, this is exactly the same thing that like, to me strikes me, like why I just love what I do is because, there's a there's for sure some psychoanalysis that can be done. I was bullied a lot growing up, and now I spent all my time with engineering orgs and engineering leaders. And they're just overall, like on average, the most kindhearted like people. And I wonder if it's, if it's just me, you know, over indexing on it, but it really does seem to be that like amongst engineering leaders, you don't find this as much as you do in, in the rest of the industry.

Why is, I [00:17:00] mean, we say plenty of outrageous things on this podcast, but why is the engineering leader the kindest leader in the org? You know, let's just say it, like, why, why are they maybe the kindest leader in the org?

Jason:  I don't know if I, I, if I I have an answer to this one, but I think I have some thoughts obviously. And I've said this before, which I think that the engineering leaders get the short end of corporate sticks a lot. And in particular, there's a lot of people who are unaccountable at the C-level for a lot of different things inside the organization. But at the end of the day, the buck stops with almost only two people inside most organizations, the Head of Sales and the Head of Engineering. The Head of Sales has gotta bring in revenue and the Head of Engineering has to deliver stuff. So if the product person or the marketing person or the design person, or the COO, or the CEO are failing. Still the engineering person and the salesperson typically have to, to produce. 

Now, if either one of those aren't producing and the CEO is actually doing their job, they'll they'll get replaced. You understand what I'm really trying to say here? What I have found with the engineering folks is that [00:18:00] they, all of the people inside engineering organizations who tend to be really good engineering leaders, they can, they can multi-mode themselves. One is they can have very, very, thoughtful driven depth based side, where they're obviously deeply technical and they understand the nuance and, and they're thoughtful and they think forward and all that sort of stuff. But then the other side of it is they, they act more like, what Silicon valley would think of as, as an executive, blah, blah, blah, and alpha, you know, the type. 

And I don't, I think that's like a whole bunch of BS at the end of the day and a lot of it's for show, but in fact, they do have to have that and they have to be able to turn it on. But their default probably isn't that mode, that's a mode that they can turn on and they need to when they're in the room. But their default mode is the engineering side as a thoughtful side. Which is why they're in the engineering side of the leadership overall. 

And if that's their default mode, I think that most of those people aren't gonna go out and start seeking like massive alpha approvals from other people. And also shit talk other people. They understand that the world is a great place and it's nuance and et cetera.

But you know, there's a whole bunch of other [00:19:00] people who just go out and like your success means in some ways a zero sum, if you're having success, I'm not having it. And there's a lot of people in Silicon valley that are built that way, which they don't understand that. You and I Eiso, you and I could have mutual success and there is no zero sum success ratio, but there's a lot of people who view it that way.

Someone's talking positively about you. That means that I'm not getting the praise. Therefore, I need to neg you a little bit so that I can get, get back into the yeah. You know what I'm trying to say.

Eiso: I know you're trying to say, and I, I always try to like, bring it down even more to like, you know, like the childhood or the like, you know, when we started and, and I'm gonna draw some parallels that I have no idea if I'm even saying things here that are correct, but I think its:

Engineering leaders always come from having been builders or still are builders. And that first and foremost already teaches you, you can create value out of nothing. You're not winning value from another person, right. In Sales, I'm winning a deal over a competitor. I'm winning a deal, you know, or I'm hitting quota above my peers. I think in so many [00:20:00] other functions, it's the feeling of like, I'm either reliant on other people to create value or I am taking away value from someone else. While I think in engineering is one of the only places where you yourself have full control over the value that you create from scratch, like actually, you know, net positive or, or new into the world and not zero sum. And I wonder if, that shapes part of the thinking, and then I am gonna say it because I think a lot of people are thinking it and I don't think it holds true as much anymore today as it did when you were growing up, and as well still when I was growing up, the small gap that we have is not that big.

A lot of us, when we, you know, the way we got into programming. And hence later down the line in, into leadership started with the roots of not having been the alpha personality in the room.

Jason: I think in general engineering leaders and engineers take direct, they, they feel very directly connected to the things they build, yes. And they take satisfaction in [00:21:00] seeing those things built. So it's a direct satisfaction in seeing those things built. And I think other people have the, almost like tangential, or referral satisfaction and overall overallness of the thing, like the overall success of the company or whatnot, but we, you know, we could see and feel and, and touch the things that we build in that way. And there is that direct satisfaction. I don't know if that plays into others, given that I've only really ever run Product, Engineering, Design, Security organizations, which is under the umbrella of technology. And so I've always been directly responsible for it. 

I do also absolutely think that something does play into it with most of the people, particularly of a certain generation going to development because of not being a thing. If you're in your forties, you are mostly the nerds of high school, and you know, those are the people who are doing that from that generation. I think it's become much more socially acceptable to become a developer. And so it's actually sought after, but if you were born in the seventies or eighties and you [00:22:00] became a developer, you, you were not, it was not the socially acceptable route at the time.

Eiso: Absolutely. So I remember in one of the early episodes, you know, we were talking about Carol Dweck, "The Growth Mindset" book. And to me, I went again and Googled like the exact definition and it's, and you know, if you go and look, look at it's like, you know, "people believe that their most basic abilities can be developed through dedication and hard work. Brains and talent are just a starting point. Creating a love of learning and resiliency, that's essential for great accomplishment." 

Would you dare to say that a growth mindset. It might be more prevalent in engineering leaders off the get go than others or not. I, I don't have a I'm I'm really throwing it out. I'm even sharing an opinion. 

Jason: I think of you asked me that question and you said engineering leaders. I wanna bifurcate this. I would think that the exceptional ones, yes. The average ones, no. And then I would say the average engineer actually probably does not have a growth mindset, but the exceptional tech leads and engineers do. And I think the [00:23:00] number of people who have them, are like, if you have a growth mindset, it's actually a small number of people from a percentage perspective, but they happen to be the outliers. And that's part of the reason why they're an outlier. 

And the reason why I say that is you and I have joked privately, and I think I might even said it on the podcast that one of the most common things that engineers ever do is they tell me a way in which something can't be done. And I always flip it around and say, well, if it were to be done, how would it be done? And immediately there starts into an answer of, "well, I would need six extra months and five people and 2 million dollars, and then this thing would need to go right, and I would need this to be locked." Like, great. That's the makings of a plan right there. Let's start like figuring it out. But the default mode is to say, "no, it can't be done." And it can't be done because there's a thousand ways at which something can't be done and it'll fail and whatever, but you know, very few in which it can go well, and that's where I think the exceptional engineering leaders come in, they have that growth mindset or the tech leads because they default think that sort of way.

That said, you know, in my experience too, in the executive ranks, I don't think growth [00:24:00] mindset is a default either. I think that many people let's say play- act a growth mindset because I know they're supposed to have one, but in fact, that's not their default mode. 

Eiso: I love you're using the word play act because this is, this is something that comes up time and time again in, in my days is the amount of people who are in a role playacting, the personality or the role that's supposed to be there versus truly having it. And I'm curious of what do you, what do you use besides, you know, spidey sense to try to dig in to the play acting versus the, the genuine characteristics. 

Jason: So this is where I think that most people that you see in Silicon valley put up a front, that they are competent. They know what they're doing in that nature. And I, I question whether or not that's true. I don't know if it's true when they go home at night and they talk to their partner or their spouse or their friends, if they genuinely feel that, or if they have some sort of insecurity about them, I like to [00:25:00] think that there's still some insecurity about them because it, one makes me feel better about my own self, because I do have insecurity about those things.

Eiso: Me too. Definitely. 

Jason: But I do think that there is a, a category of people who have unearned confidence in themselves. And I think that has to do with maybe some early, prior success or early monetary success. Weirdly I think very early monetary success leads to unearned confidence in their abilities. And I think that if you understand Silicon Valley, the way that works, that will be one of the primary drivers. If someone had some sort of you know, success early in their twenties and their, you know, life-changing money and never have to work again, but they continue to, they're gonna be built a certain way and they're gonna act a certain way when in fact they should, that they should be the first set of people who should really be in information gather mode. But, you know, that's probably an episode or two in and of itself. 

Eiso: I was about to say, yeah. It juxtaposes to, to the engineering leaders who on average don't have that experience where you, I almost find that it's often, it's not [00:26:00] about unearned confidence. It's actually often the opposite, right? Like it's, you should have more confidence based on what you have actually achieved in many cases. 

Jason: And engineering leaders typically have hard skills, which is different than the soft skills, but Silicon Valley likes to, to think about the soft skills in terms not soft skills in terms of like, you know, we always talk about soft skills, but like yeah. Like "CEO types" or those types, and like, "Hey, this is person's a, leader, a builder, blah, blah, blah." 

But the engineering leaders they tend to have these hard skills and they can build these organizations and they can build the products and, and that nature. And yes, Silicon Valley loves those people, but they love those people in a specific role in the company. And, you know, I, I think that in many ways, engineering leaders over the next-, we talk about this, Engineering Leaders over the next 20 years, I think are gonna have their day they'll start leading organizations and all that stuff. 

Eiso: Exactly. At, at some point we should just start, since you are VC now, like the, the Bessemer Cloud Index we'll start, the Warner-Kant Engineering Leader [00:27:00] index, all the public companies, where engineering leaders at the top. 

Jason: Well, the, so here's the interesting thing. I still get every call in Silicon valley for CTO, CPOs. I mean, no matter what, being, even being a VC people will just assume that I'm gonna roll out and do something different. So I get every CTO or CPO call still in Silicon Valley, and I get a bunch of CEO calls. And I can tell you that the number of people who are capable of being a CPO and CTO seems to be an extraordinarily few people who, who could run these organizations. So in fact, I don't think that we're doing a great job of actually producing a ton of these people still.

And I do think that the exceptional ones should go on to run companies because they will help actually really mentor and produce the next generation of these people. Cause for the most part, CTOs that are on their way up right now, have no, no mentorship, none, zero. And the CEOs of a certain generation vintage are incapable of even understanding what goes on for a [00:28:00] CTO or CPO.

And, you know, I think that's just the truth and it's at some point it'll switch, but you know, it's not, I don't think we're there yet. 

Eiso: This brings me to a question I realized I've never asked you. And it kind of surprises me that I never have. I mean, just in general, not just on the podcast, but who would you credit, in those last seven years as, as the mentor that that helped you the most? 

Jason: Um, I've had two good managers in my entire career. Rick Spencer, he's over at Influx DB right now he's running platform over there. He was my, my manager at Canonical when I first got there. He, he taught me quite a bit about the people, the systems, just generally as he's a, he's an awesome human. He was hilarious. Had a lot of fun with him when I was at Canonical. Still chat with him on a regular basis. I think he taught me a lot about the engineering management side of things. 

And then Adam Gross was my peer and then boss at Heroku, he ended up being Heroku CEO. And he is easily one of the smartest people I've ever met in Silicon Valley. He's [00:29:00] great at Product Marketing, great at Product Thinking, and he's also kind of an acquired taste. Like some people love him. Some people get frustrated with him. I happen to love him. I, I got along great with him. And I just watched the way that he talked, the way that he wrote the way that he did things, the way that he thought.

And he was the one person who told me, I should take the GitHub job. You know, I've mentioned before and here too. I asked like 20 to 23 people, whether or not I should take the GitHub job and to a person except for Adam. They said, absolutely don't take that job, you can't fix founders, can't fix boards, can't fix product, can't fix culture. Can't fix a whole bunch of stuff that's wrong with GitHub. And he was the one person who told me I should take it. And the way that he thought about it was, was incredible, which is, "Hey, everyone knows the story of GitHub where it is, and if you're able to go in and do anything with that, you'll become a legend. That's what a quintessential bet on yourself is all about."

And it was amazing that that's, one person told me that and that is an example of how he was at all times. So, you know. So I have those two people, but as you notice that [00:30:00] Rick was on the engineering side, but Adam wasn't, Adam was just a, a leader in general. And I, I had to pay attention to that and amalgamate that, and then turn it into my world as a VP of Engineering at Heroku. And then the CTO at GitHub. 

Eiso: Well, more so what I noticed, because I know if I asked this question to any CEO, they're gonna list a list of people that weren't their boss or weren't their manager, or might not have even worked in the same organization with them at any moment. They'll list the people from externally that have been introduced to that have kind of grown to be their, their list of mentors. And it's kind of to your point earlier. We do this far and few between with engineering leaders, because you got, you were in the right organizations at the right time, but, you know, were there like, how did your peer network look like? Right. And do you think there is at all a strong peer network? 

Jason: No, there's, there's not a strong peer network. And in fact, I still get calls from, I get calls now from like platform teams at various VC funds, or recruiters saying, hey, we've got an up and coming person, would you take a call with them? And I know they're [00:31:00] probably doing this with a couple of different people, which is great, cause I think it's, it's great. But at the time, you know, even Heroku or, you know, GitHub, if I called up and said, "Hey, I need some help with this." There's nobody that they could point to, and if there was, it always tended to be somebody at like an SVP at Google who, who just can't take that call. The context is different too. It's, you know, the platform team at Google or whatever, and scaling down is gonna be very different than any of those contexts. 

And so, I don't know if there's that many people that can do that. I didn't have any in that way from an engineering perspective. So I had to kind of piece that together. if I were be honest here too, I think that, you know, again, like as a CTO at GitHub and you can't knock where GitHub's influence is in the world. And we built a, a bunch of amazing products while I was there. I would say I'm still built more like a CEO these days, because that's what I've been patterning myself after for the last 15 years.

Just applying it to the engineering side of the world.

Eiso: That's interesting. I, I think this is an [00:32:00] amazing place to leave it at today and, and also gives us a topic that we're gonna have to explore in another episode, you know, what can you learn from, from the CEO as an Engineering Leader, and what should you be modeling from there? And I think a lot of that has shined through episodes already, but it's, it's worth an explicit discussion at some point. 

Jason: That'd be a fun one. Let's do that.

‍