Episode 3 | The Art of Making Good Decisions

Eiso: [00:00:36] Hi, I'm Eiso Kant, and I'm joined by Jason Warner, and this is Developing Leadership, the podcast where we chat about the biggest lessons we've learned on engineering leadership throughout the years. Good morning Jason, how are you?

Jason: [00:00:49] Good morning Eiso, how are you doing?

Eiso: [00:00:50] Pretty good. I'm having one of those, very very busy starts of the week. I don't know about you.

Jason: [00:00:57] Same, summer ramping up, still no vaccine, a hundred percent coverage in Canada, but with the first dose, people are starting to venture out to parks and all that sort of stuff again. So, and it's sunny, you know how that goes.

Eiso: [00:01:09] Exactly. It's, it's gladly sunny here as well. So last time when you and I spoke, I actually just remembered. We decided to,to make this episode about a topic that we left off on, which was that, a lot of the issues and challenges that we see in engineering leadership are often best solved top down or require a top-down leadership, which is quite controversial because a lot of the ways that we build software and also the way that we like to build our organizations are more bottoms up and you said something around, you know, "control what you can control". And I'd love to just kind of kick it off from there today and hear a little bit about how you look at decision-making top down versus bottom up and go from there.

Jason: [00:01:51] There's a couple of types of decisions I think that require tops down decision-making um, and if you make those types of decisions, then you can get to a, let's call it a middle out decision-making process, or at least, you know, everyone wants to say bottom up, bottom up is not really what happens, it happens somewhere in the manager, director, tier in their structures that a lot of those decisions kind of get sorted out. And I think that if you understand, and you've done this enough, you understand what types of decisions to be on the lookout for. So let me give you some non-work examples and then we can kind of translate it.

[00:02:24] But the first time I ever heard this, by the way, I know people don't like to use military context, but the first time I heard it was in the military context, so I want to like translate it  here exactly the way I heard it, then I'll use my examples.

[00:02:36] If you're on a mission in the middle of whatever, the way that you wanted to train everyone in the military to behave. There's certain places, the military that are more free-thinking than not than others, but they always say that like, you have to understand the mission. That's the most important thing. So if the commanding person is sitting over here saying "our entire goal in life is to take that hill over there". And that person then gets wiped out, captured whatever everyone should know, where their responsibilities are to help go take that hill.

[00:03:05] Ultimately, if there's a ravine or a stream or a river, or, you know, you're pinned down because of whatever, or you're worried about, you know, something over there, everyone kind of has to know how to move and mobilize ultimately to go take that hill. And in the sports context, I'm a sports person. You know what I think about his style of play. Like basketball or football or soccer clubs, all of them have different styles of play.

[00:03:28] Do you want to be more aggressive? Do you want more defense oriented? Do you want to like get the one goal lead and protect exclusively? Like how do you want to play these things? Those are Coach level decisions because Coach then has to, and GM, have to kind of like stack team to have certain types of players. And then you have to coach about what to do in situations like that, but on the field players have to make in the moment decisions. And I think about that a lot at work, which is, "ok, what do we want to be? What are we going to do over a certain amount of time horizon? What is incredibly important that we get right? What can we let flex and get wrong or can delay?"  And those are types of decisions that you have to make at the top. But everything else below that typically in some way can kind of get sorted as long as it aligns to the top level.

Eiso: [00:04:09] So it's interesting that you put it this way, it reminds me a lot of the, it's called the Eisenhower Matrix, which has been massively important over the years for me, which is looking at the impact of the decision versus the actual effort of the decision, or the reversibility of the decision. So what I mean by that is, you know, high impact decisions that are hard to reverse.

[00:04:30] Those are the ones that you want to spend a lot of time on, and probably also further up at the top of the organization and get everyone's input, while decisions that are, you know, high-impact and easy to reverse are much more, it's a type of decisions that you're willing to let people make much faster with less input and also maybe more middle out or bottom up in the organization. And in the decisions of kind of the categories of, you know, low impact and hard to reverse or easy to reverse. Well, those are the ones that you don't really want to be spending your time on anyways.

