The Pace of Innovation: Systems Thinking for Faster Engineering

Speaker A: Maybe in another answer to your question of how do you get more innovation from engineering faster is make sure you really guard the ability for engineering to do true research and development. Welcome, everybody, to another episode of the how many CTOs does it take Podcast. My name is Brad Heftegal, and my trusty co host is Scott Porad.

Speaker B: Brad, how are you doing today?

Speaker A: I'm doing pretty good. I'm doing good.

Speaker B: Were you just in Hawaii?

Speaker A: Uh, that was like a month ago, but yes.

Speaker B: Then you were just in the mountains?

Speaker A: I was just in the mountains.

Speaker B: What's happening up in the mountains, man?

Speaker A: It was, it was. I got. I only got one of six peaks done. It was, it was quite an adventure. Was some sketchy. And, uh, we made safe decisions and came home.

Speaker B: That's good. That's the safe decisions is the victory.

Speaker A: But it was a lot of fun. We, we, uh, we are in this zone called the Chilliwacks. It's incredibly beautiful zone. Really rugged, really beautiful though. And we, we, um, were camping under a glacier that we were watching like, cal off and then tumble down cliffs into a lake nearby. Um, that was kind of wild. Um, and, uh, had beautiful, beautiful weather, beautiful scenery, and, uh, yeah, that's what we did. It was fun.

Speaker B: That's. That's awesome.

Speaker A: Uh, what were you doing while I was away in the mountains?

Speaker B: I was having so much fun. Tell me this will date our episode. This will probably come out in early to mid August.

Speaker A: Oh, yes.

Speaker B: I went to two baseball games two nights in a row. And then I went to a World cup game in person in Seattle. And then after the World cup game, I went to a bar and watched another World cup game. And then that got me to Wednesday. What did I do on Thursday? I mean, I don't even know. It was just. I had a great week of, of just doing fun stuff.

Speaker A: Awesome.

Speaker B: Love it. Oh, I know. I. I know. I concluded that week with a big, long bike ride. And, you know, I said to myself, if every week was like this, my head would probably split. It could just be too much fun. I'm not used to having much fun.

Speaker A: Too much, too much winning. Love it. Well, the World cup certainly was an exciting time. I think, uh, I think, uh, you didn't even have to necessarily be a soccer football fan to just get the excitement coming off of all that stuff.

Speaker B: That's right. This isn't a soccer podcast, but I think I finally figured out what constitutes a foul in soccer.

Speaker A: Oh, no, I don't think I understand that.

Speaker B: I haven't understand it. I've been following. I'm not a. I'm not a lifelong soccer fan. I started following soccer about five or six or seven years ago, and I've always been puzzled as to what constitutes a foul. I think I. As a result of watching so much soccer over the World Cup, I think I finally figured it out. And I think it goes like this. If you kick the guy before the ball, that's a foul.

Speaker A: But if you are kicking the ball,

Speaker B: if you kick first, then you're fine. That's the first rule. The second rule is if you kick the guy or shove the guy from. You can't shove or kick from behind. No, no, from behind. Anything, uh, from behind is. That's a foul. Otherwise, do whatever you want. Oh, I'm sorry. Number three. You can't touch it with your hand.

Speaker A: You can't touch the ball with your hand. Unless you're the goalie.

Speaker B: Unless you're the goalie. Otherwise, do whatever you want.

Speaker A: Love it. Love it.

Speaker B: There you go. I think that's it. As near as I can tell, that's it.

Speaker A: There you go. Yeah. Cool. Well, what. Um, you texted me right before we started this call and you said, brad, I got a topic for you. We got to get on the call and we got to talk about a topic.

Speaker B: Oh, I took a two hour. The beginning I took. We're, uh, starting a course, I don't know if you'd call it a training situation at our workplace, um, led by an external facilitator about change management.

Speaker A: Oh, boy.

Speaker B: And it's very exciting. Well, I mean, it's exciting in a business context. It wasn't like going to a soccer game or a baseball game. Exciting nevertheless. Uh, so this person talks about, um. Okay, often when we want to change things, we talk about technical aspects. Let's change this way. We do something or this process or something like that. And then she said, you know, then there's a level up there. We try to change technological. The first is technological. The second level because, like, then we try to change, like, psychological aspects. Like, uh, we try to create core values and we try to create psychological safety and things like that. And then she said the third level. And this is what she wanted to get at. This is what our, like our 10 hour training course is all about, is what she referred to as system.

Speaker A: Okay?

Speaker B: And she. And we know about systems and engineering because we deal with systems all the time. And she described a system as, um, I can't remember exactly words, but it was basically two or more entities in with a Boundary. So imagine you're in an elevator. It's just yourself. So it's you. That's one entity, and there's a boundary, the elevator. And then I enter the elevator, and now there's two people. And together we are a system. Okay? And there are a set of norms and rule. There's a way that system works. For instance, we, uh, have norms, both spoken and unspoken, about how that elevator works and how we interact in that elevator. This was the analogy she used.

Speaker A: I'm just cracking up over all the, the weird things you can do in an elevator. You know, like, for example, if you get in the elevator and you face backwards, most people in the Western world are going to think you're a weirdo.

Speaker B: Right. That is not how that system works.

Speaker A: Right.

Speaker B: And so one of the things she was talking about is if you're trying to change an organization, you need. First she was saying, if you're really trying to change an organization, you have to change the systems. And one aspect that she was talking about was if you want to change systems, you really have to get to the unspoken norms, the, the rules that everyone knows, but nobody has written down. There's no user main. No one ever gave me a user manual for how to go to an elevator.

Speaker A: Right, right. Yeah, but you figured it out quickly.

