Episode 15 | Things That Drive Us Crazy in Software Engineering Leadership

Eiso: [00:00:00] Welcome to Developing Leadership, the podcast where I, Eiso Kant and my co-host Jason Warner share our thoughts and lessons learned on engineering leadership through the years. Today, we kick off 2022 with a fun episode where we vented about the things that irk us the most in software engineering and the tech industry as whole. From the books we love to hate, to the leadership approaches as we just can't stand, listen to Jason break his record on sports metaphors as we roast some of the most well known elements of tech industry pop culture, and throw in our solutions for some of the issues at hand.

 Hi, everyone, and happy New Year from Jason and I. We're back with another episode of Developing Leadership. We had a great idea for a topic to kick off the New Year. Well, actually, maybe it's a little bit of a pessimistic topic, but the idea that Jason and I had was to talk about the things that irk us most in software engineering and software engineering leadership, and, and kind of our [00:01:00] industry as a whole. And, of course, always with the hopeful and positive outlook that we end up in a place that's better tomorrow than it was today. 

So Jason, welcome back. How are your holidays?

Jason: Great. Relaxing. Spent a lot of time with the kids, and that's what I needed to recharge.

Eiso: Perfect. So Jason, let's maybe ask each other this question, what irks you most about the space of software engineering and engineering leadership?

Jason: Oh, where to begin? Uh, where to begin? I think if I were to kind of sum it up, I think a lot of what irks me can boil down to as one of the root causes, a lack of overall actual professional leadership in tech, at the highest levels, but also kind of throughout the organization. And people who are... have listened to the podcast before maybe heard me speak in other places have heard me say, that if you largely bucket leaders and workers in general, but leaders specifically, into amateur, pro-am, and pro categories, [00:02:00] we are full of amateur and pro-ams. And very few pros actually are in the industry. I think that leads to a whole host of issues.

Eiso: I couldn't agree more with you, and it's, it's definitely one of the things that irks me as well. So let's maybe start there and then we'll come back on some of the other things that irk us, because I know we have a large list. So maybe to start with a very basic question, and I kind of feel I have an answer on this as well. Like, you know, why are we full of amateurs? Is it just because our industry is young, or is there another topic?

Jason: I think by necessity, to some degree, if you think about it, that we need people at the tops of organizations. And there's so few people who are capable of running a lot of these large divisions and companies. And I think that that's just by necessity. A good example of this is going back to sports. There are 32 professional teams in the NFL. That means there's 32 starting quarterbacks in the NFL. Not all 32 are actually NFL caliber quarterbacks, but there will always be 32 starters[00:03:00] in the NFL. And I think that we have a similar problem in tech. We just look at it slightly differently, or maybe not... it's not as blaringly obvious to us because we don't watch it on TV and see the results in the same way. But I feel it's very similar.

Eiso: So the rate at which tech is growing, right, it's leading to huge, larger number of demand and also supply that we create of new leadership positions. Do you think the rate at which we're growing those new roles and those new leaders is in line with the same rate at which creating quality leaders? Like, even if it's-

Jason: No.

Eiso: ... a small level at the top, are we still proportionately growing it?

Jason: No. I mean, I think we're proportionately growing it, but I don't think we're growing in the aggregate that we need. And I think, also, what happens is, this is where the part of the challenge comes in too, is if let's just say 80% of the current generation are pro-ams, and only 20% the pros. And I don't think it's that generous of a ratio, for what it's worth. That means that [00:04:00] 80% are gonna be training the next generation. And what do you think that they're going to get as quality education? You know, I think that's, that's That's the cycle really, that's gonna hurt us the most. And even if we create enough, they're not gonna know what great looks like. And not knowing what great looks like is a really, really, uh, hard issue to overcome because you could have people who might have the skill, but they just don't know how to apply that.

Again, going back to sports, like, if you could have all the raw skill in the world, but if you can't train against some of the best, you're never gonna know what it means to train with the best and what the best look like. And I, I, I think about this a lot when I was an operator, I think about it now, as a VC, but it's, it's going to be an issue. And again, on the VC side, now what I think about a lot is helping the younger generation or first time founders understand what excellent and world class looks like.