[00:04:58] Jason: [00:04:58] I'd never actually heard of the Eisenhower matrix, but I just looked it up while you were talking, and its exactly, it's a perfect representation of my meandering thoughts. So go listen and research what Eiso just said, not what Jason just said. It'll help crystallize it, but it's exactly that, it's I talk about one way door decisions. Only I, at some point can make a one-way door decision. It's almost like pivoting the company line engineer line sales person. They can't pivot a company, I can pivot the company, you know, that's a one-way door decision. I have to be very respectful of the type of decision I'm making there. And interestingly, people inside, almost everybody has a type of one-way door decision to make inside their decision-making context. But if an engineer's making a one-way door decision, now but in the company typically, and if they are it bubbles up to the point where you're betting the company, but if you're saying like, "well, this could go wrong or bringing down production and what would happen if we brought down production as we haven't had these safeguards in place."

Eiso: [00:05:53] It makes a lot of sense. So you've, you've gone through quite a career so far. What are some of the decision-making moments that you find yourself in that still to this day? You really remember.

Jason: [00:06:04] There's a couple that I'm happy about is a couple of which I pushed more for. And I'll give you one example here that I, I still think about on a regular basis.

And I have a saying in my head, which is like "being proven, right in retrospect is actually one of the worst feelings in the world." It just means that you probably didn't push hard enough or you had, you already knew what to do, but you didn't have conviction yourself to go push it forward, if that makes any sense whatsoever.

So it's kind of like my moment of regret. That's another way to say it. Like, I might've been proven. Right. But it's actually regretful, that I was proven right, because I didn't push for harder for the moment. I was working at a start up in the late two thousands, and it was originally written cold fusion and SQL server, and,  it was, I think it was 2000 late, 2006, early 2007, and I was pushing to go cloud, like, obviously that would have been super early to go cloud, like ridiculously early to go cloud, but I was pushing for it and and I was pushing to do it in, I didn't actually care about Java. I was just pushing, not Oracle, but I was pushing for some more modern stacks and things of that nature.

Ultimately, it came down, it was decided that we were going to rewrite in Java, on Oracle, on prem, so like deployed WebSphere. And you know, I'm much younger obviously at that point. And I'm like, that doesn't seem right. Does it seem like the right decision to do, they know more than me,  that type of that type of situation. I was in a leadership position. I was running engineering, but they know more than me, in this situation. So, okay. I'll defer to that one there. And it was, it was a little bit of a disagree and commit type of deal, but it was a little bit of defer to, which is where my regret comes in. And I think about that one a lot, because ultimately at the end of the day we did it because customers weren't quite ready for it, but we could have brought the customers along and maybe it was a little bit too early, but it wasn't, it wasn't that early, really where we were. And ultimately we built that product anyway, just three years later.

Eiso: [00:07:48] So it's interesting that you mentioned the notion of like, "hey, you were running engineering, but  outside of engineering I was getting some pressure." That's quite different today. And so today, how do you look at the power that engineering has today compared to even just 10 or 15 years ago? Because if I look at the people around me and the engineering leaders I know, it's a massive change, right?  We're finding ourselves in positions where it's hard to still imagine at, at almost any modern engineering organization that someone who isn't running engineering is going to push you into, into these types of decisions. Or do you think differently?

Jason: [00:08:25] I think it'll depend on the industry a little bit still today. You know, if you're an engineering leader in oil and gas, it's likely to be that you still get tops down pressure. I think we've had this conversation before, but I think that, the evolution of time for engineering leaders, and I don't mean run of the mill engineering leaders, I mean, top level engineering leaders is that they'll end up running these organizations at some point. And naturally so,  I think there's only two very, very capable organizations that should be producing engineer leaders for some of these orgs today. It's probably sales, if you're a  go-to-market-focused customer-oriented type of thing or engineering at some point. And it hasn't been, it's been Finance or Marketing or Product recently, more recently. Sales is still probably one that has dominated. I think industries move that way. I do think just in the future that we're going to see a lot more CTO's who have people skills,  visionary skills and things of that nature emerge out, you know, in the next 10 to 15 years. And they will start to become, you know, the Googles and the Microsoft, CEOs.

Long past when you and I probably want to be doing it anymore, but that's the next big trend. I think though the first couple of companies that get that right with, with a singular person only takes one, you know, look at Satya and Microsoft, it takes one person ultimately charged to change the fortunes of an entire company. I think a lot of these emerging trends will be that engineering leaders start to do that too.

