Episode 40 | Placing Bets & Building Trust as an Engineering Leader

Jason: I fell victim to this myself, where I felt I had to be the one who always knew the answer. And so you can almost kind of make something slightly up on the spot, like you know enough about...

Eiso: Yeah. [laughs]

Jason: ... the database that it's not working correctly, so you slightly make something up on the spot. But me, as my more confident self always says to the CEO, uh, or whoever now at this point, was saying like, "Yeah, something's going on. We're figuring it out. We don't know enough yet to say what it is." And sometimes like very junior or pretty, not really with the CEOs blow up at that answer. But the point is that's the right answer. That right there, what I gave was the right answer, and that's the approach that we need to take to that.

Speaker 3: Welcome to the Developing Leadership. The podcast for engineering leaders where Eiso Kant and Jason Warner share their lessons on the ins and outs of managing software teams. On today's episode, Jason and Eiso explore the intersection between finance and engineering leadership and discuss the importance of position sizing and engineering orgs from promotions to product initiatives and technology choices. Leaders are constantly making bets. So the guys delve into decision making, risk management, and the dangers of making the wrong bets. As always, this episode comes with accompanying show notes with a deep dive into the main topics, mental models, and key moments from this episode. Find them at developingleadership.co and linked in the episode description.

Speaker 4: [singing]

Eiso: Hi, everyone. Welcome back to you, another episode of Developing Leadership. Hey Jason. How are you . Doing?

Jason: Good. Good, good, good.

Eiso: So, you know, right before this podcast, you and I were talking of a, of a kind of a finance concept that I was throwing at you, which is, in investing in finance, the importance of position sizing, related to the risk that you're willing to take. And, and it kind of triggered a discussion of that to a large extent as engineering leaders, that's exactly what we do, right? , I'm kind of known for using this, the dual responsibilities of an engineering, you know, build and improve your org and, and deliver value and in delivering value we're placing and sizing bets all the time, so that'd be fun one to, uh, kick us off with today.

Jason: Yeah, definitely did not resonate with me when you were talking about finance, uh, concepts...

Eiso: [laughs]

Jason: ... but as soon as we put in the engineering conte- text, uh, it, [laughs] it landed well with me.

Eiso: [laughs]

Jason: So yeah, where to start, where to start, where should we go from here?

Eiso: So to me, let's start by looking at the, the, you know, the kind of bets that we place as, as an engineering leader. And, And actually maybe even go a step earlier. Do you see engineering leaders talking about it in the, using the words bets and, and probabilities and risk, uh, and reward? Do we even see that that's part of the language? Uh, or is it just our building exit, we're building one?

Jason: I think in organizations that have healthy overall executive management, there is this concept of risk taking in bets and understanding too what a bet means, a positive or negative outcome from that bet too. And unhealthy orgs, it's all typically a binary. So let me give a very specific example. Like every promotion is a bet, right? Every promotion of somebody to a different role is a bet. And in healthy organizations, you're talking about one, if they're ready or what their strengths are, what they would bring to the role, what their weaknesses are, how they would, how they might mess up, or how things could go poorly, and how we would, you know, mitigate those sorts of things.

But a negative outcome from a promotion is usually someone has to be exited from the business, but a positive outcome from that promotion is they stick and they continue to move up. But we don't tend to talk about bets as, like, hey, a possible positive outcome from a negative outcome bet...

Eiso: Yeah.

Jason: Is that they're no longer in that role still, but they're still inside the company. And again, like this is one of those where it gets tricky too, because, like, what do you do in that situation, right? But you can understand that that is actually a bet, like, people moving to new roles or bets. And you have to understand what that would look like and what size bet you're taking too. So a person moving from, you know, tech lead to CTO of a 200 person organization is a massive, massive bet. And, you know, are you ready to take that kind, type of an all in position?

Eiso: So we take bets on people. We obviously take bets on product and initiatives, but we also take bets on technology. Now there's, there's the obvious ones of, you know, we're moving to the cloud, or, or we're taking a bet on this database. But while we, well, you said if a bet on the person goes wrong, you know, it's exit.

When the bet on an initiative goes wrong, it gets killed. But it seems that when the bet on a technology goes wrong, uh...

Jason: We just kinda live with it. [laughs]

Eiso: You know, you kind of have to live with it, right? [laughs]

Jason: Yeah, I mean, I had that microservices thread a long time ago on Twitter. We were talking about some of these things and, you know, this is where I think that we don't do enough actual real company building anymore, everything kind of has to, to actually be in the same kind of tried and true and situational path. Going back to analogy I've used before on this podcast and talked about on Twitter, about the cruise ship versus the flotilla is the easiest way that I think that you, when I talk about company building, is like, "Hey, we're actually company building here for multiple decades." not we're product building for a quarter. I want executives to switch into that mindset company building. And the reason why I harp on this cruise ship versus flotilla, because it allows me to take multiple bets in a safe manner. And that's the kind of the purpose of the analogy is I'm, I could do multiple things at once inside a company and not destroy the company if I'm wrong in any one bet.