Eiso: It's interesting you say this because to me, it, it kind of... it touches upon something that, that irks me as well. And I think it's tangential to this, is the fact that I I've asked hundreds of engineering leaders. "What did you consume [00:05:00] to learn to where you were at?" And one of the things that massively irks me in our industry is they all mention the same three books. And it's not that those aren't great books, but the fact that the list is always three. And some of those books are also, in general, don't apply to every single stage or different type of leader. Why are we in a space where the sharing of learnings is still so much in its infancy? And, and do we see it changing?

Jason: So this is a really interesting topic, I think. I don't know if it has to do with sharing, although, I do think that there is an element of not sharing that needs to go into this too. I think about this quite a bit, because I get asked a lot, "Could I write a book? Could I..." I mean, we're doing a podcast that's different than writing a book or doing a series of articles. And the reason why I think is that you could write content that speaks to an amateur or a pro-am really easily. And, and get an amateur to a pro-am or a non practitioner to an amateur. But it's [00:06:00] very, very, very difficult to write for the pros. And to get a pro-am to a pro because, and this is where it really comes down to, is that all pros realize that the shades of gray, the nuance, the, the middle is where pros are made, and it's the art, not the science of it.

So one of the books that I know that people quote all the time is "The Score Takes Care of Itself" by Bill Walsh, one of the is famous 49ers football coach. And it's an excellent book. If you haven't read it, I do recommend you go read it. The problem is, is that if you think about this, that book has been out there since the, what, I think 80' is when it was out there.

Eiso: Yeah.

Jason: Every professional football coach should be an excellent football coach if it was that easy to apply, just the words on the page to the situation. And Bill Walsh, is excellent, or was excellent. And, and if you read it, you'll understand exactly what I mean by that, which is, there are so many times when you need to make a decision, and it's the art of the decision not the science of the mechanics [00:07:00] of the... of the situation that matter. And that's where... that's where the pros and the excellent ones are made.

Eiso: So let me throw you a curve ball here. Could it be argued that to go from pro-am to pro it really has nothing to do with consuming more content, book or otherwise, on engineering leadership, but that it really just at that point comes down to the common intersection of all leadership knowledge, experience like that there is as much you can learn from a football coach, or an athlete, or the CEO of a, you know, chemical company. Is there a point where we should be immersing ourselves far more into content that's maybe not written for us as engineering leaders?

Jason: I, I personally think so. Yes, but then again, that's my own bias coming up too, because that's how I got better at this is I studied sports. I did a lot of politics, uh, not because I had an interest in politics, but you have to understand high stakes conversations, high stake risky situations, nuance, compromise, all that [00:08:00] sort of stuff looks a certain way. You've gotta understand how to pull from other areas and, and learn from it. So I think so. 

Yes, but I also think a lot of the other industries and a lot of the other arenas are more mature with probably more deepened practitioners than we have here. And it's more obvious too. So again, I keep going back to sports, but the reason why for me is because I'm 20 years steeped into kind of study sports to apply into engineering leadership and company building.

One of the things I love about sports is you have discreetness, you have a game, you've got preseason, you've got a game, you've got quarters, you've got a season, you have off season. You have like perfect chances to, like, redo experiments and, "Okay, this season didn't work out for us. We're gonna go back next season. We're gonna change things up. We're gonna do some stuff and we're gonna the experiment again. And then we're gonna see what happens with it." It's interesting. It's fascinating to see. And then you can read about the philosophies that go into each one of those seasons and all that sort of stuff. You can't do that in tech. You could postulate. I do that quite a bit. But you can never really fully know. [00:09:00] 

So I do think that we should consume more of that information. I honestly do. I also think that we should be much more critical of ourselves and others around us, but in a way that says... not critical, isn't judgey. Critical as in, why do they do that? What is a possible scenario?

Another thing I mentioned before in this podcast is that I have notebooks all over my desk, and I have my GitHub notebook over here. But before I joined GitHub, but what I maybe less commonly known is I, I have a Yahoo one, I have a Google one, I have a Salesforce one. And it's what would I do in the situation that I found myself running any of those companies? And obviously, there are moments in time, but I think through, and I was like, "what would I do?" And then I look back years later to see what they were doing to see how far off on or off. And obviously, I have no idea what the strategy is, but it's interesting. It's data that you can kind of like help yourself to, like, at least course correct to a degree. And I don't think we do that enough. I think most of us wake up every day, look at our calendars and say, "Oh, I need to have five one on ones and I need to do this project review. And then I go to sleep again at night."