Eiso: [00:09:46] So it's interesting you say, right, "one person can change an entire company". And I think it's something that's very true and it holds very true. Also in engineering organizations. You found yourself, you know, throughout the last decade and in quite a bunch of, of powerful roles, both within the companies that you've been in, but also within the impact that they have on the industry. For an engineering leader who isn't there yet, but someone who today is running an engineering org is a VP of engineering of, you know, a company with one hundred engineers, 500 engineers, maybe a smaller team. What advice would you give them to be able to, to have such an impact on the business? What is it that there, what should, what should you have heard back then when you were making that decision around cold fusion?

Jason: [00:10:28] So interestingly, the same person who pushed me for cold fusion and Oracle, is still a friend today. We talk on a regular basis and he gave me some other advice, which I didn't take.  And in retrospect, I understand why he was giving it to me. He said, "at some point you should probably leave Engineering, and go to Sales or Marketing". And I don't think it was the right advice. Let me be clear on that. I don't think that's what I should have done. I think what he was basically saying is like, "Hey dude,  you could be one of those people. A CEO one day of one of those larger organizations, but to round out your view of the world, you would need to go do a tour of duty and Sales or Marketing".

[00:11:08] And I think that in that framing, that was excellent advice. Not because, I'm going to be good at it, but I have to understand why, how those functions work. Now over the last 10 years, since that person gave me that advice, my super powers have been that I understand every function of the business and I can dive in and work. I, I wouldn't be the bad carrier. I can't be a quota carrier in a sales organization, but I understand sales organizations and how they work and why they exist and what their methods are.

[00:11:35]And I think if you're, if I'm giving any advice to engineering leaders, it's, there's a two-fold thing, which is,  you've got to think of yourself as your department and your department's efficiencies. But really, if I were to give you, if I were to flip it around and say, "Hey, think of yourself as a functional leader second, and an executive first". And so if you're thinking about yourself as an executive first, you're thinking about a business, you think about the new CAC multiples, you're thinking about sales efficiencies, you're thinking about all the stuff that's going on in finance. Not that you have to actually know those things, but you're interested when the CFO is talking at the LT staff meeting, or the exec staff meeting about what's happening in procurement. You're still interested. You don't tune out and just think about "we need to start talking about database tuning". Think about those things second. And the reason why is because then you'll actually pick up on a bunch of these things and care about the entirety of the business.

[00:12:23] The second thing I would say is, whenever you're in charge of anything, it has to be running well. And so almost the price of, of earning the next step is that your function runs incredibly well. And don't make it competitive. Don't be like, "we're better than sales or we're better than marketing". You think about your price of entry to the exec room as the fact that your function is running well. And running well, does not mean that everything's green, running well means that everyone in that room understands what's happening in that room. The risks, the trade-offs, the good, the bad. And you could have five projects that are red, but you're fixing them, two projects that are green that are so critically important that sales is still happy and there, and it feels like it's under control. That's actually a running well organization because everyone in the company knows what's happening.

Eiso: [00:13:08] So it's really interesting you say this, because as you know, I spend, I spend most of my week with different engineering leaders from, you know, small companies to very large ones. And a lot of credit to them, but I can probably count on my two hands, out of the hundreds that I've spoken to that are actually aware of the CAC multiples in their business, the sales velocity  that they have, the issues that are going on, on other parts. But all of them, and many of them are brilliant people who would love to know more and would love to actually get more insight into that. What's going wrong? You know, like why is this something we see so little while we have brilliant people who actually are very interested in, in digging into these areas?

Jason: [00:13:48] One of the things that I've seen throughout  my journey in doing this is, almost everyone thinks about their division before they think about the company. And it's almost like their primary role is a downward looking role, and their secondary role is an upward looking role, and their third role is a sideways looking role, at their exec teammates. And if you think about those three different relationships, down, sideways and up, then in many ways, I'm just saying, hey, invert it a little bit, thinking about your partners, your teammates, as almost a prime, you know, the primary relationship. Not your boss and even not your team. You got to think about everyone else. Now that's not quite right, people are going to balk when you say that, but it helps me. So a good example of this is, that startup company, that I mentioned before, the Oracle one, I didn't have any one-on-ones with anyone outside of my boss who was the CEO and my direct subordinates and a couple of skip levels, and oddly, the CFO. And only, the only reason with the CFO is because I was an engineer number two, he was there as employee number one, or whatever it was, you know, and we we've been around for ever. We knew each other for a long time and we had a couple of things in common that we just like to chit chat about. I didn't need meet with marketing, I didn't meet with sales, I didn't meet with any of those folks. I made a conscious decision moving to Canonical to do that, and then grew it with Heroku and then like cemented it with GitHub. And it was at Heroku the first time I really saw this, Heroku kind of operated similarly, and then a couple of key leaders came into the company and like broke all that down. Said, "No, no, no. If you're an exec staff, you've got to have one-on-ones with everyone on the exec staff". And that I was like, "yeah, like that's a no brainer, why, why haven't we been doing this?" But it's most people don't think about the other execs. Pre-acquisition to GitHub I had standing one-on-ones with every exec member, every week, for half an hour. And if we didn't have anything to talk about, we said, "well, what don't we like in the business right now that we should be spending some time and focus on". And all of a sudden you're like, "oh, we're actually talking about the business, not our interactions or our department's interactions or shared projects, we're talking about the business, and then it rolled into exec staff. And that's how we started to get stuff done.