And so let me give a couple of really concrete examples here and the two most obvious and relevant would be GitHub actions and GitHub co-pilot. GitHub actions was started literally right after I joined GitHub. And it was a slow build on my side. I went around and I, I socialized this. I really pushed, I didn't know GitHub the organization.

I didn't know the people all, and I was recruiting folks at the same time. And at some point it flipped from me socializing to two very important leaders, and I've talked about them before on this podcast, Sam Lambert, who was the head of infrastructure and now runs PlanetScale. And Marc Shoning, who was the head of product design at GitHub and has moved on just recently to do, uh, something else.

And they took it and they basically said, "We will go and we will size this." And they did a two week offsite with 14 or so engineers in Tennessee and they came back with a working prototype. So that was amazing what they did over there in that. And then GitHub co-pilot was interesting because when the office of the CTO, which is something that we created for me to go experiment with a whole bunch of different really smart folks started, it was outside of the normal day-to-day product engineering side of the fence.

So at some, at one point I transitioned from running product engineering and design to literally just running a very small unit of very smart folks called the office of the CTO. And inside that we started incubating and experimenting with a whole bunch of different ideas. So going back to that flotilla analogy, this is another very specific type of vessel that didn't adhere to the same structures as one of the cruise ships.

We did our own thing, we did our own bets, we did our own, own way of working. Well, you know, one of the things that popped outta that was a new search beta that a lot of people are using on GitHub, but one of the more well-known ones is co-pilot. And somebody who joined GitHub via acquisition, Oege de Moor, who was the head of Semmle, he joined Acto and said, "I wanna work on some AI stuff. Specifically, I wanna experiment with co-generation." And we ran with it. We had two really hard requirements though. One was, we have to be able to show something in less than three months. And it has to be obvious that this thing is a massive big bang win. Like, we're not going for incremental here. We're going for like just something revolutionary. And he said, I think I got a couple of things that might work in this way. And with a team of less than six, in less than three months, we had a prototype that ended up in Satya's in the, in Microsoft board level, where unfortunately it was too good at that point. It was like, "Ship it."

Eiso: Mm-hmm.

Jason: We need to... We're like, whoa, whoa, whoa. Slow, slow down here for a second. We need to actually do some more work on this. But the point being that if we try to do that inside the normal structure, that was GitHub, it would've been a wh-, it would've been a disastrous, like very large landmine field of all the different things.

Even so, we pulled it outside. It still had a bunch of, um, fraught with peril type of situations, including bruised egos by, for other people who wanted to go, quote unquote, "do this," and they thought it was inappropriate that it was being done outside. But the point being, it's like you're, you're maximizing the success of possible and once you're doing that, you take different structures.

Eiso: So it's interesting, right? When do you, when do you pull out of all of the norms and structure of the organization? And not just when the CEO gets a crazy idea? I'm, I'm curious, Jason, like there's for sure engineering leaders listening to this right now who are going, "Ah, I wanna do that with X," but what should be some of the criteria that we're applying to when we really should say, "Okay, we're breaking all the rules and we're. We're going to put it somewhere else or we're gonna make it a Skunk Work project or office of the CTO"?

Jason: Yeah, I, I think there's a couple of very simple ones. One is when there is a singular person who's competently capable of running it, at least a singular person. Maybe, you know, two in the GitHub actions case as an example, but like you need somebody who's like not the CTO or if it's a C- CEO's hair brained idea, not the CEO. You need somebody who, who's in the organization who can go and do that.

And this is going back to a bunch of other analogies that we use, but like, you know, a different leader that can go do that. That's one. And the other is, I think you have to have time bounds. You have to understand, like, what would success look like? All, all that sort of stuff. Because, one of the things that you might notice in some of the other larger organizations that are quote unquote, "innovating," like on AI as an example now is like they're taking multi-year approaches to some of these things. And obviously that is, there's some benefit to long research in some domains, but there shouldn't be multiple years to show some sort of value prop, some obvious value prop. 

I do believe too that organizations tend to need to be a little bit more mature to handle these structures 'cause people will get bruised ego, particularly the leaders. So let's say you've had, you got a product or an engineering leader and you're moving this outside to somebody else, outside their domain so it doesn't report into that chain. That is going to be a difficult conversation because there are gonna be a bunch of bruised egos.

The other flip side, and this is, say it's staying inside, of one of those two, the product or the engineering leader, so you have two people who are doing this. One of the other [laughs] ones is gonna be upset. Uh, and then if it's staying inside, let's say staying inside the engineering leader 'cause is typically where this would probably stay, is in all of a sudden, VPs get upset because they think they should be the one who are quote unquote "doing this."