Eiso: Okay. So [00:10:00] that's... You just shared with me something that I didn't even know about you yet, which is that notebooks of other companies that you haven't worked at. I find this interesting. It almost is like the fantasy football equivalent of strategic decision making. Tell me a little bit more about what you're doing there.

Jason: Uh, well-

Eiso: What does your Google notebook look like?

Jason: Well, my Google notebook was prob... I think I probably did that one in 2016 or so when I was at Heroku.

Eiso: Yep.

Jason: Um, and a lot of it is... Okay, so Google, "what would I in a situation where you have the world's best search, one of the world's best video assets, unlike any other, an underperforming cloud asset, but some of the best tech, one of the deepest research organizations in the world, blah, blah, blah," you start, like, "what would I do? How would I take this company?" And the goal being that, well, I wanna put myself in a high stakes situation and understand what decision making might look like and the trade offs too, because you can't just say, "Well, I'd go invent a space division out of nothing." You can say, "I need to experiment with it and see what and why you would do all that sort of stuff."

My whole purpose there is to stretch [00:11:00] myself and to think differently and to push... put myself into a situation. Now, on the flip side, it served me well because I had a GitHub, GitLab, Atlassian. I had all three of those notebooks when I was at Heroku. And that led to me trying to acquire GitHub, GitLab when I was at Heroku, which didn't work out which then led me to GitHub... and then you just crackbook and that notebook and talk about that. 

What I always said is "I really wanna put myself in a position where I can see myself taking the top job and understanding how to navigate that company and, and bring it to success." Good example on the counter here is I, you know, talked about how I interviewed at Uber at one point for the top job over there, when they were going through some of their struggles. And ultimately, there's a whole category of decisions, uh, and criteria that didn't fit for me to join there. But one of them is that I could never see myself being the CEO of Uber. 

And the reason why is because I didn't really fully understand their business, and how to take it from where it was to like this grandiose next stage. And I didn't have line of sight to it. As weird as that sounds, Uber at the time, was not as... I think it had just gone public or maybe about to go public, I can't quite remember. I would have a much more crystal clean answer on exactly what to go do in Microsoft or Google or Roblox, even because I understand that business a lot more or Coin base. Now, I understand that business. But I didn't understand Uber. So I didn't really know what to do with it, but I know exactly [00:12:00] what I would do at Microsoft today to make it a five to 10 trillion company. It's obvious what you would do at Microsoft or Google these days. It feels like to me.

Eiso: So it's interesting. You, you bring up the notion a couple of times of both experimentation and strategic foresight, or at least, or just playing with ideas. In contrast to the fact that a lot of leaders today, like you said, it's, it's the five one-on-ones on the day. It's the, the meetings that are often reactive, not even proactive. 

This brings to me, one of the things that irks me a lot about software engineering leadership is, we have a huge culture of experimenting with technology, right? We, we will try every new thing under the sun, no matter how mature the organization is. Someone will slip in that new project or new library and experiment [00:13:00] with it. And it brings us, it gets us into trouble, but it also gets us... it moves us forward, right? It, it ends up creating new interesting things from columnar databases to all other cool tech that's come out in the last years.

But I feel that we have a huge lack of culture in experimenting with our organizational models, with ideas on how to improve things. And I think it partially comes from the fact that by the time we make a decision to try something different in our organization, it often comes from a cargo culting, or, "Let's mimic what Google does, or let's mimic what the blog post that we just read on, on hacker news. And let's go all in on it." How do you look at experimentation at the kind of organizational level?

Jason:  So I think you hit the nail in the head there. And for listeners at home, we had a mini conversation about this episode before, but we didn't get into this point here. So Eiso just kind of read my mind personally on this one. So I think [00:14:00] in software, it's easier because one, we expect an experimental mindset to a degree. We talk about short feedback loops and failling QA tests and know what I'm talking about.

Eiso: Yeah.

Jason: It happens all the time. And we kinda encourage it. It's the exact opposite with leadership. And in fact, you're not allowed to make mistakes typically. And by mistakes, I don't mean, "Hey, we're over budget." Or... I mean, it's like, "Hey, we're gonna experiment with something." It's almost like you have to have the exact answer. And this goes back to my other point about amateur, pro-ams, and pros. Pros never act like they have the answer. 