Speaker B: Yeah, you figure it out. You know, you're a little kid and your mom, you go in there and you push all the buttons and your parents say, don't do that. And you learn, right? Some point you turn backwards. Everyone's like, that's weird. Or you see somebody else turning backwards and your body says, that's weird. That dude was standing there. You learn. Right? Okay, so that was one aspect. But the aspect that I thought was interesting for this conversation. We have a culture of, uh, providing feedback when a system isn't working. We have a culture of providing feedback and asking other people or other parts of the system to change so that the system works better. Like, we have a whole. Actually, she used the word. We have an industry built up around feedback, which is true. Like, I mean, there's companies provide tools. And so it's an industry. There's HR companies and systems. And so she talked about getting other people to change is really hard, and getting yourself to change is relatively much easier. And so if you want to change the system, actually first start by thinking about, how am I operating within this system and what can I change to start to get the dynamics of this system to work differently.

Speaker A: Yeah, totally.

Speaker B: Such that. Such that it'll get the Better outcome. I want. Okay, so that led me to another thought, and this is the one I want to talk to you about. Almost everywhere I've worked, people want the system to produce engineering output faster.

Speaker A: This is like episode number two of the podcast.

Speaker B: And so, um, I thought to myself, and this is, this will be a very, very meta question. If we were going to change the system. Well, and I'm sorry, I need to point something out. And typically the way people say to get stuff faster is to say, engineering, you need to do stuff faster, right? And then engineering says, okay, well, we need to, uh, change processes or we need to change ways we do stuff, we need to change our technology, um, so on and so forth. But I thought to myself, okay, if we wanted engineering to produce stuff faster, if the company, if other people in the system wanted the engineering part of the system to produce stuff faster, but they couldn't ask engineering to change, they could only change themselves. Yeah, what would it be? What would change? Now I get this is a little meta, because I'm going to be. I'm. I'm the engineer saying, you should change this part, you should change this part. So it's a little, it's a little violating the principle of what this, uh, you know, person who was leading this training was going out. But it just that it. That thought came into my head was like, oh, interesting. Instead of department X or department Y or whatever saying, you guys go faster, you guys go faster. What, what should, you know, finance, hr, marketing, product management, commercial operations, biz, dev, customer service, legal, et cetera. What would those groups change and do differently to get us, the engineers, to be able to get stuff done faster?

Speaker A: Man, that's a great. I love it. That's a great meta question. Do you have answers to this or do you. You just, like.

Speaker B: I have some snarky answers.

Speaker A: Okay. That's at least somewhere to start. I mean, I guess, I guess. Let me, Let me just see if I'm, if I'm, if I'm picking up what you're laying down here. I mean, in the zeitgeist, uh, especially in the world of AI coding, right? In the Zeitgeist, there's this real, this real question of, like, if you make all of the code writing instantaneous, M. What else in the system breaks? And that's sort of where my mind is going to answer your question.

Speaker B: Uh, how many minutes into this are we before you got to AI? Because I could play the other way around, which is right now, companies want engineering to go faster. So they say they're telling us to change and use more AI.

Speaker A: Right. But that's what I'm saying is. Okay, yeah, yes, so agreed. So that's. So I love your thought experiment of saying like, well, what has to change other than engineering in order to make engineering be able to go faster? And like I have a couple immediate answers to this question that I would say almost every single organization I've ever worked in would have if all of a sudden the engineering building stuff was instantaneous.

Speaker B: Yeah, yeah.

Speaker A: Uh, there's two places that would collapse immediately or would become apparent immediately as the problems.

Speaker B: Right. Because the instantaneous means you can't ask it to go faster. Right. Because it is, it's as fast as possible. It's a speed of light.

Speaker A: It's the speed of light. Right. And so the first place that you'd have a problem is deciding what you want to build.

Speaker B: Yeah, right.

Speaker A: Like, like, like, I mean, uh, you and I, when we were at Health tech company, right, like they had, they put a ton of time and energy in their SDLC around the whole deciding what to build. And there was this, all this process of like these, these. There was a little bit of like, you know, TPS reports, like forms in triplicate that had to get filled out, you know, and, and who was the signer that was allowed to approve from security and from compliance and from medical. And, and um. So that's an environment where. Oh my God. Like if we're coding like crazy now, like we, we're instantaneous speed of light. Like the bottleneck would be like, what are we building? Like who's deciding what we're building? Like that would become a huge problem. So if I flip, so, so if I sort of flip the script there, one might say, like, if you want engineering to go faster, make sure you have a, uh, like basically make your shovel ready plans come faster.

Speaker B: Yeah, right.

Speaker A: Like how quickly could you produce your shovel ready plans? Yes.

Speaker B: Or you can push that further. Come with shovel ready plans.

Speaker A: Come with shovel ready plans.

Speaker B: Don't come, don't come with a line in a spreadsheet that says make a flux capacitor.

Speaker A: Right. Come with shovel ready plans.

Speaker B: Now your hypothetical here about instantaneous code brings up something. There's an implicit, uh, potentially something explicit implicit in that hypothetical, which is, is the ability to create code in that hypothetical constrained. Because there's actually two parts to the going faster. One part is how fast can the team get a given piece of engineering done. And the other part is what is the overall capacity of the team to get things done. In this example is, uh, there unlimited capacity? Because I think one of the things that might change outside of engineering has to do with capacity and utilization. There's all sorts of research, which is if you want a system to operate most efficiently, you can't run it at full capacity. You have to run somewhere between like 50 and 80% in order to maximize output. Right. But in our industry, we, we really try to maximize the utilization of our. We don't want our engineers sitting around. Like that's the worst thing possible to have an engineer sitting around with nothing to do. Which I've never ever seen in my life, by the way.

Speaker A: Right.

