Episode 10 | The Episode You Should Send to Your CEO

[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.

[00:06:58] I also think this goes to engineers, engineering leaders sometimes too, which is they only want to have one way of working, which is: Something comes into the product organization, you sequence it, you figure out which team is going to work on it, and you do all of the dependency management at one time, in one big grand "planning process". And so sometimes the small things do take longer to get done in that, in that model. But I think that the lack of understanding comes from when the CEO might've seen an engineering team of five people, very early on and they always want to get back to that same sort of cadence and energy, which is, "Hey, five people just kind of like frenetically worked on everything, and therefore they were able to blow through features really quickly. Why can't we do that when we're 500 people?" Well, that doesn't scale. That's the point of five people and frenetic energy is that type of stuff doesn't scale.

[00:07:49] I think, in the industry, we and CEOs in general too, and heads of engineering, try to get "rigorous" or "grown up" or whatever you want to call it. And they try to put these, these processes in place where everything fits inside the exact same construct. And that also doesn't work. I think the lack of dependency understanding is really what it comes down to, but I also think that we do sure ourselves as engineering leaders, sometimes in the foot, by not doing the full broken down process differently. But if I was to give any advice to CEOs talking to their VPs of Engineering or their Heads of Engineering is saying, "talk me through how we do engineering here. Talk me through how we do big things, how we do small things. How are we to get really big, nasty, gnarly things out the door in versus quick ones and are they all in those exact same cadence and structure."

[00:08:38] Eiso: And so you mentioned the VP of Engineering, you know, we recently did an episode on the difference between the CTO and the VP of Engineering. How should the CEO look at those differently? And, and should they be having the same conversation with each? Should they be requiring the same information from each year?

[00:08:56] Jason: So we've talked in the past too, about whether or not CTO and VP of Engineering report to the, ah sorry, CTO and VPs of engineering report to the CEO, or if a VP of Engineering reports to the CTO and all that sort of stuff. I'd say, this comes down to knowing your players, knowing your people. And each one's going to have a different skillset and they're not going to be uniform, you hire myself as a CTO or VP of Engineering, I'm gonna have very different skills than you, Eiso, if you were to be hired in the same role somewhere.

[00:09:25] So imagine you have a CTO who is incredibly technical minded. Very very architecture-oriented, but prototype-ei, you ask that person how long it's going to take to do something, you're going to get a very different answer than if you ask a VP of Engineering, who's very process-oriented, very methodical, and also very completionist. And you have to understand and how to filter the answer, how aggressive somebody is or how conservative they are or how hell bent on perfectionism they are. So you've got to filter it the answer is actually less interesting than understanding why they came to that answer in the first place. What is the pathologist psychology and also methodologies in which they want to go achieve those things. So that's why I think CEOs should have an understanding of that.

[00:10:09] Not at scale, they need to trust, like if you're a Microsoft, Satya doesn't know those things about his people in all likelihood, he probably knows like the various GM units and their approaches, but he's not going to go three levels down to a random VP of Engineering at GitHub or Twitch or whatever the thing is that Microsoft bought a while back. But you get the idea. But, hey, one day, we should all hope to be Satya running Microsoft.

[00:10:32] Eiso: Absolutely. So you raised a very important question is, you know, the CEO when they have their CTO and in many cases also their VP of Engineering reporting to them, they need to go in with a mindset of trying to understand the why behind the decision and, and what's going on there. As a CEO of a company with, you know, 50 to 250 engineers, how often should you be meeting with your CTO and VP in Engineering? Should you be meeting them separately, together, and what are some of the questions, if CEO's listening to this today can take into his next meeting with them that really helped them build up that understanding.

[00:11:10] Jason: I think in engineering is about expectation setting 90% of the time, both ways. CTOs and VPs to CEOs and CEOs, et cetera. So if your expectation as a CEO is that you really only want to get something as a trial out the door, that's a different conversation, than we need something that is enterprise grade and ready for 100% of all of our audience on day one. And so you have to understand which one of those things you're actually going for.

[00:11:39] And vice versa, if the CTO hears something and says, "Hey, what's your expectation on this?" But also kind of says to the CEO "for us to do this properly at scale, whatever, we're going to have to do X, Y, and Z as well." That's hidden work that you don't see, you know, maybe its scaling or maybe it's database work, maybe it's migration. You have to surface that. So it doesn't look as the expectation doesn't have a mismatch to the work involved. Because no one will be happy. You, you feel like you're, you're okay, getting past that initial conversation, but eventually that bubbles up and no one will be happy when that conversation lands. And by the way, in this one, right here, this is where CEOs and how they react is critically important, critically important.

[00:12:23] Eiso: So talk to me through the right reaction versus the kind of stereotypical wrong reaction that you've seen.

[00:12:31] Jason: Well, the very stereotypical wrong reaction is "that's not acceptable." Someone gives you an answer to something and they say "that's not acceptable. X, Y, or Z needs to be done faster or whatever." And the reason why is because that's, that's not understanding anything, you're just stating something. And with lack of understanding, you could be stating the wrong thing. You, if you, if that's your expectation and needs to get done in a certain amount of time, you should understand why, why this person is telling you it can't be done, now because there's a mismatch.

[00:12:59] And, yes, there's a whole bunch of people that are CEOs listening to this. And they might say, "I just want to tell my Head of Engineering that it needs to get done on this date. And I don't want to have a conversation about it." And I say, then you're probably not a technical CEO. You're not a CEO that's going to understand why the, one of the two most important organizations, if not the most important in the earlier stages is telling you something, would you ever, ever expect a quality leader to take that attitude? But for whatever reason, the industry thinks that's okay to do. So, a good answer in that case is like, "hang on a second, walk me through this because I I'm, I, I just want to understand, like, I don't care about quality in this case. I don't care about full-scale. What I really want to do is I want to go prove something like, oh, I thought we were, I thought we were rolling this thing out for everybody. Okay. Nevermind. Let me go rejigger, let me go figure out, let me go, you know, like rework the plan a little bit."

[00:13:52] Or another response could just be like "that's too long, like, that's just that we're going to miss the market, we're going to blah, blah, blah, or, you know, we're not going to hit our customer that we need to get. So what does it take to get this done in two weeks? What does it take to get this done in a month? What does it take to get this done in..." and, you know, there's a very classic set of questions you can ask people about thinking bigger, which is what does it take to add a zero? What does it take to 10x this, what does it take to all those different questions? Kind of get into that mindset.

[00:14:20] Eiso: Were still going to have no matter, how popular this episode comes, CEO's who are going to have that meeting, where they, they use their persuasive powers to convince that engineering leader, even if they know it is not correct to go get X done by date Y. And in many cases, engineer organizations will manage to get something done once, but the costs, the underlying cost of what it's going to cost the company down the road, tech depth, so to say, ends up servicing much later on.

[00:14:49] I'd love for you to share a little bit with some of the engineering, sorry with some of the executive leaders on this podcast, who are listening, what that really ends up meaning for an organization. For instance, I come across quite a lot of companies when, when we look at them through the lens of Athenian's data, where at some point, they've, you know, tripled in size, but they're no longer shipping software, even at the same pace or the same amount than they were when they were three times smaller. Likely because of a lot of those decisions that were made early on, with pressure coming out of engineering orgs. What should a CEO know about tech dept and what that really means?

[00:15:27] Jason: The whole concept of not shipping, is one we should explore as well, some point, because I think that there's a whole bunch of different reasons why people end up calcified, organizations end up calcified and not shipping.. Though say this, when it comes to debt, and we said before on this podcast that if you're undoing a decision 10 years into a startup's existence, it's likely the CTO's decision somewhere, and in fact, it's probably a combination of the CTO's initial decision, as well as continued decisions by the organizations not paid up at debt.

[00:15:57] And there is always a point in time when you have to spend cycles to maintain things. You just can't. There's a, there's the concept of gardening, if you want to use it for software, which is, you can let your garden go for a year, but the amount of effort you're going to have to do to maintain that garden once a year, the cost, the energy, the effort is very, very, very high. But if you were to do just a little bit of work every week or every month, or even better yet, just a little bit every day, you always have an actual maintained garden. Which one of those worlds do you want to live in? You have to make a choice. And I'm not going to tell you that maintaining your garden once a year at a high expense and high effort is the wrong approach. It's a choice that you can make. But I will tell you that if you're going to do that, you should have no expectation of getting anything else done in that time period, while you're maintaining that garden, like you have to dig yourself out from the debt that you're doing. And tech is no different from that perspective.

[00:16:52] In fact, I think one of the problems is that people don't understand that even in that, that metaphor that I just mentioned there, it breaks down because you still have to have people using your product, while you're maintaining that debt. And it gets harder and harder to do when you get larger and larger, the skills needed are just very, very different than maintaining something smaller over time. Which is also why one of the movements in software over the last 15, 20 years has been smaller, incremental changes more frequently because it's just safer.

[00:17:21] Eiso: I think there's something that I've seen a lot of CEOs and non technical leaders often miss out on is if thinking that, "Hey, if we have a hundred engineers in our organization, we're going to have a hundred percent of those hundred engineers oriented on shipping new features." But we can actually break those hundred engineers down into engineers responsible for actually adding to your application, versus engineers responsible for the security and the stability of your application, the infrastructure. And once you start looking at it that maybe from those hundred engineers, you have 30 or 40 who are actually responsible for adding new features to your application. But actually those 30 or 40 engineers are not just building new features, they're also solving bugs, they are doing some of that gardening work to reduce tech debt. And what we usually see is that about anywhere between 30 and 50% of the time of those engineers actually goes towards new customer value.

[00:18:21] And so if you take that onto person engineering org, you take 40 people and you take the good case of 50%. You actually only have 20 engineers that are really working towards building new customer oriented features. And I think that's something that's really worth noting for your CEO is that your a hundred people are not a hundred people building new customer value.

[00:18:42] Jason: So I think a good way to put this is, we've used this in the past as well in the podcast, but many people when you're building a product organization, want to build a cruise ship. And I say product specifically here, because I want to get to the engineering side of that thinking. Hey, every engineer in the organization is going to work in the same process, and I call it The Cruise Ship. You know, you're on the cruise ship and you're going in a certain direction at a certain pace and everything is scheduled and it's all sequenced and all that sort of stuff.

[00:19:09] But even so in that scenario, when you're on that cruise ship, let's say that you want to do that, and you're okay with working at 50% of your max feed, because that's exactly what a cruise ship is going to do, it's going to have plot along. And in that scenario there, you have staff on the cruise ship to maintain the engines and the ship, but you also have cooks and you've got servers, you've got people who have different skillsets. Now, yes, many people can flex up to a skill set, and let's say you had all hands on deck to go serve meals or something like that. Well, most people can be cleaned up in this, you know, that analogy and metaphor to, to do that.

[00:19:46] But it's a specific skillset to maintain the engines or the ship or the, or other things on there. And you have to understand that not everybody is going to be X or Y or Z. You're going to have to have some specialists. You're gonna have generalists and specialists. And I think this is where the lack of understanding of what engineering actually is, comes into play. Because again, going back to sales, we understand with the word quota carrier, how many quota carriers do you have inside your sales organization? Well, they ask that very specifically, not that you have a hundred people inside sales, how many quota carriers do you have? Again, you're understanding the sales side of the world, but for whatever reason, it doesn't map back to engineering.

[00:20:27] Eiso: Its first time I hear it, a cruise ship analogy, and I really like it. I think it's a very good one. There is though something to be said on the other side of the house. I've had quite a few CEOs have come to me and said, we had recently one on, on our podcast who afterwards said, "Hey, we just raised a ton of money. We're growing really fast. We need to go and, you know, deliver on this new product we're building. I've asked my engineering leaders that they, you know, they can hire as many engineers as they want. They can tell me whatever resources they need. Like I have that available. But when I go and ask around my exec room and say, Hey, we have X hundred million new capital in the bank. What do you need? Every single person on my exec room asked me for a lot more resources, engineering often doesn't ask me for a lot more resources." Can you unpack that a bit for me?

[00:21:16] Jason: Sure. So I want to go back to the cruise ship here for a second too, and say that if you were an engineering leader, listening to this, maybe again, we should do another podcast on this about engineering efficiencies and execution at scale. But if you're a product leader or an engineering leader or your product leader wants to help your engineering organization understand that a singular method for getting something done for getting all of the work done inside your organization, it's not likely to be the most efficient.

[00:21:43] You actually need multi boats. You need a fleet or an Armada of boats. You can have one cruise ship, or maybe you can have two or three of smaller size. So you don't need one mega cruise ship. Maybe you have three smaller ones, and then you have a whole bunch of speed boats and maybe life rafts or jet skis or whatever you get the metaphor, but you have different modes of being on the water. That's actually what efficient product engineering organizations look like.

[00:22:08] Now, the reason why I think that most engineering leaders, there's two modes you're going to ask, for it if you're an engineering leader, you're going to ask for all the head count, or you're gonna ask for none of it. And the reason why is you're going to ask for all is because you know that there's a whole bunch of people who are underwater when it comes to things like call or production maintenance, or you think that you can get more features done.

[00:22:28] Now, I find that the infrastructure and security side of the org asks for head count quite a bit, and then I also find that if production engineering or product engineering ask for head count, its because they think they can get more features done in the same amount of time. But interestingly, very, very advanced engineering leaders typically ask for no more head count because they know that adding more people to this is just an overhead actually. It's not fingers on keyboard is actually a whole bunch of coordination issues that are at play. And they, they, they're not going to solve that by more people there's ended up with more people doing the same amount of less work. Yeah, and the end, no one's going to be happy because then the CEO says, "I just gave you 20 new people and we're still getting the same amount of work done, or why is this late?" And they don't want to have that conversation.

[00:23:13] Eiso: So in the exec room, should the CEO be having conversations with the VP of Engineering and the CTO about that efficiency and effectiveness and what should they be asking?

[00:23:23] Jason: Well, I think of course the CEO should be asking and having those conversations. I think let's fast forward 20 years from now. You know, in our industry, in tech, you know, high-tech and this specifically, I think more CEOs are going to look like X engineers. I don't mean that they're going to be engineers through and through, or have run engineering organizations, though I do think that that trend will pick up and continue. I think they're just going to have a broader understanding and we, as an industry, will have a better understanding of product and engineering together.

[00:23:51] I do think inside the exec room, similar to how they have conversations with sales leaders, they should have those conversations with engineering leaders. And they should not have exclusive conversations with product, this is where I think it breaks down. Product can't tell you how long something's going to go take. They can actually go do the coordination with people, on the engineering side, to go figure out how long it's going to take, but when you ask a product person how long is it gonna take to get something done, you're gonna get a made up answer. If it's on the spot. If you ask an engineering leader in that same moment, it will be a little bit more educated, but it'll also be made up. So instead of asking them how long it's going to take, ask them what makes this possible in certain timeframes and what are you trading off. Don't expect an answer in the moment, expect a, "here's how I'm going to approach finding this out." Have that conversation. "What does it take to de-risk this? What does it take? What do you need to know? What information do you need? What are you going to go? Try to find out? Okay. What parameters are you putting into this?" That sort of conversation is the one that CEO should be having.

[00:24:52] And what I recognized by saying this now in the moment too, is they probably have no idea, they didn't even ask those questions because they've never actually run projects themselves because this is typical project management stuff. "What's the scope? What do we need? What are the must haves? What are the de-risking elements? What are the things that we don't know that we need to go find answers to as quickly as possible, so we feel justified in X, Y, or Z?" It's very, very typical things that anyone who grew up through the engineering leadership ranks knows implicitly.

[00:25:19] Eiso: So you mentioned something at the start of this, which was, "don't go just exclusively talk to your product leader." And I think because what you're mentioning, there's a lot of CEOs who haven't gone through that career path, where project management was, was a big part of it. There's just a more natural fit for many to go talk to their, their Chief Product Officer or VP of Product, and want to actually filter all the information through them, instead of talking directly with the engineering leaders. Why is that a wrong approach?

[00:25:47] Jason: So, it depends on your approach to this. So, let's say that you want the definitive answer to come out, but you actually don't want to have to worry about the details. You could talk to your product person if you want, and then expect that they're going to go back and get the answer. But if you ask the question to the product person, and they give you an immediate answer, I'd be suspect. How do they know? How do they get the information? Where'd they get it from? But if you want as much information as a CEO as possible, have the Engineering Leader in the room too, because then you're going to start hearing directly the concerns or the challenges or the various things that they have to go through in the thought process.

[00:26:24] I also do think, imagine that you have an offsite. It's an executive offsite and who you have in the rooms is you have the CPO, the CRO, the CMO, the CEO, all the C-level ones, and you've got a CTO, but you also have a VP of Engineering that reports to the CTO. You have an expectation that that CTO can represent the ins and the outs of the execution side of the organization. But you have to be really clear is that person is capable of doing that because then maybe the technical part and soul, but they're not the operational heart and soul of engineering. This is where engineering starts to differ based upon how you have constructed the leadership of the organization.

[00:27:02] So if you have a CTO that is the visionary, technical person, they've got a couple of engineers reporting to them, working on side projects, and then there's a VP or an SVP that reports to that person, that person likely should be at that offsite, the SVP. And the reason why is their concerns look very, very, very different, and while that CTO might be aware of those things, it does manifest very differently. And if you think about how many agregate people report to the SVP of engineering in total, yes, those will report to the CTO as well. That person represents then major, major, major, major unit, and they should probably be in that room.

[00:27:40] Eiso: I think that's a great answer. So to kind of shift focus here and look at it from a different angle, what do you believe a CEO should require from their VP of Engineering and CTO, in their communication towards them. Like what should you expect to proactively receive from your CTO and VP on a weekly, monthly basis?

[00:28:03] Jason: Well, I've always said, this isn't a proactive answer and I recognize that I'll go back and answer that one in a second, but I've always said that in engineering, the only unacceptable answer is, "I don't know," and it's not unacceptable because that's a bad answer. We all know that like, I don't know is actually a mature answer, but "I don't know, though I'll find out," is actually the answer you want as a CEO.

[00:28:26] And what you're looking for in all leadership positions in all companies is initiated individuals or highly issued individuals, people who will own their area and figure it out. So the, "I don't know," answer is half of the answer you want. "I don't know, but I'll figure it out or I'll find out or I'll go sort it out" is a very, very, very mature answer to get. Now, if someone just off the cuff gives you an answer, you suspect. Now, on the proactiveness, I very much, when you do staff meetings, obviously if you're a CTO or VP of Engineering and your other VP's are reporting to you, you have staff meetings and you want to get the reports back. CEO's should have some notion of these, of these things as well. Now, I think what you should expect out of your engineering leaders to report back to you are basically high level status. You know, we can call those things, the stoplights, the red green yellows of projects. Risks and then mitigation steps that you're taking. So this is where I think a lot of engineering leaders do fall down is they're going to bring a list of things that are risks, possibly, or things that could go wrong or things that are blockers, but they're not going to bring the next step.

[00:29:36] Now I want you to, I want all engineering leaders to hear this. I want to actually, I want everyone in engineering to hear this. Think about who you report to, who they report to and who they report to, blah, blah, blah, all the way up the chain. Now imagine that most of these people are probably reading your status update on the phone. Now, particularly if you're reporting to a VP of Engineering or CTO, or if you're a VP reporting to a CEO, this is almost a hundred percent true. That person is on the phone, reading a status update from you or something. And what they really need to do is within one screen, have one emotional feeling come through for this. Either, "oh, crap, I need to go do something" or "they seem to have this under control. Let me follow up with them." Your job as the person reporting these things up is to give enough information at a high level so they're aware, give them a sense of burning urgency or "I've got this" as well as, you know, drive that "I've got this" home with what steps you're taking and how you're going to follow up with it.

[00:30:38] If you don't do all of those things together, what you're effectively doing by status reporting up in those ways is actually creating more work for the chain all the way up. So when I think about those things, I can give you very specific tactical answers of how to do project status up, but that's what you're going for, is, the person reading this on their phone, on the fly, maybe at the park with their kids or whatever, has this emotional feeling of, "I have an adult over here who has got this thing handled. Yeah. I'm a little uneasy with the risk maybe, but like I'll follow up with them afterwards." As opposed to, "Hey Johnny. Hey Sally. Hey Susie. We need to go home right now because mommy or daddy has to go handle this burning urgent issue.

[00:31:20] Eiso: I think that's a great way of putting it. Actually it's the first time I've heard someone emphasize the phone and it is so true. It's the medium that most CEOs are consuming everything through and it does change the dynamic completely.

[00:31:33] So Jason, we've had a couple of people on Twitter ask us around communication style of, of engineering, people with engineering background is different by communication style with people who don't. I personally like to call bullshit a bit on this sometimes. I think there is there is a very, maybe too much of a stereotype floating around, and. But you said it, you know, quite famously, "everyone who's in an exec room at a company has their own quirks, but what are some of the, the communication, general communication tips that you would give to a CEO to really understand how to get to be the best communicator, best version of themselves, towards their engineering leadership, or do you just say, you know, this should be a role, but everyone in the exec team, and frankly what we say here today is more general advice and doesn't really have anything to do with engineering leaders in particular.

[00:32:23] Jason: I think this is one of those topics that people are going to really disagree with me on, because I think that there's this expectation that people might bend to the CEOs and the CEOs don't have to bend to others because of the nature of the role. I disagree with that because I think everybody should understand the humans involved in this. And we've talked before about sociologists and psychologists modes. You know, you have to make decisions in sociologist modes for the betterment of the entire company, but you also have to have a mode where you operate as an executive, which is psychologist mode, which is understanding the person sitting across from you. Because you have to actually filter, you know, maybe this person is overly exuberant and everything they say is a few of them positive, but actually what happens in practice is they under-deliver. So, they're overly confident, but they're under-delivering. Maybe this person is like super, super, super conservative. What happens is because they're worried about looking bad, they're going to be very conservative in the moment, but they're gonna over deliver because that's just the way they work.

[00:33:16] Well, if you don't understand your people, you're never going to understand what is actually happening in the conversation. So this is when it comes down to it. Like we understand this about coaching. Like if you're going back to sports, you, you can have a quarterback. That is one, one way like that pit bull mentality. And they're supremely talented and have won all these championships and their team loves them. And then you can have another quarterback who's a little bit more mild mannered, has the exact same talent profile and has won the same championships. You're not going to treat those two people the exact same way. I do believe that this should be a thing with all executives. You should understand everyone else around the executive room and how you communicate with them and they will change. And that's actually one of the secrets for me in my career is I understood how to glue that room together, the executive room, it is so important, and if you treat everyone as like this inter disposable set of parts, you're never going to be a team. You're going to be this weird amalgamation of oddly shaped blocks that doesn't look like an actual thing.

[00:34:13] So step one, I think is for all CEOs to actually do that sort of analysis, how, who are my people and what are their, you know, that sort of quirks and traits and adapt a little bit of the communication style to those people.

[00:34:27] Eiso: And so to, to bring this back to something even more practical, to what extent can you hold your engineering leaders accountable for missing expectations?

[00:34:38] Jason: I think you, you have to hold everyone accountable for all of those things. So I don't think there's any difference between missing numbers in product and engineering as, or marketing or sales.

[00:34:47] No, but I do think the difference in product engineering is that I just said product and engineering. I didn't say engineering because at the end of the day, the two of them need to work in concert for these things. Which is also why I really like product and engineering to report to the same person. Because at that point, then one person is still responsible. If you have the CPO and the CTO reporting to the CEO, the CEO is responsible for those numbers, not the PPO, not the CTO. And if you do understand what I mean by that, then you will understand exactly what I'm saying is, so if you have the CPO with engineering or the CTO with product, now you've got an accountable structure. If you don't have that, you have an unaccountable structure and it's on the CEO to make sure those things are happening. And no CEO wants that.

[00:35:31] Eiso: I think that's a great, great final comment. Is there anything else still today that you wish CEOs would take away from this? Jason?

[00:35:40] Jason: I had a long Twitter thread on this a long time ago. I call it the competence, confidence spectrum. And I think that if you don't understand your engineering leaders, you're going to try to filter them through a lens of others. And I've had this happen to me in my career as well. And I've had to adapt it for the expectation differences. And I remember, I was in an exec room when I was a younger engineering leader and the CEO said, or the, sorry, the CRO said something along the lines of, "well, holy shit, I got this. I'll go figure it out." And they came back in like three months later and they failed at that task. They did not get it done. But in that moment you could see the CEO just completely did not ask a single follow-up question because the overwhelming confidence exuded by the CRO put the CEO at such extreme ease. " Oh, that person's got this. Look at that person. That's a winner. That's a, that is an executive. That's executive presence."

[00:36:41] And I remember I was similarly asked around the same time about something and I tried to work through all the different scenarios and I tried to show them the complexity. And you could see that CEO lost complete confidence in my ability to get this done, even though I delivered on that thing, because it's the way I packaged and presented it to them. Now I have, I've had to learn to adapt what I call a confidence, competence, spectrum, and talk about things in a confident manner, but show that I have competence.

[00:37:05] And what I would say is, for CEOs to understand that most of their engineering leaders are going to try to overly show their competence. And they're going to lack some of confidence that they see in other roles, because it's just the nature of the job, that there is more risk, it's harder and more difficult to move components around, and, and things of that nature in engineering. I'm saying, I'm not saying engineering is harder than sales. It's not what I'm saying at all. I'm just saying the complexity of moving parts, the coordination and the sophistication of the systems are very different. And to pull these things off, there's a thousand ways in which these things can go wrong.

[00:37:38] And to have that sort of understanding about that side of the world, filter some of the answers that way don't hold people to the exact same communication style standards, set your, your understanding of the person and what they're trying to do.

[00:37:51] Eiso: I think that's a great way to look at it, and I think one thing to add is that one of the main reasons we're able to predict sales so well, is that sales truly is a pipeline. It's a funnel with things coming in from one side and ending up on the other. While engineering well, the way we build engineering organizations and the way they function, and we actually spoke about this earlier, when we talked about dependency management, it's really a complex system. It looks far more like a graph with dependencies between things and it relies on a lot of different moving parts. And however, we sometimes would like to look at it as a pipeline. It ends up being far more complex than that.

‍