And this is where, really where I think a lot of these things fall down is going, like in a previous episode, we've talked about psychologists and sociologists and stuff like we do too much appeasement of these things. And we have to make sure that we understand what we're trying to achieve here. And, you know, um, you know that, that's how these things fail in my opinion.

Eiso: This brings me to, um, to a tangent, which is having your favorites.

Jason: [laughs]

Eiso: Right as a... [laughs] Because it's when you're putting that project on, you are fundamentally signaling to the organization in many cases, not all, "This is one of my favorites." How do you think about that as being an engineering leader? And I don't just mean with other leaders, with engineers up and down the organization, there's this implicit structure of who's are who's favorites and how do you make sure that, that stays healthy?

Jason: Yeah, so I mean, I, I will not claim that I am immune to this. I don't think anybody is ever immune to this. I have always tried to be very transparent that I make decisions based upon trust. And for me, if I'm going to choose what, where, like even if it's just like I have an application engineering, data engineering, infrastructure engineering, and a platform engineering as an example, and I'm gonna choose where something is going to go sit, it's gonna be a logical decision and a trust-based decision. And trust is, "Who do I think will do the best job with this? Who do I think will achieve the best outcome?" All that sort of stuff. And I, and I try to be really transparent with it and I try to be approachable and someone else calling me on my BS as well. But at the end of the day, that's what I'm effectively, like, you're effectively trying to go do is you're saying, "I'm handing this off to somebody else. I trust this person to go do this."

And the flip side of saying like, "Hey, I trust this person to go do this," could be, "I trust this other person much less to go do this." What I'm really trying to say is that if you really want to be in that position in the future, it's all about building trust now and how do you build trust with that person is, you know, obviously each person is, is contextually different too.

But the, one of the very first things I ever did when I got to get help was I talked about my own way of operating and what matters to me and, you know, how to build trust with me. And I was trying to be very consistent and very approachable on that as well. But the consistency in, in building that trust and you don't build trust by asking for a new project. You build trust with a previous year of, of operating excellence and things of that nature.

Eiso: I, I really like this and I think this is an incredibly powerful communication tool of there is these logical conclusions that I came to for this decision, but there's also the factor of trust and someone has built it with me.

You, you mentioned your, your own way of operating. Uh, I'm a huge fan of leaders sharing their operating manual, right? Going and, and, and publishing a, a document that says, "This is how I operate." I'm kind of curious if you could, you know, walk our listeners who, who haven't heard this concept before, through what's a personal operating manual and, and what are kind of the sections that should be in it? And if you don't have it yet, I, I highly recommend people to write one and, and share it with your team and fellow, uh, leaders.

Jason: Oh, so it's not something I've ever done in explicit ways and shared with an organization.

Eiso: Oh, interesting.

Jason: But what I have done is I've talked about what's important to me with my leaders and with the org. So it's not something I've published. But for those that aren't familiar as Eiso mentioned, it's usually a, a concept of like almost writing your own CV, but it's like, "Hey, this is, these are what matters to me. My inputs and the outputs that matter to me. I respond well to this. I don't respond well to that. My preferred written communications or my preferred communication style is X, Y, or Z." Or, my, you know, that sort of stuff.

There's a lot of different ways and sections that can go into this and maybe we can actually link to a couple in the show notes to give people an idea. Um, what I have done at each level in each role that I've had in the past, though, is I said, how I want to view like the next couple of years, and I work backwards. And then I say, "Here's basically my API," which is effectively what we're talking about here.

Eiso: Yeah.

Jason: And so let me give you an example of how I've had this conversation with folks it occurs in group settings, all hands. Even if people, if I'm being challenged on something or asked a question. But very often in one-on-ones because you're, you're trying to, you know, something, right? Uh, with a, with an organization. And the root of all leadership, in my opinion, is achieving outcome that wouldn't exist via other people.

And the best way to do that is to start talking about expectations and all that sort of stuff, and also like how the interfaces work and things of that nature. So, um, what I've said before is, uh, the easiest way, particularly s- let, let's orient this from senior leaders for a moment, because it's much easier to talk about folks who have, who are experienced, and at the very high end of the spectrum and been doing this for a while.

The easiest way to talk about my own interface is at trust. Because trust is the root of everything. And trust is the one that happens to be easiest to break too. And so ways in which trust is built, you, you said you're gonna do something, you did it. Your organization is well taken care of, compensated well, um, happy. I don't end up hearing about your organization except in the positive ways when people talk about your organization, they generally love it.

When people talk about your organization in other organizations, they have positive experiences. Going back to you do what you say, like literally. Like, you own your area, you are a professional. If you don't know something, you say, "I don't know, but I will go find out." You don't ask me a thousand questions. You can ask me one or two as an orientation question, but you then go do the rest. And how is trust lost? For me, it's simple, Machiavellian type of things.