Eiso: [00:15:51] I really love this, to be honest, because it's, it's incredibly practical. It's something that anybody can pick up tomorrow if they want. And like most things that we've been discussing, the moment you hear it, it's just common sense.

Jason: [00:16:02] The interesting thing is as a smaller company, it's so obviously easy to do. As a larger company is actually much harder to do so like, Salesforce size actually becomes quite difficult. Microsoft becomes incredibly complex. And so the reason why, when I'm talking to smaller companies and earlier companies, I said, "just do some of these things so they become ingrained in your culture, before you have to fight things like politics or, uh, survival mechanisms inside of these larger organizations". Like, you try to do this inside Microsoft right now. Oh my God. It'll feel like Game of Thrones. And, and there's a reason why it doesn't happen inside places like that, because information is power. And a lot of these people are protective of information because they're so afraid of losing that power or the status or whatever. And so you, the amount of energy to have to put in to go break this down is insane. Don't let your company get to that point, do it early.

Eiso: [00:16:49] So talking about game of Thrones, you know, politics within an organization. At what point do you feel that that starts seeping into engineering? Like what are the kinds of sizes, how to watch out for it? What are some of the things that you can do to try to make sure that it doesn't, just even within an engineering org on its, on its own?

Jason: [00:17:06] I'd say that obviously politics will get more as you get bigger. I just think the, the number of times you encounter the "political element" gets more frequent because you have more people. I do think that you basically have it, as soon as you add anyone to the organization, you just don't know it in subtle ways. Like someone's slowly accumulating a veto power over PRs because they've been there longer. That's a form of politics, you know, all that sort of stuff. So I think what you've got to watch for, what engineering leaders or leaders in general have to watch for is a couple of different things.

[00:17:35] Assume, just assume you have it and assume that you're part of the problem. Um, and what I mean by that is, assume that you've mistakenly rewarded the wrong behavior. Just out of naivete, you know, type of deal like, "oh, I love that you did X, Y or Z". But I don't mean like in, "assume you were part of the problem" is "just analyze everything to death". Just watch for things. So think about the common mechanisms by which things get more political. So the first time someone gets promoted or a raise or more equity, or, you know, their, their "teacher's pet". You're starting to enter political land. So you've gotta be a lot more explicit about communication, just to root out politics. And sometimes you have to be real hard ass. Like you gotta say, like, "sorry, yeah, you actually are probably one of the most capable engineers we have, but we're not going to make you staff because you've got five different things over here or two different things that we can't tacitly endorse of your behavior. If we do that, that becomes the norm. That becomes the standard by which everyone else will act. And that, we can't have that."

Eiso: [00:18:34] To drill in a little bit further. What are the kinds of things that you have seen or negative experiences that you've had, or you've seen others around you have that you say, you know,  they're your blacklist. We all have a blacklist. What are, what are some of the things that are maybe not as obvious to people that are in your blacklist Jason,  when you see that someone in your engineering org is doing them and you're like, "no, this is not okay, we need to have a conversation about this", or "this is not letting you, stay or get promoted" or-

