[00:00:00] Eiso: Welcome to developing leadership, the podcast where I Eiso Kant and my co-host Jason Warner, talk about the lessons we've learned about engineering leadership throughout the years.

Today, we celebrate our 10th episode with a very special episode. This is the one you should send to your CEOs. We talked about the things CEO should know when working with engineering leaders, understanding the complex systems and processes of building product, creating a higher level of empathy towards your developers, the questions you should be asking your CTO and VP of engineering and why these two are different. And as always much, much more. If you hear a topic on today's episode that you would like to learn more about, make sure to check out this episode's show notes linked in description.

[00:00:45] Hi, everyone. We're back again, Jason and I have a very, very interesting episode today that I personally have been quite excited about recording. It's the episode that you should be sending to your CEO. So if you're an engineering leader, listening to this, it's going to be interesting for you to listen to it. But we are specifically recording this episode so do you have something that you can send to your CEO on what they should know about working with engineering leaders. So Jason love to hear what, what your thoughts and excitement are about doing this one today.

[00:01:15] Jason: I always say as someone who basically grew up through the engineering ranks and understands the good and the bad, and maybe what some of the challenges might be, it's just going to be fun to get this out there.

[00:01:25] I think in general, too, one of the things that we don't overly appreciate about the engineering side of the world is that in early stage startups, it's usually the largest organization right away and in even mature, fully scaled organizations, it's one of the more complex. So we always think about enterprise sales as being incredibly large, you know, Microsoft and all that. But the coordination involved in enterprise sales is the same, if not higher inside of engineering, and at the end of the day engineers are the ones who build the thing.

[00:01:52] Eiso: Exactly, as you famously said, quite a few times, it's where the rubber meets the road. And I think in today's day and age, very few companies can still argue that software engineering isn't core to their being, or even to their existential being.

[00:02:05] You, you mentioned something to me, a couple of episodes ago that really stuck with me, and I'd love to start from there today. You said, you know, "when a CEO goes and asks their CRO or their Sales Leader, to prepare a projection, they're given time, they're given weeks to go out and gather numbers and build this bottoms up, but most commonly in the exec meeting room or in the boardroom, we have a tendency to ask the Engineering Leaders, "ah, product just presented this, or we have this great idea. How long is it going to take to build Jason?" On the spot, and at most, a couple of days. I'd love for you to share your thoughts on that and why that is the wrong way of going about it.

[00:02:46] Jason: So I think that struck me a long time ago when I was working with sales organizations and I was running the product engineering organization. And I remember people would ask me again on the spot, "how long will it take us to do something." And the engineer in me wanted to scream, which was, "I don't, we don't even know what we're building yet. We have a mock-up or we have a paper, we have a, we have a screenshot of something that we want to copy from a competitor. We have done zero work to understand this thing. And yet you want to get me to give you an estimate."

[00:03:19] And an answer of I'll go find out was almost unacceptable. People have said, "no, we just need to know we need to plan so we can plan out the rest of the organisation, about what we're going to go do." And yet on the flip side, when we're saying, "Hey, what's your quotas? What are your quotas going to be? Or what are your XYZ is going to be in the enterprise sales organization?" They're given weeks to figure these things out.

[00:03:39] And I think that two things were at play there. One was how well understood enterprise sales was, even, today, it's obviously more well understood, but it's been understood for quite some time. How you build out enterprise sales programs, how you build out areas and GOs and all of that sort of stuff. And also, I think more CEOs are familiar with sales, particularly 10, 15 years ago than they were the engineering. And on flip side, how radically misunderstood engineering was. And understanding specifically how you do about capacity planning and how you figure out how to get something done. And also there, we just didn't, in engineering, we just did not have the same sort of "methodology" available to us that sales had.

[00:04:23] I think I even sent to you a while back on one of the podcasts. I remember going into my very, very first board meeting where, uh, looking around the board room at everybody besides myself and the CEO, it was financier, financier, financier, X marketer, X salesperson, financier, or something like that. And they would talk about the marketing conversion funnels to sales efficiencies, to all of these different things about the business, which are incredibly important. Then they will look over to the product and said, "so what are you building? How long is it going to take?" And it was like, it was the disparity and dichotomy was so stark and obviously over time, I've started to see how that is not actually how really, really well run boards are. But it's also, I think, a testament to how poorly understood product engineering has been in our industry.

[00:05:14] Eiso: And since today's an episode for the CEO and let's, preface that with the CEO who hasn't been a software engineer an engineering leader himself, can we maybe start completely from the basics?

[00:05:25] What do you wish that a CEO knows about how software engineering is done, that helps them build that better foundation of understanding that stops them from asking you, "Hey, how long is this going to take? Or even just having the common misunderstandings of, "Hey, you know, why isn't this working? Can't you guys fix this quicker?" or just the level of empathy for, you know, "why was production down for 20 minutes last week?"

[00:05:51] Jason: Two things I think that are, or maybe a couple of things that are at play. One is, at scale and I'm going to jump to the middle, of this first and then come back to both sides of it, but let's say at a scaled company larger than a couple of hundred engineers, it's all about dependency management and you're understanding how engineering teams or an engineer or component or X, Y, or Z is dependent on something else from somebody, whether it be information from support or a "yes", from Legal or a, "this, this component needs to get done by this other team." there's a whole bunch of different things at play.

[00:06:28] And I think that right there, the lack of understanding of that, that is part of the big un-bundling portion for engineering to figure out if you can actually do something is all about sequencing and dependency management is really difficult for people to understand, because it looks like a small feature. It looks like you just want to add this button to the screen, but behind the scenes, there's a whole bunch of components that are needed for that. Or maybe there's a database somewhere, or maybe there's a, something or other that needs to get done, they just don't understand that.