Like you're pitting one group against another group. It's, um, you, going back to the Eleanor Roosevelt quote, you know, the great talk about ideas, the average talk about people or events, the small talk about people.

Eiso: Yeah, exactly.

Jason: Constantly talking about people on a regular basis. It's like, did, you can see the meter di-di-di-di, like that is not what I'm about. It actually lowers my energy and it really, it really drives me into a negative space with a person really quickly. And, um-

Eiso: Is just the first thing you fire on? To me, to me breaking trust once it's below a level is the, is the fastest way and the easiest...

Jason:  I don't think I've ever fired faster than when someone has broken trust. And it's always been about some sort of undermining, uh, Machiavellian thing. Like, there's been multiple times where someone has thought they should have my job or something like that. And I've actually put up with some of those situations because I was, I thought I was coaching a person, but I've never fired faster than when it was them trying to undermine a peer and take over a peer's...

Eiso:  Mm-hmm.

Jason:  ... thing. And it wasn't with me because I, I shut that shit down. It was with somebody else inside the organization, and then somebody else comes to me and says, "Yeah, like, you know, like, I heard that, you know, John is not doing well from, you know, from this person over here." Like, you're like, "Oh yeah, I'm going to fire that person. That person is about to go."

And they're like, "Oh no, I heard they're doing really well." I'm like, "You just got played. That shit's gonna go away."

Eiso: Yeah. And I think, to be honest, that's very practical advice for anyone listening to this. If you're seeing that in your organization, it is the quickest spiral to a terrible culture. And I think it's, it's any, you know, good leader's responsibility to try to snuff that out as quickly as possible. How do you, how do you discover that? Besides the, besides actually picking up on the Machiavellian techniques that, that are coming to you?

Jason: So, a couple of things that are very useful for me. One is there's a set of people who want to show that they have information 'cause information is commodity in Silicon Valley and high tech startups. If, if you are confident in yourself, you can sit with knowing way more than people think you know and just let the information, more information come to you.

So part of that is not having to say, "I know a thing." So if you know somebody's having a conversation with somebody else, you, you don't necessarily need to tip your hand that you know, you can just like watch it and see what happens and or even have a conversation directly with that person and not confront them right away, but kind of ask questions and see what happens and all that sort of stuff.

The other is you need, all senior leaders need to have good relationships with other senior leaders and other folks inside the organization. And I go back to my canary example about how the organization is running and how things are going for people on the ground, but also like other execs and, "Hey, you know, what's going on?" All that sort of stuff, like et cetera, et cetera.

But you'll hear more in those situations from others and not... Now you're not gonna hear everything, but you've gotta look for signals. So like, as an example, if somebody is, is quote unquote going to, you know, another organization and talking shit about somebody else in, in the group. You may not hear from that person direct, but they'll hear three people removed and they'll be like, "Yeah, I heard about, I heard about that." and it, by that point, it's wrong. That's not exactly what happened, but it's signal, it's the smoke, um, fire analogy type of deal.

Eiso: Yeah.

Jason: And so when you hear stuff like that, you do listen to it. Now your job is not to act on that right away. Your job is to confirm or your, or to, or see if there's more signal or all that sort of stuff. And it's never to react to it. But sometimes you get a direct line, and when you get a direct line, that's when you know, "Hey, let's go, let's go tease this out a little bit more."

Eiso: You, you know, you mentioned sitting with more knowledge than might be obvious to the room, right? That the kind of power of, uh, not having to always show what you know and, and asking questions. Do you think we ask enough questions as engineering leaders today?

Jason: I mean, typically probably not. No. My personal style of leadership is typically ask more questions. We've had this actual conversation about when you flip from, like, more directive to more kind of...

Eiso: Yeah.

Jason: ... coaching-ish type of approach. And I like to coach more than I like to be super directive, but I think you need to be directive. But I think many people are actually more directive and they need to learn to coach more.

Eiso: But isn't there a whole category of questions, uh, that wouldn't fall in, in, in between the directive and coaching part? Like the...

Jason: I, I do believe, yeah.

Eiso: ... the gathering of, like, of...

Jason: Yeah.

Eiso: ... understanding the complex system that you're in?

Jason: Oh, totally. And so my, one of my classic examples here that I give, and I think we actually talked about this on the podcast, so I keep re-, you know, we've done a lot of episodes, can't remember what is the podcast versus what, what is not. But one of them is, uh, my favorite thing is when an engineer typically says, "That's impossible to do."

Well, my job is not to tell them how it is possible to do that. My job is to start asking questions to demystify whether or not it is, you know, for them to almost come to the conclusion. So it, it's a simple, it's a simple, you know, way to, to frame this but, "Hey, that's not possible." "Well, if it was possible, how would it get done?"