Jason: [00:18:59] Well I think it's so, in an interesting way, I talk about inside and outside the email domain, and I say that inside the email domain, you've got to push so that you're one . Team.  And I think we've talked about this in the past too. I'm a "we're a team", not a family, um, mentality when it comes to work because of certain connotations, but I say "we're a team". And we, in a world that exists today in 2021, we're actually all actively choosing to be here. There's so much opportunity for people to be outside the organization. I want inside the email domain, team spiritedness, outside the email domain you can be super competitive. You can be super,  hyper, you know, political, whatever, I don't know whatever you want to do. But none of that shit can exist inside the email domain. So you gotta put, you gotta set the ground rules for that. And I get really, really frustrated when I see people playing political games, like, you know, with me, with others. It's the worst when you've, and it's very common, by the way, inside an engineering organization, you've got unit A, unit B, unit C. One unit does not like the other unit does not like the other unit because there's slight tension about handoffs or trade-offs or who's whose responsibility. And instead of figuring out, they don't talk amongst each other to figure it out. They come and they, come talk to me or someone like me, and they're like, "Hey, we gotta figure this out". Like that that's actually part of the job is to figure that out for those people, it's where those lines blur. And if they deadlock, then come up, but not like, "well, I don't like them, they're inefficient and they hire poorly and I don't like them there, they're doing their operations wrong", or something you know what I mean. Like one of those. That drives me crazy.

Eiso: [00:20:32] And it comes down to your earlier point, right? It's like, have conversations with your peers outside of your domain, but even within your own, like have those conversations with your peers, not everything has to, has to run by the headmaster. So to say.

Jason: [00:20:43] I think one, one other element inside of that too, is that too many people I do, I do believe this, too many people don't know how to have difficult conversations. And I think that they view any point of contention as a fracture in the relationship or a fracture in something. And instead of divorcing it from the two individuals and having a conversation about a topic, there's that, there's that quote, smart people talk about i, um, ideas-

Eiso: [00:21:09] Yes. Dumb people talk about people. Or like, yeah, exactly. It's, it's funny you say this because I was at an event lately and all I could do is hear people talk about other people and how much they had made on their exit and who had done what? And I just literally walked away from it and I went to my brother and I said, "no, like, this is not the room you want to be in. You want to be in the room where people discuss ideas." And I think this is something that like in your organization, when you see that it starts talking about people and talking about others, you've lost the battle.

Jason: [00:21:37] It was one of the first things I did when I got to, on a conscious basis, but in telling when I was doing it, I just watched for  all the conversations, and GitHub at the time, the only topic they would talk about was people. So I remember now in my head it's, "people, events, ideas" as the hierarchy. So it's, below average talk about people. Average, talk about events. Above average or brilliant talk about ideas. And how often were,  conversations falling in each of those categories. A hundred percent of all conversations at GitHub at the time we're falling into "people", and you can't yoke an organization through that, I found, I was trying to yoke it all the way to "ideas" and that just wasn't possible, so you had to actually talk, start talking about "events" and then "ideas". Because I had a suspicion based on the rumors I heard about GitHub and some of the, you know, meeting with the founder that was still there. And the exec team was like, "oh, this doesn't seem like a well functioning, highly cohesive team". And I got there, "oh I get it. Okay."

Eiso: [00:22:28] So what is it? Right? Because even a place like GitHub at that time was filled with individually, you know, above average and, and often brilliant people. What causes a group of people to, to kind of come down to the lowest common denominator of talking about others while everybody there would have been more than capable to be in a room and talk about interesting ideas?

Jason: [00:22:49] In my view, there's probably never any one thing. It's probably a series of, uh, of events, over the course of, you know, multiple generations, et cetera, et cetera, et cetera. It's kind of like if you're, I'm trying to think of the exact example they were using here. But, there's a, an experiment by social psychologists, I believe, where they take a monkey and there's a light bulb. I believe it is with a banana next door, or something like that. And it climbs the ladder, and it goes to get the banana, but then it gets a shock, and it keeps doing that until that monkey no longer goes after that banana. And then they introduce a new monkey that has never been in that. And that monkey starts to train that monkey to not go for the banana. And eventually what happens is the original monkey is no longer involved, the tribal monkey is there and introduced new monkeys, no monkey goes for the banana because all the monkeys keep each other from going for the banana. And no one actually knows why anymore. They're just, they just know the banana is off limits type of deal.

[00:23:37] So, I think about that inside an organization. It's like a whole bunch of small things over time. The organism of the company and of the organization has learned a certain set of behaviors. So the certain set of behaviors, I think specifically that I I'd watch for in all cases are, you know, it's like fear. Like, does someone fear for their job? Do they think that something bad will happen to them? So they're going to try to, you know. Then there's greed. Like maybe seven deadly sins is the best way to put this. Like, you know, the fear, the greed, the, that you just, you can like work your way through that. There's some set of that, probably is at play.