Pro-ams do. And they say, "This is the way." And in their mind, this is the way because Google did it, or because I just read this blog post, or because it's got... it's got a recipe right here that I can follow. Because I actually don't know what I'm doing. But if someone smart said it, I'm gonna go do this. Where as a pro is gonna say, "our goals are to achieve this. And then we're gonna try this way of doing it because we need [00:15:00] to optimize X, Y, and Z to achieve these goals. And this will get us there. And if it doesn't work, we fucking throw it out." That's it. 

OKRs are a perfect example here. I can't tell you how many times I walk into an organization and they said, "Oh, we got OKRs. Do you wanna see them?" I'm like, "Oh God, no. I don't wanna see your OKRs. I wanna see where the work is actually happening and what work is actually getting done." And they look confused, but you can... If you have a series of three hours of conversations with key leaders around the organization, you're never... you're gonna circle a bunch of OKRs that are not being worked on and a whole bunch of hidden work, not on OKRs, thats kind critical.

Eiso: Yeah. And, and so it's funny, you, you bring up OKRs because we all wanna get better. We all believe in setting goals, but for some reason, OKRs and engineering, just don't go hand in hand. I have yet to see any organization where OKRs represent, like, you said, represent, what's actually being done. Why do you think... And it irks me, to be honest, because I... you read the John Doerr's book, and you look at OKRs [00:16:00] and, and you see how they can be valuable for your organization.

Jason: Yes.

Eiso: But time and time again, they fail in engineering. If anybody is listening to this and they really feel OKRs succeed in their engineering org, hit us up, 'cause I'd love to learn more. Why is it, Jason? What are your thoughts on why this happens?

Jason: Well, two... a couple things, one, John Doerr's... Most of John Doerr's OKR stuff, one, is from a factory. And if you think about why that works is it should be rather obvious why that works.

Eiso: Yeah.

Jason: It's a very different, different type of approach to engineering. It is an engineering, but it's a different engineering discipline at entirely. Two, I actually think there's a lot of conceptual things in OKRs that make a ton of sense. I call them alignment tools. And I love alignment tools. I just don't like OKRs. And I don't like, you know, a lot of things about OKRs, but I do love the fact that they're trying to align the organization in a way to have conversations around what's important. Further, I also think that we start to get really pedantic over OKRs, because again, we don't [00:17:00] understand the philosophy and the soul of what the alignment tool is supposed to be doing. It's supposed to allow us all to be on the same page about where we're going, why we're going there, who we're doing it for in the time of horizon that we're doing it under.

And instead, we start saying, "That's worded like a K, not an O, [laughs] and doesn't really mean that we can actually get the result that way, blah, blah, blah. And you're like... by, by the end of it, you just put something on a spreadsheet or a paper, so you can end the conversation. It's literally what happens in 99% of all orgs that do OKRs. 

And so, you know, you couple all those things together, and I don't think it works for engineering. It works pretty well for sales. It can work pretty well for marketing, it work, um, in finance. It worked okay. Product, no. Design, absolutely not. Engineering, very minimally. And the reason why is because it loses the soul. And I think that is, as an engineering leader, I understand this. It's very difficult to take an OKR translating into software engineering.

And it's much easier to say, "We're gonna go over here. We're gonna do this time horizon. And then the messy middle it's the draw [00:18:00] the owl." Ironically, this... the draw the owl thing, you understand that it's gonna be very messy to go from the sketch to the full owl, but for whatever reason, you know, we as an industry have taken it that, "No, no, no. It's actually to be really descriptive to do that."

Eiso: And, and it's funny because you we're going from one thing that irks me to the next kind of within very naturally, being pedantic. We are a space where we look at a lot of these challenges and we get incredibly pedantic about them. And while it makes sense to get pedantic at times on, on certain technical topics, there's a lot of examples that, that I see today in our industry that no one agrees with what we all do, right. So I'll give a, a very simple one that just... I see time and time again, and it bothers the hell outta me. Two or three reviewers on three line PR that's fixing a typo.

Jason:  Yeah.

Eiso:  Right? It's, it's one of those things like, "Yeah, we've decided to have two reviewers on every single pool request." But that's not the soul, that's not the purpose of what we're [00:19:00] trying to do.