And next thing you know, the engineers rattling off a series of things that need to go right, or blah, blah, blah. And you're like, "Well, okay, cool. That's the, that's the start of a plan. Let's start asking more questions along the way and see, see what, you know, what comes of it."

But like the point is, wait, it's gone from the, the area of not possible to possible, but expensive or possible but, you know, long time or possible, but risky. And great, that's the start of this. And, but, but that's an example of where I think we as engineering leaders get it really wrong. And we, and I think VCs tend to get this really wrong, and exec leaders with engineers tend to get this really wrong.

And I think CEO non-technical CEOs get this really wrong with CTOs and VPs of engineering. So a good example here would be CEO asks the VP of engineering, or a CTO, a question and the VP, and they expect the CTO to know the answer, the exact answer, "Hey, we're having scaling issues, we're having some outages, et cetera, et cetera. What do we do?"

And the CTO should never say like, theoretically, like they're, if it's in a moment type of thing, like have every single answer in there. Like, but there's this expectation because they're technical, they should be the most technical and the most knowledgeable about the entire system, and there's this, that sort of thing.

That's a five person org behavior. That doesn't work at a 500 or a thousand or 2,000 person org behavior. The role of CTO in that situation is to go into the room and be like, "We got this problem. What are we doing about it? Have we, uh, what, what are the database constructs? What are the eventing structures? What are the... How, how are we doing this?" Like all that sort...

That is the, the role in that moment. And then the role, you know, if we're talking about this as an important type of thing, which it is, and the CTO should be owning a lot of this, is to go and talk about the expectations about now versus the future and how we're gonna get out of problems and how we're not gonna get into problems. More importantly, "How we're gonna avoid these types of things in the future and stuff."

But the, the, there's this, you know, in particular, like I fell victim to this myself, where I felt I had to be the one who always knew the answer. And so you could almost kind of make something slightly up on the spot, like you know enough about the...

Eiso: Yeah. [laughs]

Jason: ... database that it's not working correctly, so you slightly make something up on the spot. But me, as my more confident self always says to the CEO, uh, or whoever now at this point was saying like, "Yeah, something's going on. We're figuring it out. We don't know enough yet to say what it is." And sometimes like very junior or pretty, not really with the CEOs blow up at that answer.

But the point is that's the right answer. That right there, what I gave was the right answer. And that's the approach that we need to take to that.

Eiso: And we like to, to, to kind of loop that back to where we started today on, on placing bets and which bets to place, when we're sitting around as engineering leaders and, and or even just with ourselves, how many bets should be top of mind for us at any given moment?

Jason: Oh, that's a tough one. That's a tough one. I think 

Eiso: obviously... 

Jason: ... as the organization gets larger, I think you need to be placing more bets. And as the organization is smaller, maybe not, maybe the, the total number doesn't necessarily change, but the size of the bets probably change a little bit. Like at some point you're a five person organization. You're not betting the company on, on a major bet. You, you know, um, well maybe you are, maybe the entire company's being based on one, one product decision that you're trying to go after, but that's like intimately involved with the CEO and all that sort of stuff. But I do think that you should be making micro, macro bets a lot.

And one of the common strategies of the office of the CTO that we talked about, um, I talked about with my group and, and co-pilot and the search are a really good example of this. You just, it's a simple business parlance of horizon one, horizon two, and horizon three. And I want us focus on horizon three efforts, which I defined as more than 18 months out. And if we took on 10 of them, eight of them were not gonna see the light of day, two of them were going to be, uh, massively successful, like company changing bets.

And I think we hit more than the two out of 10, which to me was an indication, one, we probably didn't think even big enough possibly, you know? We hit a bunch of really good things out of the park in there. Two, I, I think it was also probably too close. I was felt, I was still too in the moment of the roadmap of GitHub and et cetera, et cetera.

But the point being, I think you need to be placing multiples. I think if you're Microsoft size, or let's say Google, 'cause I think Microsoft has been doing better at this. If you're Google sized, you need to be running like AI bets everywhere. Not like concentrated in one company. Like, which I think unfortunately they've oriented themselves around with Deep Mind and a couple of things.

Like you're, you've gotta be saying like, "Hey, what are we doing in all these different areas?" Like, "How are we experimenting with this? What does our, what does the future of the operating system look like? What does the future of YouTube look like? What does the future of this..." And like, not just like at the macro level even too, it's like, "Hey, are we experimenting with some element of these things?"

And I don't know each one of those business lines well enough to pontificate on it. But the point being that people should be making bets. And the way Google is structured right now too, with CEOs in each one of those business lines, if those CEOs aren't thinking that way, well, you know, they're already a couple years behind.