Eiso: [00:24:09] That makes a lot of sense. And so if I, you know, when we spoke last time, you mentioned something, which is, you know, I think it was "once you find yourself in a more powerful spot later in life, how should you treat people and others based on what you've learned from your own negative experiences," right? When you were earlier in your career. What are some of the things that within this context that you think back of where you're like, "I wish that wouldn't have happened to me and I consciously make sure it doesn't happen to others now.".

Jason: [00:24:36] You know, I think people are dismissive of anyone's ideas in general. And I think that, you know, two lessons I would have given my younger self is assume that your ideas, no one will listen to, assume they'll listen to proof. You know, code wins, put it in, put it down on paper, do the actual work. Don't try to sell the idea, try to sell the solution. But I do think a well run organization will actually listen to the idea, but most organizations are well run, so don't assume it. But in mine, I try to give people the room to express the idea and then room to run with it, if I think it's a good one or tune it or tweak it. Another would be that you want the work. The actual work to matter. And not the politicking, not the whatever. I found that too many people were rewarded for too many of the stupid human trick behaviors and, try not to do that at all. You're never going to be perfect, and you will, you yourself will have your own suspect moments of judgment, but you try to almost like we analyze your own decision-making there too. Particularly when it comes to people and promotions raises and equity grants, those are the ones who really can't fix later. And they set a really interesting tone for the rest of the organization too.

[00:25:41] I, this is one that I don't think, the industry will ever totally fix, but I very much want to do this. You and I have had this conversation at length. We've talked about when companies are going well, or when they're going poorly. And a lot of people focus on when they're going poorly, like watch for VCs, how they react when the company is going poorly, et cetera. I actually think like going to the, how the company is doing or how the VCs or investors or other people act when it's doing really well. That's actually more interesting to me because that's when money is on the line it gets really important.

[00:26:09] And so I think back to, you know, the way that I was basically not treated well right around the GitHub acquisition and exit, from that perspective and how I want the industry to change around that sort of thing. But it's still very difficult. There's, you know, we're a capitalistic society that VCs and LPs, there's founders about the people involved. Like when dollars get really large people get really greedy and a lot of people throw things out the window just for that moment in time.

Eiso: [00:26:38] As you've mentioned, we've spoken about this a lot in bigger context as well, but it kind of seems that the more money is on the line, the greed drives people and people in companies to shorter term thinking. And that's, I think the part that, that you're not optimizing for a global maximum ever in your own career when you're trying to do that as a leader, no matter. But when all of a sudden people start seeing, "Hey, this thing is going off like a rocket ship", you find yourself in adversarial situations, and what I will always find very fascinating. Right? How, how can you allow someone to act well in a situation when everybody around them has started to do short-term thinking plus greed, and they're trying to actually be the best version of themselves. But like you said, all of a sudden, all the other monkeys  are fighting amongst themselves, and you're there trying to do things right. Because I speak to hundreds of engineering leaders and I come away from it that many people, humans in general, many people, but I'm very much exposed to those that work in software engineering are, you know, great kindhearted people who are passionate about technology. That's why they got into the field. They found themselves in management because there was some aptitude towards it or they got the opportunity to do so. And when asked, they want to do the right thing. But all of a sudden, they find themselves in situations where, you know, the money all of a sudden becomes a topic. And early on in any of our careers in engineering, money is not a topic. It's not something you, you really are thinking about yet, when it's very, very early on. At least maybe 10, 15 years ago, I think that's even changing a bit today.

[00:28:14] What do you do? Like, what do you do when you, you have the right things in mind? What do you advise to someone who right now is at a company that just, you know, got their first billion dollar valuation, the environment is changing and you're an engineering leader and you're trying to do right by you by your organization.

Jason: [00:28:31] Yeah. So this is something I wish I had learned much earlier, which is, I mean, this is going to get to like, as negative a territory as I typically go. So, apologies in advance to people. Um, and Eiso suppose laughing here because he knows that I'm generally a very upbeat and positive person. This is probably the one scenario where I assume that I want, I would advise to everyone go in and assume nothing, assume nothing until it's written down on a piece of paper and signed. And this is your contract negotiations might be the other, the other situation for that. But interestingly, when you're negotiating your entry contract, if you're an executive. That's actually negotiable, even post it as long as it's still the status quo, like how things are going, if you're, if you're showing that you're good. But as soon as the company itself takes off like this, all bets are off. And the reason why is because it's a zero sum game. There's only a hundred percent of equity in the company that you can dole out. And, um, most people only think about that percentage. They don't think about the valuation and the value of the company.