Speaker B: Um, I think there's a, A piece there about something that could happen outside of engineering is thinking, I'm not exactly sure what, but something about maybe it's just the expectations or the standards for what capacity or I'm, uh, sorry, what utilization the organization wants to use of its engineering resources. And if it were committed, if it was really disciplined about being in a more optimal zone, it might get more output.

Speaker A: Sure. Like, but to me that just sounds like another way of saying, make sure you know what you want. Be good at knowing what you really want.

Speaker B: Yeah, it's a, It's a different layer. You. We were talking about knowing what you want for a given thing. Have it show already. And then there's like, also have your queue of things ready. Have them in order and ready to go.

Speaker A: Exactly. So this is another thing that pops in my head immediately when you talk about, like, the idea of like engineering going really fast is. I've been in many organizations where, you know, and again, this happened with us at Health Tech company where, um, the primary users of the software platform, the medical team, they kind of were like, hey, stop giving us features. Like, you can't give us features too. If you give us features too fast, we have to get trained on them. Right. So depending on how, uh, mission critical or how critical the thing that the people are doing with your software, like, yeah, you got to be able to train people to use the software or you got to be able to make sure that your downstream release processes. Right. Like whatever releasing looks like. Right. Like if releasing looks like customers install it and customers use it and customers configure it, well, how good are you at that?

Speaker B: Right.

Speaker A: How good are you at taking the finished product and getting it in the hands of, of the real customers? Like, that's another huge bottleneck I've seen in my.

Speaker B: Yeah. And, um, a tangentially related one, like you've Talked about installing software also, like the integration with other parties, right? Yeah, that's often a big piece. Like, hey, we've got our API done and now there's a whole integration testing cycle thing.

Speaker A: Yeah, totally.

Speaker B: And now that we're getting in the engineering space, because my answer to that is always like, oh, we got a good sandbox and good documentation and good, you know, good ways for these people to mock their stuff up or whatever.

Speaker A: And like, I'm just trying to say, like, blur the camera a little bit or you know, kind of blur your eyes a little bit. And, and really whenever we talk about speed through a series of steps. And so I love your system, I love your point that this, this, this uh, trainer, educator was trying to get you guys to think in systems. And the thing I'm saying is like any one of these, like if software, if the building of the software is a piece of a sequential system, then the things on both ends of that, to make the software go faster, the things on both end of that also need to go faster and be ready and be prepared. And what's interesting is there's this really nice, you know, there's this thing that like I remember I've been frustrated in the past by product owners that didn't necessarily. That always sort of thought of themselves as like, I invent things from whole clothes and I'm the one that has the vision for the product. Okay, cool. There's like, some people are great visionaries, but really you need to make sure that you know what your customers want. Right. So that's another thing that I feel like, what other things do I need to make true to make software go faster, to make engineering build stuff faster, is I need to really know what my customers want. So what were your snarky answers to this question?

Speaker B: Oh, you know, just like, leave us alone. Okay, that just nonsense like that. Is that.

Speaker A: By the way, I'm super curious, is that actually like, are your other leaders. As soon as this, this conversation around systems change and systems changing came up, the first thing that they wanted to, to figure out how to do to change is make engineering go faster.

Speaker B: No, no, no, that was not at all part of our conversation. This was, uh, this was, you know, actually this was my thought which was like, oh, well, I know where all this systems thinking is going to go. It's all going to go towards engineering going faster. And that even that I was reflective for a second. I was like, wait a second, am I just stuck in a pattern of like, you know, Stockholm? And isn't Stockholm syndrome. That isn't the right way of phrasing. But am I stuck in a pattern of not having, believing in good intentions that are people's good intentions here? Um, and am I stuck in my world of engineering that I can't imagine that the finance person was thinking about how they could get accounting done faster and close the books faster if the marketing person wasn't thinking about how they could get their creative done faster. Or not even students even say faster. Uh, I'm just, again, I'm stuck in my world. The accounting person might have said how can I get close the books more accurately? And the marketing person might have said, well, how can we improve this system to make our creative for our advertising better or resonate with customers? Yeah, we didn't have that. This was just chapter one of I think like five of these sessions and um, or about 10 hours of these sessions. But you know, I'm so like, I think almost scarred from just a career, a career of everybody saying engineering go faster. That that's where my mind went to. And it just, and then I just sort of thought like, oh, okay, if all these people want us to go faster, how are they going to change?

Speaker A: Yeah.

Speaker B: And so um, and I, into that point I even had a hard time imagining like I've been so beat, I got such the abused puppy syndrome. I've been so beat down, I couldn't even hardly imagine how other teams might change.

Speaker A: You know what I think is interesting? Here, let me, let me uh, let me zoom the camera out a little bit more. Um, one of the things I've been thinking about recently and um, it's funny because maybe uh, my LinkedIn, my LinkedIn feed has somehow been filled with like PE CTO recruiters or something like that, right? So, so this question of like, like as a CTO, right? Like, God, uh, there's so many times that CTOs are like confronted with challenges of like, you know, maybe they, maybe they're working through like instability problems or maybe they're working through performance related problems like uh, around the team being able to move quickly. And maybe there's like years of back of features that people uh, wish were implemented. And I think that the harder problem is are we building the right stuff? Is the stuff we're building actually going to move the needle of the business? To me, that's where the really, that's the juicy questions that are out there. And I think that one of the things that I think is so important about being a CTO as opposed to being the VP of Engineering or something is being able to really be a business technical thought partner. Right. And helping understand. So what if we built this stuff faster? If we're just building stuff that's not actually going to move the, the needle of the business, then that's not doing anybody any good either.

Speaker B: Yeah, I was really proud of our product management team. They've started a practice of uh, going back, it's a two quarter lag because they, when something goes into production they need some time to get some data. But of really comparing what did we predict this investment was going to do and what's, and what's the actual outcome been? And um, I've seen that at other places but I've seen it, I'm seeing it be done very well where I'm at now at TaskRabbit and like that is, that's the name of the game. Like they're not going to get it right. I understand that.