Eiso: So I want to take this on, on when to know if a macro trend means we have to bet, right? If we look over the last years, there have been quite a few macro trends that you and I, I remember looking at and said like, "Oh my God, there's gonna be a whole bunch of bets being placed on this now because they're either too early or because they don't make sense."

And like the classic example is, you know, the, the big bank enterprise, all of a sudden, you know, going deep on, uh, placing a big bet on VR, you know, way too early or, I mean the, the blockchain and web three space has had many of these. But then right now we're in a place where all of a sudden we look at, you know, the, the importance of large language models.

Jason: Yeah.

Eiso: And probably you and I can agree that, that means everyone should be placing bets yesterday. So I'm, I'm kind of curious of, or what's the thought process that you and I use and not, not making us oracles, but in discerning, uh, when it is, we should be placing bets on the macro trend and when we should be ignoring a macro trend. Because I think the ignoring part is even harder for some execs when everyone around them is doing the latest, you know, X, Y, or Z?

Jason: Uh, so ignoring, I think, is the hardest thing to go do because, I mean, think about just the FOMO people have with crypto, right...

Eiso: Yeah.

Jason: ... and opting into this. And let, let's actually talk about Meta here real quickly.

Eiso: Yeah.

Jason: Because this is an interesting one. They bet the business on a AR/VR, right? They're betting the entire business on this. And who am I to criticize and critique Zuck here given his success? But let me just say that, holy cow. Like, you could talk about conviction a lot, or you can talk just about risk.

And there was a hundred ways in which this could have gone much better for Meta in a less risky way. And may, I don't know the internal workings of Zuck's mind or the way that they were thinking about this, but, and maybe Facebook was in a deeper death spiral than we ever could have imagined from the outside.

But this is a Rubicon burn the boats type of bet, and it could have been mitigated. And again, a hundred different ways that could have de-risked this while still keeping the cash cow alive, including keeping the cash cow alive and allowing him to go into this next wave of AI, large language model bets, who they were positioned in such a way that they could have done things that nobody else could have done.

But, you know, that's one, one way in which they, you know, let's just say that is a decision that is for sure.

Eiso: And again, I, I don't know Meta well enough, but my opinion has changed here over the years. I was the first person in the last years to probably look at that and say exactly the same thing that you're saying right now. On the other hand, if you look at true cash cow businesses and Meta being one of them. And I think they're, they're a good business, should be one that generates a lot of excess cash, right?

I think like fundamentally, you know, when a lot of us are in companies where we don't generate excess cash, that's a historical temporal anomaly that like, you know, that, that should, that should correct itself, right? It's either betting early on in the future, but fundamentally, you know, all over quarter of economic history for a decade for a company to become a multi-decade company...

And you said that ph-, you know, that phrase earlier, they have to be able to make cash, right? And so meta, I think roughly will, will, you know, invest in AR a quarter's worth of, of operating cash flow, right? I don't know if the exact number I don't know their business well enough, but it's essentially saying, "25% of the extra cash that we make, we're investing year in and year out on the future."

Now, I think the interesting thing is that, that I don't think you and I would argue about the fact that AR is the extremely likely in our foreseeable future. I don't know if it's one, five or 10 years, 15 years. I, I couldn't predict this, but it is an extremely likely, you know, mobile-like event that will happen, right? iPhone-like bringing, like, event, right? I, I, and it's like are we [inaudible 00:30:10]

Jason: I, I, don't, I don't disagree. What I disagree with Meta's approach here is I feel that their approach was the riskiest possible approach, which is the rebranding of the company, the rebranding of the structure, the all in on this, when in fact it would be the equivalent of decommissioning OSX to all in an iPhone, in my opinion. And rebranding the company from Apple to something else.

I don- actually don't disagree with the decision as we and, and I'm not one of those who thinks AR and VR and this is a fool's folly. I think it's just maybe, and Zuck might go down in history as someone who, like, saw something sooner and I think he will with AR/VR. I do actually believe in it.

Um, but at the way in which it was done to me indicates either I don't understand the business of Facebook. Maybe it was what, worse off than it was. Or something else fundamentally about Facebook that only Zuck knew is going on. Because I feel, again, like the AR/VR, this, this approach would've been de-risk from a public perception, which is important for stock price, public perception.

And remember, they did how many billions of stock buyback, um, um, over the last two years, which now looked like a black hole in the balance sheet because of the stock price, um, crater, which eventually could work out really well still. But if they had, instead of taking the entire company and pivoting, which I don't think they took the entire company, but they took some massive portion of it, they took 500 people, 200 people to start or whatever it was, and really ramped this up at speed and really show these examples 'cause now they're gonna get dragged every time those, those avatars don't have legs. Like, when they celebrate the avatars have legs and stuff like this.

And again, I'm not going back to the long term strategic, I'm going to the short term in the stock at the moment because I feel that, that is something that is, is gonna harm them here. Now again, I think they could have been right, but I think that they took the riskiest possible approach.