[00:29:34] So this is where you have to play a different game too, but just assume that most people are not playing this game. If you're, if you own 10% of a, a hundred million dollar company versus 10% of a billion dollar company versus 1% of a hundred billion dollar company, like what, you know, you start to do the math on those sorts of things. So most people don't play the valuation game. VCs obviously do, but a lot of people in the company don't, and they just, they, they get hoardy. They want more equity for themselves because that's just what it means. So don't assume that anyone is going to be looking out for you. Don't assume that anyone's going to look out for your employees. Don't assume anyone's going to be actively seeking how to give away more of the company for those people.  You have to be that champion for your people and you. This is like an incredibly important point. You have a boss who is not going to give you more equity. I can almost guarantee it, unless people listening to this become that person in their organization and actively start to do that, just don't assume it. So have the conversation with them. Be that person for your employees though, be that person for your employees. The only way that this changes generally as an industry is that a hundred people see the example from one person to go onto and ten of those people go on to lead more organizations who inspire more people to be that way. And it may not be there ever for you in your career, but that doesn't mean you shouldn't do it anyway.

Eiso: [00:30:51] And it's also the thing that the moment, uh, everybody looks at their career  not as "to my first x millions" or in the bank account, but to, "Hey, I'm going to be around for the next 30, 40, maybe even 50 years working in this space. Who do I want to be surrounded by? How do I want to be remembered someone earlier this morning told me, you know, what should your obituary read? Uh, it goes a little bit dark, a little bit further, but it's, I think you're absolutely right. I gladly have seen examples of people doing this, but it's far and too few between, and probably you and I should spend, you know, an hour, one day on this podcast talking about compensation negotiations for engineering leaders, because it's a bigger topic. And there are some things that kind of come back to what you mentioned earlier. Like a lot of people are not trained to have the difficult conversations. And I think this is the part that really comes down to, we could probably solve, I would probably say you can probably solve 90% of issues at any company if everybody around was comfortable having the difficult conversations in the right manner.

Jason: [00:31:51] It's such a critical skill.  Obviously like I think it's, oh my goodness, what is the, the book that everyone recommends?

Eiso: [00:31:57] I know it's when you're going for.

Jason: [00:31:59] Crucial conversations, is that the one?

Eiso: [00:32:01] Radical candor, I think is the one that we're talking about.

Jason: [00:32:05] I would recommend people spend some time thinking through these things and also reflecting if they've ever seen someone navigate a tricky situation really well in the moment. And what that meant too. I think is really important that you have a couple of different skillsets when navigating difficult conversations. Here's a good example of how it goes poorly too. I was having this conversation with, a friend of mine who was taking over. He took over head of sales, for an organization and it was a, it was a struggling startup, and,  he was the first real,  enterprise sales person to come in. And very young, naive, kind of first time CEO, rocket ship taking off though.

[00:32:42] And, he and the CEO disagreed on a topic, like "Hey, I just don't want to do that. I don't see if that's the right thing to go do". And the CEO, not very good at difficult conversations. Head of Sales, was a grizzled veteran, probably 50 at the time type of deal, 47 maybe or something like that. Running sales organizations for the last 20 years, all manner of difficult conversations and understanding it.

[00:33:06] The CEO came back the next day and said, "Hey, I've given this a lot of thought and I'm not going to fire you over that disagreement." And the Head of Sales said, "well, hang on a second, we need to go for a walk, because the fact that you would,that would have ever entered your mind over that conversation, this isn't about me and you working together or me being here, this is about, this company will fail if you take that mentality anywhere else inside the organization, because no one will bring you information. No one will talk to you on a regular basis and they'll, they'll start to fear you and you won't understand why. But it's that statement right there. It's not a building the company up statement." And they went, apparently they went for a walk for like a three hour period talking it over, and this person thought you needed 100% perfect kumbaya harmony for the organization to kind of run, and wow.

Eiso: [00:34:01] Yeah, but it's, it's the, the fact that these examples are not far and few between that they, you know, you and I hear them all the time just keeps me very much wondering of like what's missing in our industry, in our own education and in the way that we're brought up to be leaders, for some of these things to just be common sense. Because frankly, a couple of small five-year-olds on the playground, if you present them this as a case study, I'm sure your, your kids, if you give them this, as a case study are going to make the right decision here. Right? And so there's things that are happening in our industry that are shaping and changing people that by the time they're in positions of power, they're acting like this.