Speaker A: Sure.

Speaker B: In this business if you get it right a third of the time you're a Hall of Famer. It's like baseball.

Speaker A: Right.

Speaker B: And so um, but the key is to go back and look at it and say, okay, what happened here? We thought if we did this then this was going to happen and then some change would happen in user behavior and we would get these results. And so um, I think it's really, really valuable to, I really appreciate that they're going back and looking at that and then the most important, going back and looking at it. It's only the first step. In fact, it's not even meaningful. Uh, it's meaningful but what's, it's not even impactful. What's impactful is saying okay, how are we going to learn from this? What are we going to do about it? How are we, what assumptions are we making about investments going forward that we're going to change based on this. And I'll give you an example. It goes both ways. I'll give you a positive example. Uh, we made a change to how we pre authorize credit cards up front to um, uh, minimize fraud. And instead of just doing like an ordinary credit card pre auth we were actually billing for an hour of time and this was pretty complicated because the amount of somebody's job on TaskRabbit is variable. So there's all sorts of, after the work gets done, there's all sorts of adjustments you got to make to make it all sum up. So it's kind of a complicated project and the team has been working on it for quite some time. But there was A lot of fear about this is going to impact, like, our, uh, conversion rates, because people are going to see that they're going to get charged for an hour up front and they're going to be apprehensive, I don't think. I'm pretty sure, if I recall, the fear was overweighted. And the benefit to minimizing fraud, basically fraudsters using fake credit cards and stuff like that, was even greater than projected. So, you know, as we have the conversation, and I say a minute ago, you know, you'd get a third of them. Right. You're a hall of famer. Here's a case where we learned, oh, actually, we don't have to, you know, we're too fearful of some of this stuff. Right.

Speaker A: Yeah.

Speaker B: And the upsides of managing fraud is even there's even more fraud than we thought going on on the platform. And so there's not. I need to clarify, especially for the lawyers out there, Ben, there's not that much fraud going on the platform, and we're doing a great job preventing it. And so. But, uh, but the point is this.

Speaker A: The point is that this change the team was. I mean, I've been in these meetings, right, where someone goes, hey, if we make a change to credit card processing, a uh, small change, there can have radical impact on numbers. We're going to see breakage. People are going to, you know, we're going to see. That's going to scare people away if they find out they're getting charged, you know. And, um, you know, is there really that much, like, cases where we're getting these chargebacks, you know, is that really happening that much? You know, and so. But you develop this model where you're like, okay, we're going to do it carefully, uh, because we are afraid it's going to, like, cause problems. And it's. Is this really that big a deal? And then next thing you know, you've implemented it and it turns out you go back and you measure it and you go, wow, not only did we not get the breakage, not only did people not, you know, cancel orders, but it had no. It had minimal effect on that. And it had net very clear positive impact on cases where there would have been chargebacks.

Speaker B: That's right. That's right. I think so often we are attuned, what I would refer to looking for, you know, we're so attuned to trying to avoid, you know, look for our mistakes, avoid making our mistakes. You've talked about this before when we talked. I think we've Maybe talked about retrospectives and you've talked about this. Looking at what did we do right. Can we do more of that? I don't remember exactly the context you brought that up in, but we're so attuned at looking at what went wrong and trying to fix it that we often don't try to learn from what went right.

Speaker A: And I think that, and yeah, 100 I, I, I'm a big believer in that. That like, a lot of times when things go right, people say, oh, that went great. We don't need to talk about it.

Speaker B: Like, yeah, uh, yeah.

Speaker A: And the reality is, I believe that when things go right, that's the best time to pause and really interrogate. Like, what did we do differently here? Or what did we, what is it, what is it in our system that contributed to this success that we had?

Speaker B: Yeah, that's right. We were probably talking. I know that. I think about it. I think you're bringing that up in the context of avalanche awareness.

Speaker A: Oh, yeah, we do that.

Speaker B: You do that all the time. Right.

Speaker A: Because we're, like, trying. Because, like, every time you, uh, every time you don't have an accident, right. You're asking yourself, was I lucky or did I make good decisions?

Speaker B: Yeah, that's right. Okay. So actually we have stumbled into, I think, a huge thing that every team, including engineering, but also all the teams outside of engineering, can also do, which is build really good learning feedback loops.

Speaker A: Yeah, right.

Speaker B: And, um, we have those feedback loops in engineering, as you know. In fact, I'm giving a Present All Hands presentation on Monday. About one of them, or Tuesday. Um, not that that's relevant to our podcast listeners, but, um, about our incident response process and our postmortem process and how all that works and how, um, you know, I'm starting out my presentation by saying if failure is our measure of success, then we have achieved victory because we have problems. We have problems all the time in engineering. The systems are failing all the time. And the name of the game is to get really good at learning about how you made those. And if you think about or not how you made them, but what caused them, how to fix them, and if you think about our entire industry, I started building online services, we called them websites back then, 30 plus years ago.

Speaker A: Yep.

Speaker B: And the stability of online services today, knock wood. Is incomparable to what it was 30 years ago.

Speaker A: Right.

Speaker B: Even to what it was 10 years ago, it's incomparable. And so that's all because as an industry, we made mistakes, we learned from them, we made M mistakes we learned from. We kept on building layers upon layers on layers upon layers upon layers of learnings. So we can get to a point where, knock on wood, we can keep these systems that are now kind of vital to really, every aspect of our lives, uh, up and running. Can I detour for a second? On systems that are vital to every aspect of our lives. Okay, this is a total add side quest we're going to go on. TaskRabbit operates in Europe and apparently the country of Spain. Have you heard of Spain?