Jason: And this, this... I could draw a direct line from this back to pros and pro- ams, because, again, like, it's, it's not understanding the spirit, the why, the soul, all that sort of stuff. And again, it's an awesome example because if you say it on the... on the surface, of course, you shouldn't need a reviewer for a three line, blah, blah, blah, particularly a typo. I mean, like, there's, there's somebody somewhere listening to this podcast who's going to be like, "I could come up with a one line change that everybody in the organization is gonna need to review." I'm like, "Yes, of course you can. Every time the database screen gets changed, we're gonna have to blah, blah, blah. Every time this gets changed. Yes." But that's not what we're talking about here. We're talking about the fact that, like, there's a category of changes where there's so low-risk, that the fact that we're gonna put them into a high burdensome scenario to get reviewed will grind the system to a halt.

And this goes back to another book that I don't think we talk about enough for engineering, leadership and leadership in general, this [00:20:00] is 1944, I believe it is, CIA handbook, which has been recently classified called the Subtle Touch of Sabotage. And its all these-

Eiso: Ah yes.

Jason: ... things that you could do if you were behind enemy lines in World War II, to grind the enemy organization to a halt. And they're, they're awesome ones. It's like reopening meeting topics from last time or making everything about the definition of something. And it's, it's amazing. Just go... you know, we can... we'll link it here in the podcast and people should go look it up. But I think in that way, there's a lot of things in here... in many organizations that are unintentionally, so are self-Sabotage.

Eiso: So I have the feeling we do this more in engineering than even in other disciplines. And I like to th- I like to think that it, it stems from the fact that you've probably sat in meetings like this as well. And, and some of my favorite engineers that I work with today will often push me or, or push people on our team to give the black and white answer and rule, because it's what we're... it's what we're looking for, right? Like, it needs... does the test [00:21:00] pass or does it fail? What are the five test cases inside that we need to do? And, and while that works... well, partially well for code, I don't think we're great at testing everything anyways. It doesn't work for these organizational topics. Do you think this is more prevail in our discipline because we're all across the org pushing each other for, for certainties?

Jason: I think... So this is again, I'm gonna show my, my own career path and biases here. But I think that it's the difference between mainframe monolithic thinking, where most often root cause can be tracked down to a singular thing, versus large scale distributed systems thinking, which is, there's almost never a certainty because there's a... there's a degree of, of risk in almost every single message being passed across and scenario and failure mode. 

And if you think about the two different types of systems that play there, and I'm using my hands for the folks on the podcast, trying to like show you that you've got a box on one side, where basically everything is kind of housed and [00:22:00] well understood. And like mostly handcrafted. If you think about what that looked like. To now, what we're running, you know, I think about GitHub scale or Heroku scale or Roblox scale, or like these massive, massive distributed systems where all of a sudden something broke for about two milliseconds and everything went haywire and then it fixed itself. And you're like, "What just happened?"

And you don't have an answer for it. You don't have an answer for it. Distributed systems thinkers understand there is no certainty. And they have to try to get to best postulation. And I think that those folks can deal with ambiguity in a very healthy way inside the organization. But there's a monolithic approach to thinking, which is, "No, no, no. You need to tell me what the PRD says. I need to have this doc written so I can take it from the spec and, and write it over here. And I need to know exactly what the stack trace says. Send me the stack trace and I'll de-bug it." It doesn't work that way. I- I've said this before and I'll keep saying it, organizations themselves are like less rational distributed systems. So if you think about it from that perspective, you already had a system that's not very [00:23:00] deterministic and you take a less rational version of that. [laughs] It's... you understand what's actually happening inside organizations.

Eiso: I love this analogy that you're making because at the end of the day, a lot of our faults in decision making, and I would even say as humanity as a whole, not just engineering, comes from the fact that we're trying to understand complex distributed systems in simplistic causal or correlated type situations, which are just completely impossible to do. We don't have the bandwidth to do so. And it's, it's like... it's like economics, right?

Jason: It really is. I was actually gonna say, it's more like...It's a Marvel movie where Dr. Strange talked about the Time Stone and all of a sudden there's a thousand different possible realities in each one of those. There's a thousand possible different ones too. I mean, that's, that's what we're talking about here. We're not talking about like, "we'll just pick the path and next thing you know, we understand exactly what happens when you do X in 1944." No, that doesn't... that's not the way that works.