Jason: [00:34:43] You know, I haven't studied that aspect of things too deeply, but I would say this: I would say that I do think that too many people think that if you're discussing an idea that they brought and you disagree with it, you are attacking them as a person. It's kind of like you say about writers. You cannot take editing of your book as a personal front, if you do, you'll never be a successful writer. And I think that a lot of people feel that way, which is I, you know, if, if I put my, my social theory hat on, maybe, I would say that too many people think about themselves as a smart person, and if someone disagrees, another smart person disagrees or wants to like, say challenge that idea that they had. It's an attack and a front, on them of how they've identified themselves as a smart person. It's like, it kind of like puts a chink in the armor or crack in the vase type of deal. And you have to like, as a leader, you have to divorce yourself from all of that entirely.

[00:35:37] And the best leaders basically look at it as like," Hey, I'm just amalgamating more information about this to update, you know, an opaque map. Now I see more of the map. That's amazing, I see more of the map. I'm able to go explore more of the video game territory now.

Eiso: [00:35:52] I just want to circle back on something, cause you brought it up again, " " people events, ideas". You, you mentioned earlier that when you were trying to change this when in GitHub, you realized that you couldn't bring the organization directly from people to ideas. Did GitHub end up at the idea stage. And, and what was that journey? And, and what do you think were some of the things that you did as a, as an engineering org to get you there.

Jason: [00:36:17] I think that if you put it back to a bunch of different cliched kind of things in the tech industry,  "don't teach a person to build a ship, teach them to be inspired by the water and yearn for the sea," or whatever that quote is type of deal. I mean, those are the aspirations. I think you're trying to get your organizations to the point where it's a high functioning organization and they understand the longterm and the fullness of time vision of the company. So they understand that context, but you have to understand where they are on that journey. And I think what I've realized is that a lot of people want to make big changes inside the organizations if they come in and do things. And I found that the "frog boiling in the pot" is actually a better approach. It just requires more patience and actually a lot more skill to do that.

[00:36:57] So I think like, you know, the technique you do is you slowly start to ratchet up those sorts of things and you have to correct multiple times. It's kind of like, I hate to say this because, but I can say it because it's about a meta concept, an organization, not an individual person, but it's almost like parenting. It's like a child is going to explore the entire world and every couple of minutes, you're like, "nope, that's out of bounds. Nope, that's a little bit too far. Nope, we don't do that. That's not how we say that." You kind of pull it back in and it's like reshaping that.

[00:37:25] As a high level engineering leader or high-level leader in general, trying to turn around an entire organization, you can't do it with one fell swoop. There's no one magical reorg that is going to get you to that point. You have to kind of do it every day, every minute, every hour consistently over the course of some period of time.

Eiso: [00:37:41] I couldn't agree more with you. And it's funny, you mentioned the magical reorg, because a lot of our industry is still magic tries to magically reorg itself every six months,  to end up with a lot of the same issues.

Jason: [00:37:51] Good example of this is when I was going into GitHub, I got my advice coming in from some outside people who are close to the company,  we're affiliated with, it was like, you know, this is going to be a very caustic one. They said, "Hey, in my opinion the company probably is over staffed by 50%, just let go 50% of the engineers day one, and you'll be better off."

[00:38:07] And I was like, "to what end? Like, what are they building?" "Well I don't know. It just seems like they're over overstaffed," like, okay. So we have not started with the end in mind at any concept, but there's a feeling in place that we should just kind of reorg ourselves, let go of 50% of people and then, you know, things will be better. And at the same time we still haven't decided what we're supposed to be doing. We didn't do  job one yet.

Eiso: [00:38:27] Absolutely. It's I think this is a great place to, to end it on today. And, looking forward to our next conversation. One of the things that I can already mention for those of you listening,  Jason and I are going to be inviting questions and also different engineering leaders to this podcast to be talking about different challenges that they're facing. So if any of you have a challenge that's top of mind, definitely go to developingleadership.co and submit it there. And we'd love to hear from you and not just talk about our stories, but also hear yours.

[00:38:58] thank you for listening to developing leadership. Make sure you subscribe to follow us on our journey towards more meaningful engineering leadership.

[00:39:07] If you have any challenges or topics you would like us to explore in an upcoming episode. Go to developingleadership.co to submit them to learn more about data enabled engineering and how metrics can help your teams and improve your processes. Go to athenian.co. See you in two weeks for another episode of Developing Leadership.

‍