Speaker A: I have heard of it. It's a country.

Speaker B: You ever been there?

Speaker A: I have, yeah.

Speaker B: What do you think of it?

Speaker A: I love it. We went to. We saw a lot of beautiful architecture. We saw a lot of beautiful art. We ate some beautiful. Some delicious food, drank some delicious drinks. It was great.

Speaker B: You did all the things you do in Europe. It's great. Well, apparently they have passed a law which, if you operate a business in the country of Spain, you must accept customer service inquiries by mail and you must respond within 15 days in, you know, their approved languages, which I think are three different languages in Spain. And so a company like TaskRabbit now, I guess we have to go set up a mailbox and employ a person to go check the mail every day and then somehow get that and translate it and get into our customer support system and have someone figure it out and respond and then print out the response and fold it up and put it in an envelope and find a stamp and send it back.

Speaker A: Love it.

Speaker B: So the entire world is not online yet.

Speaker A: Just like. That's, uh, just like, awesome. That sounds like a service. Somebody. There you go. There's a business for you.

Speaker B: It's funny you said that was literally just this week. I was talking to someone at our company about having to do this engineering doesn't have to do anything for this. It was just. They were talking about how they had to deal with this, and I was. I was like, that's exactly what I thought. I was like, oh, that's an interesting little business, right?

Speaker A: Just have a bunch of mailboxes. I mean, there. That is the business, right? There is people that do that business. You know, in the US the, uh, um, you know, uh, registry registered agents for LLCs. You know, my. My LLC's got a registered agent. There's a mailbox there. Um, and when any paper mail comes to me, I get an email with a. With a, you know, scanned copy of it.

Speaker B: Okay, so where did we. I don't know how we ended up here.

Speaker A: We ended up There. Oh, you were saying all the systems. The systems that just are working in. The systems are working in the background. Are you going to talk about the postal service?

Speaker B: I was just going to say sometimes we go driving down the road and we end up in a cul de sac.

Speaker A: Uh, drive around in circles in the cul de sac.

Speaker B: No, we were talking about, you know, if a company wants their engineering team to go faster, what are things that non engineering teams can do to essentially facilitate that? You said one, um, have things shovel ready. You said two, be clear about the things that you want to have done. I don't remember if there was a third thing you added I threw in there. Um, have learning feedback loops. Somehow we got in talking about, uh, whether things worked or not. So I would. That sort of led to, um, having clear learning feedback loops all over the company.

Speaker A: Yeah.

Speaker B: I think is another puzzle piece that I might add to it. Here's one I would add which might ruffle the feathers of every single person not in engineering in the entire world.

Speaker A: Okay. I want to hear it.

Speaker B: In the companies I've worked at it, mostly the finances go something like this. Hey, we made $100 this year, and next year we want to make $120. So, um, we think just by doing more marketing like we did this year, that that'll get us $10. And so now we need to come up with some new features and some new product ideas and some things like that that'll get us the other $10.

Speaker A: Yep.

Speaker B: And then, you know, there's product managers that facilitate that process of deciding, uh, exploring ideas. Oh, I'm sorry. You talked about knowing your customer. Knowing what your customer wants is an important thing. Okay, so I forgot about that one. So, okay, so then there's product managers. They go talk to customers, they talk to stakeholders, they decide this is what we should do, they specify it, etc. E. And then, you know, if we need 10 more dollars, we try to come up with $30 of ideas because we know that we're gonna only get one in three of them. Right. And, um, in my experience, roughly speaking, a third of things succeed, a third of things actually make stuff worse. And the third in the middle just kind of don't have any impact at all. And, um, so we, we come up with $30 worth of ideas, and then we try and do them all. And, um, and hopefully some of those are winners out of that process and we get our 10 bucks. And I've been fortunate in my career that typically that's work. Engineering is largely An R D exercise. Research and development exercise. Yep. And so probably if we wanted to get more out of engineering and have engineering get stuff done faster, I have this hypothesis. I can't tell you exactly the mechanics, but if we didn't have that $10 on engineering, if the company said, well, we have a hundred dollars this year and next year we think we can get 10 more dollars by continuing business as usual and we're going to do some R D and maybe that'll give us a windfall and maybe it won't. Right. And there's something, I can't explain it, but qualitatively it just feels like it would lead to a dynamic that would result in a combination of. I think people would take bigger bets.

Speaker A: Yeah.

Speaker B: But simultaneously I also think people would be much more focused on actual like customer problems, not on. Here's the idea, I think that can make us money. But here's the thing that the customer is telling me would be better. Um, I think it might take some of the edge off that causes people to cut corners. You know, there's always this thing that people feel like, well, we made an MVP and then it didn't really deliver the results we expected. Was that because it was like the minimum viable thing, maybe if we had built it more full featured, it would have worked. Um, and so it might take a little of the edge off that of, you know, just always rolling out an MVP kind of thing. So I don't know, just there's a little feeling there.

Speaker A: Well, actually that kind of strikes a nerve for me. Um, I've been listening to the audiobook of the book, um, Incorruptible. I don't know if you've heard of it. It's a great book.

Speaker B: Is it about Donald Trump?

Speaker A: No, it is not. It's by, um, uh, the author of the Lean Startup. And it's a book about basically Eric's new book.

Speaker B: Eric Reese's new book.