Eiso: But it, it's, it's, you know, if I, if I pull us back into the engineering leadership realm, because if we go down this, I think we'll have a whole other episode. There, there are moments where betting the farm are incredibly important or there are moments where you have to outsize communicate in your organization to make change happen.

And Facebook didn't really bet the farm, but like you said, rebranding, you know, communicating. How do you look at that? If we bring that to like a smaller skill and inside an engineering organization, when is it the, the engineering leader's role to go into full, let's call it, you know, rebranding, "This is where we're placing a bet," mode?

And, how, how important is communication in this, right? Because when you're putting that team together of, of seven people that's working on something in the office of the CTO, it's very, very different type of bet than when you're making a bet that you need to socialize across the entire organization. And what bets can engineering leaders socialize that don't come from the C-, the CEO, or, uh, play in that role?

Jason: I think the technical ones obviously like languages and frameworks and, you know, tech stacks and things of that nature. But even that has usually have to be in conjunction with senior leadership cloud movements or all that sort of stuff.

And this to me is, again, where I think like engineering leaders... It's, it's difficult for me to say when you want, you want all in on something because the problem with all inning on any one thing from a technology perspective is that the technology can then take down an otherwise healthy business.

And that is, that's an area you never want to be in because an otherwise healthy business that is brought down by technology is the worst possible scenario. Um, obviously for an engineering leader but for a company because you had something that is honestly very rare. A, a working business that is generating free cash flow and all that sort of stuff is rare. And to be taken down from the inside by technology and some missteps like that is just, I mean, [laughs] it's tragic.

So, but you know, I, I do think that they can socialize going all in on cloud and those sorts of decisions and those sorts of ones where it's, it's that type of thing. I think it's had a 

Eiso: But, but the flip side of this is everything that happened in mobile, right, like over a decade ago

Jason: Yeah, I don't think most people all inned on mobile. I think most people still said, "Hey, we're gonna have our business and mobile, mobile adjunct onto it."

Eiso: No, I mean the actual mobile companies, right? I mean the actual Blackberry and the Nokias of the world, [laughs] the ones whose names we barely remember.

Jason: Oh.

Eiso: Right? Like, we all look back and say, "Oh, they should have gone all in on 

Jason: So, so, but this is, this to me is going back to the Meta example. So...

Eiso: Yeah.

Jason: ... Blackberry, it's existential. That's when, when you all in at a company level, it's existential. And like, whenever I use that word on Twitter, that's what I mean. It's like this company might not exist in its current form, fashion function, or at all in a decade if we don't radically do something.

And to me that's when I go back to, like, I'm making this Meta analogy, like I might not fundamentally understand something about the Facebook business because that's what it looks like Zuck is actually doing. And I'm not gonna, I'm not gonna second guess that portion of it 'cause I don't understand that 'cause we do have the examples of Blackberry.

Eiso: Yep.

Jason: And there was a moment in time still when Blackberry looked like it might be able to navigate that situation, but by iPhone two, but by for sure by three it couldn't.

Eiso: Yeah.

Jason: But it still didn't change. And obviously it's out of business now. Well, I mean, it's still around, but you know what I mean. No one gives a shit about...

Eiso: Yeah, yeah.

Jason: ... Blackberry.

Eiso: [laughs] Exactly. I didn't even know they were still around. So I want to kind of maybe bring a final, final point into this. So Jason, one of the things, you know, when we talk about existential, we think of the Blackberrys and the Facebooks of the world. And, and I've heard you over several episodes over time, mention multi-decade decision making, multi-decade horizons. There are extremely few software companies that ever make it to be multi-decade?

Jason: Yeah.

Eiso: Right. Like, the vast majority of companies today that are a business are going to be fundamentally gone and it's to me radically different of businesses in the real world, right? Like a chip manufacturer or a consumer brand, I mean consumer brand's probably a little bit more, but there's a lot more examples of, of businesses that are able to sustain multi-decade and, well, tech is young, so we won't have a hundred year business. But it's extremely rare and it almost feels that a lot of that is because, of technical decisions we make.

Jason: So this is, this is a long topic for me because this goes back to company building and being very strategic over time and, you know, good example, like, let's talk about Microsoft and Oracle, right?

I don't know how old Oracle is, but Microsoft is now one of the most valuable companies in the world. It survived the Ballmer era, it's become this. Oracle is largely irrelevant. It still has a good book of business and stuff, but as far as like we think about, as like generational companies, it's largely irrelevant.

And, but it's, it's still here. It's still around, you know? It's still in business and it still employs a ton of people. At the root of it, I think this goes to like, yeah, you can't make, like, if you're a five person company and you, you have the hubris to talk about being a hundred year company and all that sort of stuff, like I, you kind of love it, but at the same time, you haven't earned the right to exist yet. You gotta make it to year two...