Eiso: This is... I'm gonna sidestep here, Jason. Are you also a... [00:24:00] prefer Marvel versus DC? Do I have a fellow Marvel fan here?

Jason: I- I'm a Marvel fan. I grew up on Marvel comic books. I never really got into DC. So big, big time Marvel geek. And my son, who is now into comics is a big time Marvel person as well.

Eiso: Nice. Yeah. DC is just too dark for me. I think it comes from the wanting to have an optimistic view on the world. 

So if we look at, you know, things that irk us, what are some of the things that we haven't touched upon yet that you, you wish you could wave a magic wand and tomorrow would be different?

Jason: Well, we've talked about this before on the other podcasts as well, but I do think that we need more... I, I think we need more pros in leadership. I think we need more engineering pros at the top jobs in these organizations, particularly for, like, a whole of reasons that I just mentioned here.

Eiso: Yeah.

Jason: In particular, we need to look at engineering as... we don't... you know, I said before, when I started my career, I was an engineer, but I a cost center inside IBM. That's how I was coded as in, like, [00:25:00] I was an unfortunate expense that the company needed to hold on to. We don't think about it that way anymore in the industry. But we still think about that as the engineering leaders. We're like, "if you can just kind of like not speak up in meetings and just go do this, you know, we would be very appreciative of you." and I think that's a mistake.

I also do think that, this is kind of a strange one, but I think like going back to what you said about the simple answers, I think that we're, we're too often in this binary world, which is like, it's either or. It's gonna be this, or it's gonna be that. And it's never gonna be those things. But I think that we want some confidence around those, but you know, we don't accept the fact that there's some degree of a risk. I don't think that we talk about that enough. 

And then I'll say a couple of other things like slightly when it comes to, like, more specific engineering things. I think premature optimizations and the cargo culting that we mentioned before is so wasteful. It's very easy to see about stage like pree seed, A B, C, D, what you should and shouldn't have to worry [00:26:00] about there. And if you've gone through it a couple of times, and we've had this conversation in private a bunch, like, everyone thinks I'm against Kubernetes. I'm not actually against Kubernetes. I'm against Kubernetes before you get to pre-product market fit because you've not de-risked your company to earn the right, say that you need to scale to the world. 

And Kubernetes is great, but there's a set of people in the world who should deal with Kubernetes and not 99% of all engineers in the world. The fact that Kubernetes is exposed out to the random person who's building some marketing website for an agency, that's a mistake. That's a failure that we shouldn't... that, that is lazy thinking on how we should've given tools to engineers. That, that stuff irks me.

Eiso: I, I couldn't agree more with you. And, and to your earlier point for me, I... if I could wave a magic wand, it would be that everyone in engineering would be able to understand the impact of their work on the business.

 Yeah.

 And that's one of the things that, it doesn't irk me about engineering, but it irks me about businesses as a whole. And I think it comes to the point earlier of, like, engineering not being valued enough still to date in [00:27:00] certain rooms and conversations. You said this, I think from... I think maybe on the first or second podcast, right. Engineering is where the rubber meets the road. You take it away, nothing is gonna happen. And it's where so much value gets created. But still to this day, I see so many great individual engineers and engineering leaders that are doing great work, but do not have the ability to get the realization of what's the impact of what they're doing-

Jason:  Yeah.

Eiso:  ... and what does that translate to? And it's not always easy, by the way. I'm not saying this is easy to bring up, but it's... if I could wave a magic wand, that would be the one. Be able to show everyone what the impact they're having.

Jason: I, I, I agree. I think this is part of, like, going back to the alignment tools and OKRs too. It's very difficult. And that's what those things are trying to, to point to. But it- it's just a very difficult thing for people to, to break through to, and then we don't have the, the right language around it. 

Something else that occurred me that does irk me, and this is gonna be now, now obviously, I'm on the VC side as opposed to being on the CTO side. But I was irked equally as much on both sides of this fence. [00:28:00] I think a lot of times we confuse market capitalization or how financially well-off company is with how good their products are. And, you know, I... my famous example here, and I'm, I'm not shy about saying it, is Salesforce. Salesforce is a company I put my money into, but I wouldn't use any single one of their applications outside of Slack, which they acquired these days. You know, I used Heroku too, but they acquired that and they mostly killed it.