Speaker A: Eric's Reese's new book. And um, it's about how do you protect them? How do you become a mission driven company and how do you protect that mission? And what kind of. How do you, what kind of, what do you. What does that mean to do that? Um, but there's a really interesting. One of the things that he talks a lot about in the book is this notion that, um, to have something worth protecting, you need to have something worth protecting. Right. So you know, you have to, you obviously have to have a business worth protecting, you have to have a mission worth protecting. M. And um, he makes this point he's talking a little bit about, I think it was, I think he was doing an example of 3M. But one of the things he talks about is, and this kind of comes from the, he kind of mentions it a little bit in Lean Startup, but like, measuring things is a really important way to make sure you're on track. And so one of the examples he gives is if you're an innovation driven company, and I guess this was maybe 3m, um, that did this for a while. They had this as a thing where they're an innovation driven company. And so they had a measurement that was how much of this current year's revenue came from products that were invented or innovated in the last three years. And I think it was 3M, um, that he was describing. So they had this like, required metric that the board would regularly look at to be like, okay, how much of this current year's revenue is coming from new products, basically? And they were basically trying to look at the idea of like, how much are we innovating? Right. Because there's the, there's another version of it where it's like, oh, I just, like, I've got these great products, they're these cash cow products, they're like legacy products. And I, and I can just sell more of them or just, you know, goose the marketing on them and, and number go up. Right. Um, but if you're a, if you're an innovation driven company, then you want to find a way to measure like, are we innovating? Are we adding compelling innovations that the customers actually want? And so I thought that was really interesting.

Speaker B: It's really interesting. And I feel like it dovetails really nicely with what I was just saying in the sense of this. And it's great you brought up 3M, um, because many people know, but not everybody. I'll share for our audience the post it note, which might be, I don't know for sure, but might be the most valuable thing that 3M has ever invented.

Speaker A: Certainly it's one of the best stories they have.

Speaker B: Right. It was an accident. Right. And so if 3M had been depending on that engineer, uh, to produce something that was going to have an impact right away and had not given them the space to experiment and fail and say, well, you didn't do it this year, but come back again next year and try again, would the sticky note have ever been invented?

Speaker A: Right.

Speaker B: And so that's, and that's why I think this dynamic where companies are depending on the research and development department to produce in Year results creates like, like, like, creates like limits maximization, if that makes sense.

Speaker A: Well so then, so then let's, let's restate this in your. How would you make engineering go faster? So what if in, instead of how do we make engineering go faster, what if the mission is how do we get more innovation out of engineering?

Speaker B: Yeah, that's a great, great way of putting it.

Speaker A: Right. And innovation that adds value, right? Well, uh, for sure, I think there's a lot of evidence that giving space for true research, giving space for

Speaker B: um,

Speaker A: failure is a, uh, known way to have breakthroughs. Right. So another great example, right, like we all know about GLP1s, right? Well, GLP1s were like a uh, ton of research that was not at all obvious that there was any value that was going to come out of them went into that. And you know, I think it was Novo Nordisk that invented the first one. And had they. They have a strong culture of innovation, a strong culture of research and development, a strong, like they're their governance. They actually are a for profit company that's governed by a nonprofit board that makes sure their mission. And that nonprofit board is the one that like decides like what the for profit board is allowed to do. So when the for profit board, you know, like several years ago tried to say, oh, let's, let's merge with this other, you know, pharmaceutical company, the, the nonprofit board essentially was like nonprofit mission guarding and board basically was like why, how does that actually move our mission forward? Right. And yeah, and the um, CEO at the time of the for profit company basically failed to convince the, you know, the, you know, the oversight board to allow that merger. And guess what happened? The company that they were going to get merged with or wanted to get merged with was out of business three years later. Right? So it's like, that's a great example where like maybe uh, in another answer to your question of how do you get more innovation from engineering faster is make sure you really guard the ability for engineering to do true research and development.

Speaker B: Well, this is you now you. And this is maybe a whole other podcast. You're bringing up a really interesting question implicitly which is there are things that our business stakeholders want their innovation. We're seeing that all over with AI right now. But there's things they want that I would, that I don't think are innovation.

Speaker A: Tell me.

Speaker B: Uh, I'll give you an example. I'll give you two concrete examples from our world right now. This one's a little embarrassing to share actually. We have categories on TaskRabbit. Somehow TaskRabbit arrived in 2026 and it still requires an engineer to add a category.

Speaker A: Right.

Speaker B: Somehow the entire rest of the world figured out in 1998 how to create a GUI for people to do that. But TaskRabbit waited until now. So that's the embarrassing part. Uh, and we're fixing that. That's the project we're working on. That's Project A. And um, that is not innovation, in my opinion.

Speaker A: Right.

Speaker B: At all. Um, there has been some kind of resource collisions in terms of people working on that, with people bringing, um, convers conversational AI into our product to help, um, ah, client better describe the work they want. We ask clients to come in and describe what they want and they don't do a good job out of it, then the worker has got a poor description, just like us as engineers. And if the, if you go in there and say, I need some yard work, conversational AI can say, well, how big is your yard?

Speaker A: Right, right.

Speaker B: It could, it could help refine the description that you give to the Tasker. And so that's innovation, or at least closer to innovation that I would to some degree. Even that these days isn't that much innovation. I mean, it's a good thing technology isn't moving fast. So like, those are a little bit in opposition. Right. We have a commercial team saying, could you please just give me this basic feature? Like, yeah, yeah. The entire rest of the world had this 30 years ago and like, we don't have it. And then they got other teams saying, could you please give me this innovative feature to help us move ahead. And like, our competitors are building this thing, we got to build this thing. And so it's interesting. They're not always asking for innovation from us, I guess is an interesting thing.

Speaker A: Yeah, that's fair. Well, and again, I think that really scratches that question of like, know what you want, Know what you want.

Speaker B: Yeah, it really does.

Speaker A: Yeah.

Speaker B: Well, it's. And it scratches a different question, which is somewhere back in, I don't know, whenever TaskRabbit started 15, 18 years ago, someone created some tech debt. They said, you know what, let's just put this in a YAML file.

Speaker A: Yeah.

Speaker B: And here we are 15 years later, paying back that loan.

Speaker A: Yeah.