Eiso: Yeah.

Jason: ... then to year five, and then to year 10. You gotta make a $100 million. Well, you gotta make $1 million, then you gotta make 10 million and you gotta make a $100 million. You gotta do all that sort of stuff. That's like the hard work. At some point you earn the right to start talking about being a, you know, a decade long company or a multi-decade long company, or a generational company. And of the things that will hold all of those companies back, there's a, there's, it's a finite set.

And I talk about the finite set of all things in tech in general as being like four fundamental things. One is ideas, one is time, one is, you know, people, and one is money. And so if you're a business that can make money, can attract people, uses time efficiently and has a bunch of ideas, you, you know, that, that's at the root of this, but let's talk about building one of those and, and what, what will take down a company.

People, or lack of people to, to build this thing is, as far as I'm concerned, one of the bi- one of the biggest, and I mean like turnover. Like let's talk like, again, about Gates to Ballmer. The Gates to Ballmer turnover. It almost killed Microsoft. Technical decisions, Microsoft's still fighting technical decisions on what an operating system was gonna look like. And, you know, it's, it's kind of working its way out, but it's taken them how long before Windows went from basically garbage to okay-ish today, but it's still nothing compared to what, you know, uh, OSX is in terms of like an everyday machine and, and for the most regard. But, so people-

Eiso: I like how both of you and I say this, but when's the last time you actually used Windows? Because I have-

Jason: Oh, I actually use it on a daily basis.

Eiso: I actually use it on a daily basis.

Jason: I do, so I'm one of those people that uses all the operating sys- I have my Linux machine, my Mac and my Windows machine over here. And my son, so this is actually something I, I get really upset about too because my son I mentions this on The Spectrum. He uses Windows 'cause it's, it's for whatever reason, like, his schoolwork and all that sort of stuff.

And then, and he comes to me on a daily basis and I start seeing the real edges in Windows and like where it is and stuff. And like, you know, it's my gaining PC and one of my specific development tools I use over here on this one. And, but I start to see the way in which it's, it, it shows its age and really has not been really thought of and cared for.

So I get a little annoyed. This is like a personal pet peeve of mine. I get a little annoyed on this one, but I also understand why it is the way it is. I understand why, because it's a 40 year old operating or 30 year old operating system or whatever it is, and it has all this cruft and has all these legacy decisions, but ultimately it can take it down, right?

Like, you know, give, look at Microsoft's business. Look at the all look, all the totality of Microsoft's business. And if you've got Xbox Live, you've got Azure, you've got Windows, you've got now with all this AI stuff, you've got Office, all that. If you think about the strategic nature of what the operating system could have been in that.

And yes, Azure started out as Windows server, but it can't ha-, couldn't have been Windows server. It was, it made a, fundamentally, a whole host of wrong decisions...

Eiso: Yeah.

Jason: ... for that type of business. Imagine how strategic it would be. And this goes again to another topic that we've talked about in the past. The company is successful. Imagine how much more successful it could have been with better technical decisions. Um, the um, but so ul- ultimately I think people and technology are the ones that will stop all companies from becoming generational companies.

And the technology is the one that hold it back and basically say, we gotta take care of this legacy business effectively. And we gotta keep it running. We gotta do that. It's a cash cow, we gotta keep it going. But we'll fundamentally can't really change it. We, it, it's too risky, et cetera, et cetera. And then not having people that can either bring new business lines so they lose the innovative nature of them or augment business lines in new and creative ways.

And then what happens, I think, is to become that company that persists you become a more, say, Salesforce-ish, uh, and Microsoft-ish to a degree where you start acquiring all the innovative companies. So you need to be generating a shit ton of cash because you gotta buy, your stock has to be valuable and you have to be sitting on a war chest.

Eiso:  Exactly. And to close a loop, that's what Facebook did incredibly well more than anyone else.

Jason: Yes. Yep. So those three companies that you, we just mentioned, Salesforce, Microsoft, and Facebook, they're like the premier in that space. They, they generated so much money their stock was so valuable. They used that to basically buy every competitor or buy every innovative thing or buy whatever and they augmented their businesses. They would look fundamentally different if they never went on, on those acquisitions sprees.

Eiso: I think that's a fantastic place to leave today on. We started with bets, sum people and it with bets on buying companies and, uh, hopefully shared a bit with you guys on how to strategically think about them. Thanks, Jason. It's a good one.

Jason: It's good.

Speaker 3: Thank you for listening to Developing Leadership. Make sure you subscribe to follow us on our journey to more meaningful engineering leadership. If you have any challenges or topics you would like us to explore in an upcoming episode, tweet or DM us @devleadership_. To learn more about data enabled engineering and how metrics can help your teams and improve your processes, go to Athenian.com. See you in two weeks for another episode of Developing Leadership.

‍