And it's the distinction of they're a good company. They'll make money. They've got a great sales team, but their products are terrible. And I actually think of them as user hostile. And I think we just need to divorce the two of those things. You'll see financial people saying like, "I love this company. I love this stock. I love what they're doing." Then you have stock that looses, like, "Oh, I have to hate my life using this thing." But we use an industry commingle them like, "Oh, they have to be good, but look how much money they're making?" Like, no, no, no. Those two things don't necessarily need to be tied together. You actually divorce them at very large scales in our industry.

Eiso: [00:29:00] And I would even say that too, to engineering cultures as well, right? You look at the-

Jason: Yep.

Eiso: ... different engineering culture, you know, Google and an Amazon, and they couldn't be further away from each other in terms of cultures, but we can... we're easy to say that they're good because of the success of the business. And probably the, the example that, that mixes, those both is for me is Atlassian. 

Like, I absolutely love Atlasian as a company. Everyone I've ever met from there has, has impressed me, but using JIRA as a product, which we use. And I think 99% of the industry uses to date, is one where all of us have a chip on our shoulder with the product and the product experience. And so it's... I think it cuts every possible combination. And it's just worth noting that, yeah, the relationship between success does not mean great engineering.

Jason: And I think it gets very confused very quickly as companies scale. It's obvious earlier in their life cycle, but it gets very confused later. And I think it becomes near impossible to actually untangle them until they get to a sufficient [00:30:00] size where it becomes easy to, to throw pot shots at them like Oracle. I think anybody would love to have founded Oracle and have been running or being VP at Oracle for the last 20 years. You'd be incredibly well-off. But you wouldn't be proud of the product you built. You'd be proud of the money you made. And that's a very, very different thing.

Eiso: I'll even take it a step further. There are organizations and products out there where you can be incredibly proud of the engineering you've done.

Jason: Yes.

Eiso: But not that all proud of the product that's actually-

Jason: And I think this is where it gets confused again, because you could actually have done amazing work, but you've got no customer uptake. And then everyone realizes that that doesn't work either. I get particularly irked when I hear about companies are just like, "Hey, the company's printing money, therefore, they've got to be a great product engineering organization or have a good product to sell." Like, "No, no, no, no. Let's divorce those two things and vice versa." You could have an amazing product, and it's gonna become bad business, because they don't know how to distribute. They don't know how to get sales going. They don't know how to go to market. And that's... [00:31:00] again, we should make sure that we're talking... we're having the right conversation and not talk past each other in both those scenarios.

Eiso: Yeah. And you just said words that I wish were... and this is one of the things that really irks me actually, is you just said product engineer, the product engineering org. It irks me that in many organizations today, it's not the product engineering org. It's the engineering org and there's the product org.

Jason: Yes.

Eiso: And there's tensions and they're not speaking to each other and their goals aren't aligned and org structures between the two are not leading to, to the right outcomes-

Jason: Yeah.

Eiso: ... which is absolutely ridiculous because you share the same goal. It really irks me that... and this is not everywhere. I think we're making strides in progress here. And I think younger startups and companies often almost always get it right just for the nature of, of them being smaller. But the fact that we're not... That it isn't considered a joint discipline to me really still surprises me, an I... and I wish we could do much, much better on that.

Jason: This is a topic that comes up when I'm talking to very large companies these [00:32:00] days too. And so they're asking opinions on this, and what I would do in certain scenarios. And I have a, a kind of a spiel, and I'll go into it, which is, if you can find the unicorn capable of- the pro, going back to the earlier phrasing. If you can find a pro you absolutely should put product and engineering and design under that one person. The problem is you can't find that unicorn these days, because there's just not enough pros to go do this. So what do you do? You wanna break them up and find three pro-ams, or one or two pro-ams and one pro of a certain discipline but not the mega discipline. 

Then they all report to the CEO or CTO or some, some coordination that looks like that, but its usually the CEO. And then what happens? The CEO gets annoyed because those three can't problem-solve together and says, "You three gotta get into a room and prioritize this effectively." "No, no, no. Mr. Or Mrs. CEO, that's now your job, you didn't actually organize this so that one person would prioritize that. You are the one person now. You are the, "pro" [00:33:00] or the "unicorn" that needs to make this decision.'" And there's a disconnect there. And a lot of CEOs don't know that that's their job. And I'm telling you, if you're a CEO of a couple thousand person organization, you got three product and engineering and a design person or, or some, you know, matrix of people reporting to you like that. And then you tell them to get into a room, figure out prioritization, you just didn't do your job. And I'm harping on this because I see it. I saw it over and over in my own career, and its a major CEO failling, and I see it continue to this day.