Speaker B: And you know what, at the time when they were trying to kick off this business, that might have been a great loan. That might have been. I could spend two weeks trying to build this thing or I can have this YAML file ready by the end of the day. And that was Probably a really good trade off.

Speaker A: You know what's super interesting? Okay, okay, now you got me, now you got me thinking about AI. Okay, you know what is, uh, I think it's super funny. I see this with my AI agents all the time where they will take trade off tech debt intentionally. They'll say out, you know, they'll say in their discussion, I got, I got these agents and they're doing code reviews of each other's code and one of them says, oh well, what about this? Like this is a little piece of tech debt. And they'll, they'll, the agent will say, the other agent will be like, oh yeah, that's a nit. Like I don't need to fix that. Going to be deferred, right? And it's so funny to me, I, I feel like I'm constantly saying to them, no, don't defer, like fix it now. Like I don't want, I don't want the tech debt, like fix it now. Right. It's so interesting to me that the way that these LLMs have been trained is they, they are trained across essentially the history of all the way that us humans have behaved. And so it's like you and I were joking the other day when, when you ask Cursor or Claude for an estimate, it comes back with like two weeks or something, you know, and it's like, that's so ridiculous because it's like going to take it, you know, 15 minutes to write the code. And so I do, I do think there's, so you've made me kind of remember that one of the things that we're evolving through right now is the fact that the language of engineering, the language of estimations, the language of the decisions around technical debt, the language uh, that we have around, do we make that investment now or do we live with it for now? Right?

Speaker B: Mhm.

Speaker A: All of that language was predicated on the writing of the code taking a lot of time. And now that the writing of the code takes a lot less time, a lot of those decisions and the language around those decisions I think are uh, outdated and the LLMs are programmed on the old, historic, outdated way of talking about decisions.

Speaker B: That's interesting, right? Yeah, that's really fascinating.

Speaker A: And so when you were talking about like, oh, you know, when the, you know, whatever 15 years ago when somebody decided categories should just be in a yacht YAML file, right? Like, yeah, you're right. Like at that time, 15 years ago, that was probably the right decision because like coding up some user interface was, was Definitely like a, uh, two week project that you didn't really need to do at that time, right? Yeah.

Speaker B: You're trying to get your company launched and you're just like, we'll deal with that later. We don't need to change a category right now. We'll deal with it later. They can call and put it within

Speaker A: a new category, but now you can write that UI right out of the gate and, or you can, you know, have the agent go fix that ui. Uh, you know, it's funny again, like, if we're gonna, if we're gonna go back to your original question, like, what would have to change for engineering to go faster? I, I, man, I, I don't, I hope I don't just sound like a broken record or, or some kind of a, you know, complainer, but man, I just feel like, know what you want built. Like, go really get your product, get, get your, get your backlog in order. What do you really want me to spend my time on? Because I can, I can write this stuff so much faster now.

Speaker B: Yeah, but it's still, I want it all. And there are still humans in the process. Right? We're not yet at infinite code. Infinitely fast. I know there are teams that are going very, very fast, but like, like we're still, I don't think we're yet at infinite code. Infinite code and really fast.

Speaker A: No, I agree with you, I 100 agree with you. And I'm saying, like, no matter what the system is, no matter how fast you're going, you still need to have a really good idea about what you really actually want and the order you want it in.

Speaker B: Yeah, to me, that's, that's like the,

Speaker A: that's like the main thing, you know, Like I'm working with this, I'm working with this client now and it's like they did some usability testing and got feedback on a prototype, uh, that they built. And it was a real eye opener of all the assumptions that they made. Like, no, it did not resonate with the customers. And I looked at it and I was like, this is great. We got some real signal here. This is so good. Now, okay, here's five ideas that people want to try to do to address the signal that we got. Great. Didn't we learn? Let's not, let's not polish this. Let's, let's get the five possible answers real quick and let's try to get signal on those things. Right?

Speaker B: Yeah. I may be a masochist, but like one of the things that brings me the Most joy in my job is when an A B test fails or

Speaker A: what does that mean for the A B test fails?

Speaker B: Like, does that run any A B test? We've got, we've got the way it is currently on the system and we, we run it comparable, we run a new version against it to see everyone thinks the new version is going to

Speaker A: be better and when the new version is worse. That's when you, that's what you meant by.

Speaker B: That's when you learn. Yeah, that's when you learn something. That's when you learn something. When your previously held assumptions get overrun by a herd of facts. Right. And I, I find that as a person who I enjoy learning, I always find that really interesting. I'm like, well, look at that. I didn't, I didn't know something and I just learned something today. I think that's pretty cool.

Speaker A: Wasn't that one of the stories that Kevin told us about Spotify or something like that, how they had, had developed this real strong culture of like, test before you deploy. Uh, and then on one big project, like, they didn't do that and it was just like they couldn't. And then you, and then, and then you're. And then you, like, you have to test the parts. Right. Like, again, I was just talking to this, this client where I'm like, they had six ideas of things they wanted and I was like, we need to tease those things out because if we, if we try to test all six of those things at the same time, you're, you're going to conflate the signal and you're not going to know whether or not it was, you know, was. Which of those things was the good thing.

Speaker B: Right. Just like the avalanche or worse, like

Speaker A: if, if it fails, like if you, if you roll, um, out the prototype with all five features or six features and it's a dud now, like, does that mean you're lucky?

Speaker B: Here's something that I think could help engineering go faster. I don't know if this is possible, if all of us actually, including the engineers, had a longer, like, mental time horizon about what we're doing. Yes, it's not this quarter, it's not even this year. If we're trying to build these businesses to be real enduring businesses. TaskRabbit's been around 15 or so years and we're doing a big investment right now to, um, modernize the platform, refactor, a lot of parts of it. And, you know, there's a lot of impatience about that. But I try to remind people hey, the platform we're working on that we're frustrated with now because it's become brittle. Served this company for 15 years.

Speaker A: Yeah.

Speaker B: The thing we're building needs to serve us for the next 15 years. Or not maybe doesn't even need to service is going to serve this company for the next 15 years. And so if it takes a month or two longer to get us the right thing that will serve this company for 15 years. That's the right decision. But so many companies in America are just very monthly, sprintly monthly, quarterly, yearly oriented. Right. And there's very, very few companies that think in decades.

Speaker A: I don't know if it's still in the code base. Um, but like 10 years ago, a colleague of mine who worked at Microsoft said, hey Brad, I found some code you wrote. And I was like, okay, that's hilarious. Because one, I never worked for Microsoft. And they were like, yeah, yeah, it was like some copy paste. It's like some undo buffer inside of some code that's like. And it was. And where this code came from was. It was code I wrote at asymmetrics in 1993 and then was a part of a project that got spun out and bought by Vizio and Vizio eventually got acquired by Microsoft. And somehow like some code that I wrote lasted at least 25 years in a code base.

Speaker B: That's kind of cool.

Speaker A: I never worked for the company of. Right. And so yeah, I agree with your point that like. And by the way, the book Incorruptible, uh, everybody check it out. Uh, Eric Reese's latest book, like, it talks a lot about that. This idea of like, you know, m. Companies that really have a mission to live, to really make a positive impact on the world, then those are companies that want, want to live for centuries.

Speaker B: Mhm. You know, that reminds me of another book recommendation I'll make on this podcast here called the Living Company. I think the author was Ari de Goose, like a Dutch name. And it was a study of companies that had been in business for 200 years or longer.

Speaker A: Oh, wow, that's cool.

Speaker B: So this guy had observed that the lifespan of companies was getting shorter and shorter and shorter. And so he wanted to understand what was it about these companies that have endured for so long. Because if you're Mitsubishi and you've been around for 200 years, what you were doing 200 years ago and what you're doing now, making automobiles and microwaves and stuff like that. Totally different, right?

Speaker A: Yeah.

Speaker B: So something about your culture and your DNA is not about the product or service that you're offering. It's about something else. And fundamentally, if I, my recollection of the book and it's a short read, I bet it's not even 200 pages. Um, was that fundamentally these companies take their foot off the gas pedal of profits just a little bit. Like in my mind's eyes, like, like they're willing to earn 10% less in order. And 10% wasn't a number that the author said. That's just my kind of like recollection. They're willing to earn a little bit less in order to, and spend that money on thinking and optimizing for the long run. And that's the DNA of their company is we're not here to maximize profits for today. We are here to ensure that this company perseveres. We're just stewards of this company. Our job is just to keep it going, not to necessarily maximize today's profit. And that's a very un American thing, an American way of thinking.

Speaker A: It's a, it's, it's rare in, in today's sort of like view of capitalism as it exists today, but it's not unique. Like Costco. Great example of a company that has very, very focused vision around their, their part. Their customers are their primary stakeholder. Right?

Speaker B: Yeah.

Speaker A: Providing to their customers is their prime and their second stakeholders, their employees. And third stakeholders are the, are the shareholders like, and they're adamant that it's in that order. And that's the priority, which is why they still sell the $50 hot dog soda combo. And when they first introduced that a big Mac cost $1.63 and their hot dog soda combo was a dollar fifty, they have kept the price at a dollar.

Speaker B: Right.

Speaker A: Um, and it includes that they've solved the problem of they actually make their own hot dogs. Right. They've sol, you know, making, continuing to make that and they will never. And it's like a, you know, apparently there's apocryphal story of like the CFO of Costco trying to convince, um, uh, the CEO to like let him raise the price. And he's just like, over my dead body. You will not do that. Because that is like, it's a commitment to the, the customer that this is our truthful, this is the truth. We are giving you the. We, you are our priority. And we will. And so, yeah, there's a handful of companies out there that really focus on that kind of mission driven approach. Anyway, this is, this has been a long, windy road to get to Costco. And hot dog.

Speaker B: Well, that's a great place to leave off. Uh, maybe I'll go to Costco and get a hot dog tonight. I don't know if you know this, but I recently was applied and was approved and selected to be a member of Costco.

Speaker A: Are you an exclusive member?

Speaker B: Well, are you executive member? I'm a gold star member. So you're a gold star member to do executive yet?

Speaker A: Oh, wow.

Speaker B: Somehow. But I was applying for my membership and the woman asked me, she said, so, how long have you lived here? I said, actually, I've lived in Seattle my entire life. And she said, wow, I'm impressed that you've lived here for so long. It's a little bit of a comment on my age, but she said, I'm impressed that you've lived here for so long and you've never been a member of Costco.

Speaker A: There you go. Welcome to the club. It's a great club.

Speaker B: Yeah, I mean, I'm in now. I got a card carrying member.

Speaker A: Card carrying member. All right there. That's how we're going to end it, Scott. Finally, a card carrying member of Costco.

Speaker B: Is that the title of this episode?

Speaker A: Card carrying member of Costco.

Speaker B: Brad, this has been really fun.

Speaker A: Wild ride, Scott.

Speaker B: What do we need folks to do?

Speaker A: Smash. Smash that subscribe button, rate and review.

Speaker B: We really appreciate it, gang, and we look forward to seeing you next week.

Speaker A: All right, see you next week, Scott. This episode of The how many CTOs does it take? Podcast was produced and edited by Saffron Heftikao. Our theme song was AI Generated by Brad. Please follow us on all the social media platforms at howmanyctospod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok and Patreon or at our website at, uh, howmanyctospod.com and remember to rate, review and subscribe on the podcast platform of your choice. Thanks for listening.