Eiso: I mean, and I think it comes down to the point that you've made very often on this podcast, and even earlier in this episode is, we need more CEOs who come from backgrounds where they have strong product engineering understanding. And in many cases still today, the CEO is not coming from an engineering or product background. They're coming from sales and marketing and understandably so because those have driven those businesses to success. But I think there's a whole host of companies today for which that just doesn't work anymore.

Jason: I agree. I think it works... It still works for a large set. And I think at a [00:34:00] certain scale. Like a very good example here is I think on this current... let's go back to Salesforce and give it credit. On its current course and speed, product does not define Salesforce anymore. It's all gonna be about distribution. It's gonna be about marketing. It's gonna be about positioning and narrative in the market. Like, you don't need a creative person to become the CEO of Salesforce. And I don't mean this as dismissive. You just don't. It's already that company. And if it doesn't do anything, it's gonna be 20% year-over-year. 25, 30 percent year-over-year. You do not need a creative person.

But look at Microsoft when Satya took over. If you put a sales and marketing... and sales and marketing, got it into that position with Steve Ballmer, if you put a sales and marketing person in, in charge of that, and you know, Satya is a product person, he's not really an engineering person, but he was a... he was as close as you were gonna get inside of Microsoft to that. If you put a sales and marketing person in charge of Microsoft, we would ne- we wouldn't be having a conversation about Microsoft these days. Satya is the reason why. And he's the closest example I think you have in the industry at the moment.

Eiso: I, [00:35:00] I think that's a great place to end today's episode on Jason. Are there any parting words, final words that you wanna add to today?

Jason: I think that we... I mean, this is a really fun podcast in many ways, because we got to, to talk about some of the things that annoy us, or we got irks with, stuff like that. The interesting thing is I still think the trend line is going in the right direction. I just don't think we're going fast enough. I think that 10 years ago, I would never get calls for CEO jobs. I get calls every week now for CEO jobs. And I think that that will only continue for people like me in the industry as they have more experience, and that... and, you know, I'm in my early 40s, and someone in their late 20s, early 30s, 10 years from now, who's similar background to me, likely is going to be running Google or, Oracle, or something like that, and trying to turn Oracle around or take Google from kind of like a flat line to a, an upcurve. And I think that'll be fine. I think that's the right trendline. And I hope that we see more of those, those folks in the industry, take over companies.

Eiso: Yeah, I hope so as well. And I think you're absolutely right. Like, one of the things that just lives in the nature of [00:36:00] engineers and engineering leaders is to constantly improve the environment in which we work. While the rate of change that we want is... well, is never gonna be high enough knowing how critical you and I are, but in its nature, we have continued to improve. And then I think I'm excited to see, like, besides all this, I'm really excited to see where we're gonna end up in. And I think that's also, uh, maybe a, a bit of foreshadowing to a future episode that Jason and I need to do on, like, you know, what does the future look like in 20 years?

Jason: And one more thing I'll add. My wife and I just had this conversation this week, because I think it was a difference in our personalities on a... on a specific topic. But she was talking about something, and she said, "Hey, you don't ever seem satisfied with what you have and feel like the goal post is moving." And I said, "No, no, no. It's actually not goal post moving. It's not any of those things. It's more of a, "Hey, this is all working, but I know that there's a 10% over here that is suboptimal or broken." And so instead of focusing on what I know is working, or at least to a higher degree than the other, I then turn my attention [00:37:00] in the aperture of opens up to a high 100% on that. 

So what it feels like to somebody else is that I'm already not grateful or X, Y, or Z over here, but in fact, what it is is it's working. So I'm gonna turn my attention over here. That's the difference between engineering mindset and non-engineering mindset, in my opinion. And I think that's what it takes to run companies.

Eiso: Yeah. And, and I couldn't agree more with you, Jason. And I think probably it, it leaves to a final irk that we can have people think about is, we should probably celebrate our successes more in engineering-

Jason: Yes.

Eiso: ... than we do today. And it's because of this mindset that we don't.