The Pace of Innovation: Systems Thinking for Faster Engineering

0:00 Brad: Maybe 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.

0:32 Welcome, everybody,

0:33 to another episode of the How Many CTOs Does It Take podcast?

0:36 My name is Brad Hefta-Gaub and my trusty co-host is...

0:39 Scott: Scott Gorad.

0:40 Brad,

0:41 how are you doing today?

0:41 Brad: I'm doing pretty good.

0:43 I'm doing good.

0:44 Scott: Were you just in Hawaii?

0:47 Brad: uh that was like a month ago but yes i

0:49 Scott: Then you were just in the mountains.

0:52 Brad: was just in the mountains man

0:53 Scott: What's happening up in the mountains?

0:55 Brad: it was it was i got only got one of six peaks done it was it was quite an adventure there was some sketchy shit and uh we made safe decisions and came home

1:05 Scott: That's good.

1:07 That's the safe decisions is the victory.

1:09 Brad: but it was a lot of fun we we uh we are in this zone called the chillowax it's incredible

1:14 incredibly beautiful zone really rugged really beautiful though and we we um were camping under a glacier that we were watching like cav 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 uh

1:36 Scott: That's awesome.

1:37 Brad: what were you doing while i was away in the mountains

1:40 Scott: I was having so much fun.

1:42 Brad: Tell me.

1:43 Scott: This will date our episode.

1:45 This will probably come out in early to mid-August.

1:47 Brad: Oh, yes.

1:48 Scott: I went to two baseball games two nights in a row.

1:53 and then i went to a world cup game in

1:56 Brad: Wow.

1:56 Scott: 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 just doing fun stuff oh

2:12 Brad: Awesome.

2:13 Love it.

2:13 Scott: i know i i know i concluded that week with a big long bike ride

2:19 And, you know, I said to myself,

2:22 if every week was like this,

2:23 my head would probably split.

2:25 It could just be too much fun.

2:27 Brad: Too

2:27 Scott: I'm not used to

2:27 Brad: much having fun.

2:28 Scott: that much fun.

2:29 Brad: Too much winning.

2:30 Love it. Well,

2:31 the World Cup certainly was an exciting time.

2:33 I think.

2:35 You didn't even have to necessarily be a soccer football fan to just get the excitement coming off of all that stuff.

2:42 Scott: That's right.

2:43 This isn't a soccer podcast,

2:44 but I think I finally figured out what constitutes a foul in soccer.

2:50 Brad: Oh, no.

2:52 I don't think I understand that.

2:54 Scott: I haven't understood it. I've been following.

2:56 I'm not a.

2:57 I'm not a lifelong soccer fan.

2:59 I started following soccer about five or six or seven years ago,

3:02 and I've always been puzzled as to what constitutes a foul.

3:06 I think as a result of watching so much soccer over the World Cup,

3:09 I think I finally figured it out, and I think it goes like this.

3:12 If you kick the guy before the ball,

3:15 that's a foul.

3:16 Brad: But if you are kicking the ball,

3:18 Scott: If

3:18 Brad: but

3:19 Scott: you kick

3:19 Brad: you hit

3:19 Scott: the ball the first,

3:19 Brad: guy.

3:20 Scott: then you're fine.

3:22 That's the first rule.

3:23 The second rule is if you kick the guy or shove the guy, you can't shove or kick from behind.

3:29 No from behind.

3:31 Anything from behind, that's a foul.

3:34 Otherwise,

3:35 do whatever you want.

3:36 Oh, I'm sorry.

3:38 Number three,

3:38 you can't touch it with your hand unless

3:40 Brad: you can't touch the ball with your hand unless you're the goalie

3:43 Scott: you're the goalie. Otherwise,

3:44 do whatever you want.

3:47 Brad: Love it.

3:48 Scott: There I

3:48 Brad: you go.

3:48 Scott: think that's it. As near as I can tell, that's it.

3:50 Brad: There you go.

3:51 Yeah.

3:52 Cool.

3:53 Well,

3:53 what you texted me right before we started this call and you said,

3:57 Brad,

3:58 I got a topic for you.

3:59 We got to get on the call and we got to talk about a topic.

4:02 Scott: Oh,

4:02 I took a two hour at the beginning. I took we're starting a course course. I don't know if you call it a training situation at our workplace led by an external facility.

4:14 facilitator about change management and

4:17 Brad: Oh boy.

4:17 Scott: 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 you

4:39 that and then she said you know then there's a level up there we try to change technological not technical the first is technological the second level it's like then we try to change like psychological aspects like 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

5:06 Brad: Okay.

5:06 Scott: And we know about systems and engineering because we deal with systems all the time. And she described a system as, I can't remember exactly words,

5:16 but it was basically two or more entities with a boundary.

5:20 So imagine you're in an elevator,

5:24 it's just yourself.

5:25 So it's you,

5:26 that's one entity and there's a boundary,

5:29 the elevator.

5:30 And then I enter the elevator.

5:33 And now there's two people and together we are a system and there are a set of norms and rules.

5:40 There's a way that system works. For instance,

5:42 we have norms both spoken and unspoken about how that elevator works and how we interact in that elevator.

5:49 This was the analogy she used.

5:51 Brad: I'm just cracking up over all the weird things you can do in an elevator,

5:56 you know, like,

5:56 for example, if you get in the elevator and you face.

5:59 Face backwards,

6:00 most people in the Western world are going to think you're a weirdo.

6:04 Scott: Right. That is not how that system works.

6:07 Brad: Right.

6:08 Scott: And so one of the things she was talking about is if you're trying to change an organization,

6:13 first she was saying, if you're really trying to change an organization, you have to change the systems.

6:18 And one aspect that she was talking about was.

6:22 If you want to change systems,

6:23 you really have to get to the unspoken norms,

6:27 the rules that everyone knows, but nobody has written down,

6:33 that

6:33 Brad: Okay.

6:33 Scott: there's no user manual. No one ever gave me a user manual for how to go to an elevator.

6:38 Right.

6:38 Brad: Right.

6:39 Yeah,

6:39 but you figured it out quickly.

6:41 Scott: 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,

6:48 right?

6:48 At some point you turn backwards and everyone's like, that's weird.

6:50 Or you see somebody else turning backwards and your buddy says,

6:53 that's weird that dude was standing there. You learn,

6:55 right?

6:56 Okay, so that was one aspect. But the aspect that I thought was interesting for this conversation,

7:01 we have a culture.

7:04 of 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 that 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

7:32 And getting yourself to change is relatively much easier.

7:35 And so if you want to change the system,

7:37 actually first start by thinking about how am I operating within this system?

7:42 And what can I change to start to get the dynamics of this system to work differently such

7:46 Brad: Yeah, totally.

7:47 Scott: that it'll get the better outcome?

7:51 Okay,

7:51 so that led me to another thought.

7:53 And this is the one I want to talk to you about.

7:55 Almost everywhere I've worked.

7:58 People want the system to produce engineering output faster.

8:03 Brad: This is like episode number two of the podcast.

8:09 Scott: And so I thought to myself,

8:12 and this is going to be a very, very meta question.

8:15 If we were going to change the system, well,

8:18 and I'm sorry,

8:19 I need to point something out. And typically the way people say to get stuff faster is to say engineering, we need to do stuff faster.

8:28 Brad: Right.

8:29 Scott: And then engineering says,

8:30 okay,

8:30 well, we need to change processes or we need to change ways we do stuff.

8:35 We need to change our technology,

8:36 so on and so forth.

8:38 But I thought to myself,

8:40 okay,

8:40 if we wanted engineering to produce stuff faster,

8:44 if the company,

8:45 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.

8:53 Brad: Yeah.

8:55 Scott: what would it be what would change now i get this is a little meta because i'm gonna be 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 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

9:19 What should, you know, finance,

9:21 HR,

9:21 marketing,

9:22 product management, commercial operations,

9:24 biz dev,

9:24 customer service,

9:25 legal,

9:26 etc.

9:26 What would those groups change and do differently to get us, the engineers, to be able to get stuff done faster?

9:34 Brad: Man, that's a great, I love it. That's a great meta question.

9:38 Do you have answers to this or do you, you just like,

9:42 Scott: I have some snarky answers.

9:43 Brad: okay.

9:45 I mean, that's, that's at least somewhere to start.

9:48 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.

9:56 I mean,

9:57 in the zeitgeist, especially in the world of AI coding,

10:01 right,

10:01 in the zeitgeist, there's this real this real question of like, if you make all of the code writing instantaneous,

10:10 what else in the system breaks?

10:13 And that's sort of where my mind is going to answer your question.

10:18 Scott: How many minutes into the story before you got to AI?

10:22 Brad: 10.

10:22 Scott: Because I could play the other way around, which is right now companies want engineering to go faster.

10:27 So they say they're telling us to change and use more AI.

10:30 Brad: Right.

10:31 But that's what I'm saying is, OK,

10:32 yes.

10:33 So agreed.

10:33 So that's so I love your thought experiment of saying like,

10:36 well,

10:37 what has to change other than engineering in

10:40 Scott: Yes.

10:40 Brad: order to make engineering be able to go faster?

10:42 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.

10:50 If all of a sudden the engineering building stuff was instantaneous,

10:54 there's

10:54 Scott: yeah yeah right

10:56 Brad: two places that would collapse immediately or would become apparent immediately as the problems.

11:02 Scott: because the instantaneous means you can't ask it to go faster right because it's as fast as possible it's the speed of light

11:08 Brad: It's the speed of light,

11:09 right?

11:09 And so the first place that you'd have a problem is deciding what you want to build.

11:15 Scott: Yeah, agreed.

11:16 Brad: Right. Like, like, like,

11:17 I mean, you and I, when we were at health tech company,

11:20 right, like they had they put a ton of time and energy in their SDLC around the whole deciding what to build.

11:29 And there was this all this process of like these these there was a little bit of like,

11:35 you know.

11:36 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

11:58 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 if i sort of flip the script there one might say like well if you want engineering to go faster make sure you have a like basically make your shovel ready plans come faster

12:16 Scott: Yeah.

12:17 Brad: Right?

12:17 Like, how quickly could you produce your shovel-ready plans?

12:20 Scott: Yes. Or you can push that further.

12:22 Come with shovel-ready plans.

12:23 Brad: Come with shovel-ready plans.

12:24 Scott: Don't come with a line in a spreadsheet that says make a flux capacitor.

12:28 Brad: Right?

12:29 Come with shovel-ready plans.

12:31 Right.

12:31 Scott: Now, your hypothetical here about instantaneous code brings up something,

12:35 there's an implicit,

12:36 potentially something implicit in that hypothetical, which is, is the ability to create code.

12:43 So in that hypothetical constrained.

12:46 Because there's actually two parts to the going faster.

12:49 One part is how fast can the team get a given piece of engineering done?

12:54 And the other part is what is the overall capacity of the team to get things done?

12:59 And so in this example,

13:02 is there unlimited capacity?

13:04 Because I think that I think one of the things that might change outside of engineering has to do with the capacity and utilization.

13:12 You know, there's all sorts of research.

13:13 research that 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 percent in order to maximize your

13:23 Brad: Sure.

13:24 Scott: output right but in our industry we we really

13:29 try to maximize the utilization of it we don't want our engineers sitting around but that's the worst thing possible to have an engineer sitting

13:35 Brad: Right.

13:36 Scott: around with nothing to do which i've never ever seen in my life by the way um i think there's a piece there about something that could happen outside of engineering is thinking i'm not exactly sure what but something about

13:52 Maybe it's just the expectations or the standards for what capacity or I'm sorry, what utilization the organization wants to use of its engineering resources.

14:03 And if it were committed,

14:04 it was really disciplined about being in a more optimal zone,

14:08 it might get more output.

14:10 Brad: Sure. But to me, that just sounds like another way of saying make sure you know what you want.

14:16 Scott: Mm

14:16 Brad: like

14:16 Scott: hmm.

14:17 Brad: be good

14:17 Scott: Yeah.

14:17 Brad: at knowing what you really want exactly

14:19 Scott: Yeah.

14:19 It's a different layer.

14:20 You're talking about knowing what you want for a given thing, have it show already.

14:24 And then there's like also have your queue of things ready,

14:26 have them in order and ready to go.

14:28 Brad: 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

14:43 The the primary users of the software platform,

14:46 the medical team,

14:47 they kind of were like,

14:48 hey,

14:49 stop giving us features like you can't give us features to if you give us features too fast,

14:55 we have to get trained on them. Right.

14:57 Scott: Mm

14:57 Brad: So so,

14:58 Scott: -hmm.

14:58 Brad: you know, depending on how mission critical or how how critical the thing that the people are doing with your software like.

15:06 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,

15:16 right?

15:16 Like whatever releasing looks like, right?

15:18 Like if releasing looks like customers install it and customers use it and customers configure it, well, how good are you at that?

15:28 Scott: And

15:28 Brad: I mean, how good are you at taking the finished product and getting it in the hands of the real customers?

15:36 Like that's another huge bottleneck I've seen in my career.

15:39 Scott: yeah and attention to the related one like you've talked about installing software also like the integration with other parties right

15:48 Brad: Yeah.

15:48 Scott: that's often a big piece like hey we've got our api done and now there's a whole

15:53 integration testing cycle thing and

15:56 Brad: Yeah, totally.

15:57 Scott: now 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

16:05 ways for these people to mock their stuff up or whatever and yeah

16:08 Brad: 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 um 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

16:32 software is a piece of a sequential system,

16:35 then

16:36 Scott: Mm-hmm.

16:36 Brad: the things on both ends of that, to make the software go faster,

16:41 the things on both ends of that also need to go faster and be ready.

16:47 and be prepared and what's interesting is there's this really nice you know this there's this there's this thing that like i remember i've been frustrated in the past by product owners that didn't necessarily always sort of thought of themselves as like i invent things from whole cloth 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're

17:12 You know what your customers want,

17:14 right?

17:14 Scott: Mm-hmm.

17:16 Brad: So that's another thing that I feel like, what other things do I need to make true to make software go faster,

17:21 to make engineering build stuff faster,

17:23 is I need to really know what my customers want.

17:26 Scott: Mm-hmm.

17:28 Brad: So what were your snarky answers to this question?

17:30 Scott: Oh, you know, just like leave us alone.

17:37 Brad: Okay,

17:37 Scott: That's

17:37 Brad: that's fair.

17:37 Scott: pretty good.

17:38 that just nonsense like that no

17:41 Brad: By the way, I'm super curious.

17:43 Are your other leaders, as soon as this conversation around systems change and systems changing came up, the first thing that they wanted to figure out how to do to change is make engineering go faster?

17:56 Scott: no that was not at all part of our conversation this was this was you know actually this was my thought which was like oh well I know where all this systems thinking is

18:05 going

18:05 it's 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 I don't know if this isn't Stockholm syndrome that's the right way of phrasing but am I stuck in a pattern of not having believing in good intentions of other 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

18:31 The book's faster and the marketing person wasn't thinking about how they could get their creative done faster or not even shouldn't even say faster that I'm just, again,

18:40 I'm stuck in my world.

18:41 The accounting person might have said, how can I get.

18:46 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

18:54 Brad: Yeah.

18:54 Scott: more 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

19:12 faster that that's where my mind went to and it just and then I just sort of thought like okay if all these people want us to go faster how are they going to change

19:20 Brad: Yeah,

19:20 Scott: And

19:21 Brad: exactly.

19:21 Scott: so, and to that point, I even had a hard time imagining,

19:26 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.

19:34 Brad: You know what I think is interesting?

19:35 Here, let me zoom the camera out a little bit more.

19:39 One of the things I've been thinking about recently,

19:41 and it's funny because maybe my LinkedIn feed has somehow been.

19:47 I've been filled with like PE CTO recruiters or something like that. Right.

19:53 Scott: Mm

19:53 Brad: So so

19:54 Scott: -hmm.

19:54 Brad: this question of like like as a CTO, right,

19:58 like there's so many.

19:59 times that CTOs are like confronted with challenges of like you know maybe they're maybe they're working through like instability problems or maybe they're working through performance related problems like around the team being able to move quickly and maybe there's like years of backlog of features that that people you know wish were implemented and I think that like

20:24 The harder problem is, are we building the right stuff?

20:29 Like, is the stuff we're building actually going to move the needle of the business?

20:34 Scott: Yeah.

20:34 Brad: To me, like, that's where the really,

20:38 you know, that's the juicy questions that are out there.

20:42 And I think that, like, one of the things that I think is so important about,

20:46 you know.

20:47 being a CTO as opposed to being the you know VP of engineering or something is like being able to really be a business business technical thought partner right and

20:59 Scott: Mm-hmm.

21:00 Brad: helping like understand like so what if we built this stuff faster if we're just building stuff that's not actually going to move the needle of the business then that's not doing anybody any good either

21:14 Scott: Yeah,

21:15 I was really proud of our product management team.

21:17 They've started a practice of going back.

21:20 It's a two-quarter lag because when something goes into production, they need some time to get some data.

21:25 But of really comparing.

21:27 what did we predict this investment was going to do

21:30 Brad: Oh, and cool.

21:31 Scott: what's and what's the actual outcome been and I've seen that in 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

21:42 that's the name of the game like they're not going to get it right i understand that in

21:45 Brad: Sure.

21:46 Scott: this business if you get it right a third of the time you're a hall of famer it's like baseball 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 you

22:09 looking at and then the most important going back and looking at it's only the first step in fact it's not even meaningful 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

22:35 We made a change to how we pre-authorized credit cards up front.

22:41 um minimize fraud and

22:45 Brad: Sure.

22:45 Scott: instead of just doing a like an ordinary credit card pre-off 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 the 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

23:06 But there was a lot of fear about this is going to impact like

23:10 Brad: Yeah.

23:11 Scott: our 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.

23:17 I don't think I'm pretty sure if I recall,

23:20 the fear was overweighted.

23:23 And the benefit to minimizing fraud,

23:25 basically fraudsters using fake credit cards and stuff like that, was even greater than projected.

23:30 So, you know, as we have the conversation and I say a minute ago,

23:34 you know, you'd get a third of them right, you're a Hall of Famer. Here's a case where we learned,

23:37 oh, actually, we don't have to, you know, we're too fearful of some of this stuff, right?

23:42 Brad: Yeah.

23:42 Scott: And the upsides of managing fraud is even, there's even more fraud than we thought going on on the platform.

23:47 And so there's not, I need to clarify.

23:49 especially for the lawyers out there Ben there's not that much pride going on the platform and we're doing a great job preventing it and so but uh but

23:57 Brad: But the

23:58 Scott: the point point

23:58 Brad: is

23:58 Scott: is

23:58 Brad: this,

23:58 the point is that this change.

24:01 The team was there.

24:03 I mean,

24:03 I've been in these meetings,

24:04 right,

24:04 where someone goes,

24:05 hey,

24:05 if we make a change to credit card processing,

24:08 a small change there can have radical impact on numbers.

24:12 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,

24:19 you know, and.

24:21 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 and because we are afraid it's going to like

24:35 cause problems.

24:36 And it's, is this really that big a deal?

24:39 And then next thing you know, you've implemented and it turns out you go back and you measure it and you go, wow,

24:44 not only did we not get the breakage, not only did people not, you know, cancel orders,

24:48 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.

24:58 Scott: That's right.

24:58 That's right.

24:59 I think so often we're attuned what I would refer to looking for, you know, we're so attuned to trying to avoid,

25:07 you know, look for our mistakes.

25:10 avoid making your 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

25:31 And

25:31 Brad: Yeah,

25:31 Scott: so,

25:32 Brad: and I think that – yeah,

25:33 100%. I'm a big believer in that,

25:35 that like a lot of times when things go right,

25:38 people say,

25:39 oh,

25:40 that went great.

25:40 We don't need to talk about it.

25:42 Scott: yeah,

25:43 yeah.

25:43 Brad: And the reality is I believe that when things go right,

25:47 that's the best time to pause and really interrogate. Like what did we do differently here or what did we – what is it in our system?

25:56 um that contributed to this success that we had oh

26:00 Scott: Yeah, that's right.

26:01 We were probably talking and now that I think about it, I think you're bringing that up in the context of avalanche awareness and

26:07 Brad: yeah

26:07 Scott: you

26:07 Brad: we do that all the time in avalanche

26:08 Scott: do

26:08 Brad: awareness all because

26:09 Scott: the time, right?

26:09 Brad: we're like trying because like every time you every time you don't have an accident right you're asking yourself was i lucky or did i make good decisions

26:20 Scott: Yeah, that's right.

26:21 Okay,

26:21 so actually we have stumbled into,

26:23 I think, a huge thing that every team, including engineering,

26:27 but also all the teams outside of engineering can also do,

26:29 which is build really good learning feedback loops.

26:33 Brad: Yeah.

26:34 Scott: Right.

26:35 And we have those feedback loops in engineering,

26:38 as you know. In fact, I'm giving an all hands presentation on Monday about one of them. They're Tuesday.

26:43 Not that that's relevant to our podcast listeners, but about our incident response process and our postmortem process and how all that works and how, you know.

26:54 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 if you think about our entire industry

27:16 I started building online services, we called them websites back then,

27:21 30 plus years ago.

27:24 Brad: Yep.

27:24 Scott: And the stability of online services today,

27:29 knock wood,

27:30 is incomparable to what it was 30 years ago.

27:37 right 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 we made mistakes we learned from we kept them building layers upon layers upon 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

27:59 up and running.

28:00 Can I detour for a second

28:02 Brad: Yeah.

28:02 Scott: on systems that are vital to every aspect of our lives?

28:05 Brad: Okay.

28:05 Scott: This is a total ADD side quest we're going to go on.

28:11 TaskRabbit operates in Europe, and apparently the country of Spain,

28:15 have you heard of Spain?

28:16 Brad: I have heard of it. It's a country.

28:17 Scott: You ever been there?

28:19 Brad: I have.

28:20 Yeah.

28:20 Scott: What do you think of it?

28:22 Brad: I love that we went to, we saw a lot of beautiful architecture.

28:25 We saw a lot of beautiful art.

28:27 We ate some beautiful, some delicious food,

28:30 drank some delicious drinks. It was great.

28:31 Scott: You did all the things you do in Europe. It's great. Well,

28:34 apparently they have passed a law,

28:35 which if you operate a business in the country of Spain,

28:38 you must accept customer service inquiries by mail.

28:44 And you must respond within 15 days in their approved languages, which I think are three different languages in Spain.

28:54 And so a company like TaskRabbit now,

28:57 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 translated 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.

29:13 Brad: Love it.

29:15 Scott: So the entire world is not online yet.

29:19 Brad: it's just like that's just like awesome that sounds like a service somebody there you go there's a business for you

29:25 Scott: It's funny you said that was literally just this week I was talking to someone at our company about having to do this.

29:31 Engineering doesn't have to do anything for this. It was just they were talking about how they had to deal with this.

29:35 And I was like,

29:36 that's exactly what I thought.

29:38 I was like, oh, that's an interesting little business.

29:40 Brad: Right.

29:41 Just have a bunch of mailboxes.

29:43 I mean, that is the business,

29:45 right?

29:45 There is people that do that business,

29:47 you know, in the US,

29:47 you know.

29:49 uh registry registered agents for llcs you know my my llcs

29:53 Scott: Yeah.

29:53 Brad: got a registered agent there's a mailbox there um and when any paper mail comes to me i get a email with a with a you know scanned copy of it

30:02 Scott: Okay.

30:03 So where did we, I don't know how we ended up here.

30:04 Brad: we ended up there yeah oh you were saying all the systems the systems that just are working in the systems are in the working in the background are you were you going to talk about the postal service

30:14 Scott: I was just going to say sometimes we go driving down the road and we end up at the

30:16 You end up in a cul-de-sac.

30:17 Brad: Yeah

30:20 or around in circles in the cul-de-sac.

30:22 Scott: Now, 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?

30:31 You said one,

30:33 have things shovel ready.

30:36 You said two,

30:37 be clear about the things that you want to have done.

30:39 I don't remember if there was a third thing you added. I threw in there, have learning feedback.

30:45 back loops somehow we got in talking about whether things worked or not so that sort of led to

30:52 Having clear learning feedback loops all over the company,

30:55 I think is another puzzle piece that I might add to it.

31:00 Here's what I would add,

31:01 which might ruffle the feathers of every single person not in engineering in the entire world.

31:07 Brad: Okay, I want to hear it.

31:08 Scott: In the companies I've worked at,

31:10 it mostly the finances go something like this.

31:15 Hey,

31:15 we made $100 this year, and next year we want to make $120.

31:20 So we think just by doing more marketing like we did this year,

31:25 that that'll get us $10.

31:27 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.

31:33 Brad: Yep

31:34 Scott: And then, you know, there's product managers that facilitate that process.

31:39 of deciding 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 this et cetera et cetera 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 going to only get one in three of them right

32:06 And in my experience, roughly speaking,

32:09 a third of things succeed,

32:11 a third of things actually make stuff worse, and a third in the middle just kind of don't have any impact at all.

32:17 And so we come up with $30 worth of ideas, and then we try and do them all, and hopefully some of those are winners out of that process and we get our $10.

32:28 And I've been fortunate in my career that typically that's work.

32:32 Engineering is largely an R&D exercise,

32:35 research and development exercise.

32:37 Brad: Yep.

32:37 Scott: And so...

32:39 Probably if we wanted to get more out of engineering and have engineering get sipped and faster.

32:44 I have this hypothesis,

32:46 I can't tell you exactly the mechanics,

32:48 but if we didn't have that $10 on engineering,

32:51 if the company said,

32:52 well,

32:53 we have $100 this year and next year we think we can get $10 more 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?

33:05 And there's something,

33:08 I can't explain it,

33:09 but qualitatively it just feels like it would lead to a dynamic that would result in a combination of,

33:18 I think people would take bigger bets,

33:21 but

33:21 Brad: Yeah.

33:22 Scott: simultaneously I also think people would be.

33:25 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

33:32 Brad: Yeah,

33:33 Scott: me would be

33:33 Brad: right.

33:33 Scott: 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 for full featured it would have worked

33:53 And so it might take a little of the edge off that of, you know, just always rolling out an MVP kind of thing.

33:59 So I don't know, just there's a little feeling there.

34:01 Brad: Well, actually,

34:01 that kind of strikes a nerve for me.

34:04 I've been listening to the audio book of the book Incorruptible. I don't know if you've heard of it.

34:10 Scott: Heard of it.

34:11 Brad: It's a great book.

34:12 Scott: Is it about Donald Trump?

34:13 Brad: No,

34:13 it is not. It's by.

34:17 the author of the lean startup and it's a book about

34:21 Scott: Oh,

34:21 Brad: basically

34:21 Scott: that's

34:22 Brad: eric's

34:22 Scott: Eric's new book, Eric Ries' new book.

34:24 Brad: eric's reese's new book it's 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

34:43 Right.

34:44 Scott: Mm

34:44 Brad: So,

34:44 Scott: -hmm.

34:44 Brad: you know, you have to you obviously have to have a business worth protecting.

34:47 You have to have a mission worth protecting.

34:50 And he makes this point. He's talking a little bit about I think it was I think he was doing an example of 3M.

34:57 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 in.

35:10 You're an innovation driven company, and I guess this was maybe 3M that did this for a while. They had this as a thing where they are an innovation driven company. And so they had a measurement that was how much of.

35:21 This current year's revenue came from products that were invented or innovated in the last three years.

35:32 Scott: Mm

35:32 Brad: And

35:32 Scott: -hmm.

35:32 Brad: I think it was 3M that he was describing.

35:34 So they had this like required metric that the board would regularly look at to be like,

35:40 OK,

35:41 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.

35:48 like how much are we innovating right because there's the there's another version of it's 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 number go up right 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

36:13 Are we adding compelling innovations that the customers actually want?

36:18 And so I thought that was a really interesting thing.

36:20 Scott: 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 because many people know but not everybody all there for our audience,

36:32 the post-it note,

36:33 which might be.

36:35 I don't know for sure, but might be the most valuable thing that 3M has ever invented.

36:39 Brad: Certainly it's one of the best stories they have.

36:41 Scott: Right.

36:42 It was an accident. Right.

36:44 And so if 3M had been depending on that engineer 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,

36:58 well,

36:58 you didn't do it this year, but come back again next year and try again.

37:01 Would the sticky note have ever been invented?

37:04 Brad: Right.

37:05 Scott: 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 your results.

37:16 creates like limits maximization, if that makes sense.

37:21 Brad: Well,

37:22 so then let's restate this in your how would you make engineering go faster?

37:27 So what if instead of how do we make engineering go faster,

37:29 what if the mission is how do we get more innovation out of engineering?

37:34 Scott: Yeah, that's a great, great way of putting it.

37:36 Brad: Right?

37:37 And innovation that adds value,

37:39 right?

37:39 Well,

37:40 for sure, I think there's a lot of evidence that giving space for true research, giving space for failure.

37:53 is a known way to have breakthroughs right so another great example right like we all know about glp ones right well glp ones were like a 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

38:19 had they they have a strong culture of innovation a strong culture of research and development a strong like they're they're governance they actually are a for-profit company that's governed by a non-profit board that makes sure their mission and that non-profit 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

38:44 Let's merge with this other pharmaceutical company.

38:48 The nonprofit board essentially was like nonprofit mission guarding and board basically was like, why?

38:55 How does that actually move our mission forward,

38:59 right?

38:59 Scott: Mm-hmm.

39:00 Brad: And the CEO at the time of the for-profit company basically failed to convince the –

39:11 You know, the oversight board to allow that merger.

39:14 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.

39:20 Right. So it's like that's a great example where like maybe in another answer to your question of how do you get more innovation from engineering faster is.

39:34 Make sure you really guard the ability for engineering to do true research and development.

39:41 Scott: Well, this is maybe a whole other podcast.

39:44 You're bringing up a really interesting question implicitly, which is there are things that our business stakeholders want their innovation.

39:55 We're seeing that all over with AI right now, but there's things they want.

39:59 Brad: that i don't think are innovation i'll

40:01 Scott: Tell me.

40:02 Brad: 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 task rabbit somehow task rabbit arrived in 2026 and it still requires an engineer

40:18 Scott: To add a

40:19 Brad: category,

40:19 Scott: right.

40:20 Brad: 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.

40:29 So that's the embarrassing part. And we're fixing that. That's the project we're working on.

40:32 That's Project A.

40:34 And that is not innovation,

40:36 in my opinion,

40:37 at all.

40:39 There has been some kind of resource collisions in terms of people working on that with...

40:45 people bringing conversational AI into our product to help a 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,

41:03 right?

41:03 Scott: Right.

41:03 Brad: Just like us as engineers.

41:05 And if you go in there and say, I need some yard work, conversational AI can say,

41:08 well.

41:09 how big is your yard and it can it can help refine the description that you give to the the tester 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

41:34 this basic feature like

41:36 Scott: yeah

41:36 Brad: the

41:36 Scott: yeah right

41:37 Brad: 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 there's an interesting thing yeah

41:53 Scott: yeah that's fair well and again i think that really scratches that question of like know what you want know what you want and know who

41:59 Brad: you get

42:00 Scott: are that you want it

42:00 Brad: it really does

42:01 Scott: Yeah.

42:02 Brad: Well,

42:03 it scratches a different question,

42:05 which is somewhere back in, I don't know, whenever TaskRabbit started 15,

42:09 18 years ago, someone created some tech debt.

42:11 They

42:12 Scott: Yep.

42:12 Brad: said, you know what, let's just put this in a YAML file.

42:14 Scott: Yeah.

42:14 Brad: And here we are 15 years later paying back that loan.

42:20 And you know what,

42:21 at the time when they were trying to kick off this business,

42:24 that might have been a great loan.

42:27 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.

42:36 Scott: You know, it's super interesting.

42:38 Okay.

42:38 Okay. Now you got me. Now you got me thinking about AI.

42:42 Okay.

42:42 You know what I think is super funny?

42:45 I see this with my AI agents all the time where they.

42:50 will 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 gonna be deferred right and

43:15 It's so funny to me.

43:17 I feel like I'm constantly saying to them,

43:20 no,

43:20 don't defer.

43:22 Like, fix it now.

43:24 Like, I don't want the tech debt.

43:26 Like, fix it now,

43:27 right?

43:28 It's so interesting to me that the way that these LLMs have been trained is they're trained across essentially the history of all the way that us humans have behaved.

43:40 Brad: Mm

43:40 Scott: And

43:40 Brad: -hmm.

43:40 Scott: so it's like you and I were joking the other day when when you ask Cursor or Claude for an estimate,

43:45 it comes back with like two weeks or something,

43:48 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.

43:54 And so I do I do think there's so you've made me kind of remember that one of the things that.

44:03 we're evolving through right now is the fact that the language of engineering,

44:11 the

44:11 Brad: Mm-hmm.

44:12 Scott: language of estimations, the language of the decisions around technical debt,

44:19 the language that we have around do we make that investment now or do we live with it for now,

44:27 right?

44:29 All of that language was predicated on the writing of the code taking a lot of time.

44:36 Brad: Mm-hmm.

44:38 Scott: And now that the writing of the code takes a lot less time,

44:41 a lot of those decisions and the language around those decisions, I think, are outdated.

44:51 Brad: Mm-hmm.

44:52 Scott: And the LLMs are programmed on the old historic outdated way of talking about decisions.

44:59 Brad: That's interesting.

45:00 Scott: Right?

45:01 Brad: Yeah, that's really fascinating.

45:03 Scott: And so when you were talking about like,

45:04 oh, you know, when the you know, whatever 15 years ago when somebody decided categories should just be in a YAML file,

45:10 right?

45:11 Like, yeah,

45:12 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 two week project that you didn't really need to do at that time.

45:25 Right.

45:25 Brad: Yeah, you're trying to get your company launched and you're just like we'll deal with that later.

45:28 We don't need to change a category right now We'll deal with it later.

45:31 Scott: Exactly.

45:31 Brad: They can call us and put it within a new category

45:33 Scott: But now you can write that UI right out of the gate and and or you can, you know.

45:41 have the agent go fix that ui you know it's 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

46:07 Get your backlog in order.

46:09 What do you really want me to spend my time on?

46:12 Because I can write this stuff so much faster now.

46:16 Brad: Yeah, but it's still I want it all.

46:18 And there are still humans in the process,

46:20 right?

46:21 We're not yet at infinite code infinitely fast.

46:23 I know there are teams that are going very, very fast, but like, we're still, I don't think we're yet at infinite code, infinite code

46:30 Scott: No, I agree with you. I 100% agree with you.

46:33 And I'm saying like,

46:34 no matter what the system is, no matter how fast you're going,

46:38 you still need to have a really good idea about what you really actually want and the order you want it in.

46:43 Brad: Yeah, people wanted

46:44 Scott: to me

46:45 Brad: it.

46:45 Scott: that's like that's like the 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 that they built and it was a real eye-opener of like all the assumptions that they made like no it like did not resonate with the customers you know and i looked at it and i was like this is great like we learned something we got some

47:10 have some real signal here this is so good like 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

47:29 Brad: Yeah,

47:30 I may be a masochist, but like one of the things that brings me the most joy in my job is when

47:37 An A-B test fails.

47:38 Scott: Or what does that mean for that A-B test fails?

47:41 Like, does that mean?

47:41 Brad: We're running an A-B test.

47:42 We've got the way it is currently on the system and we run a comparable,

47:46 we run a new version against it to see. Everyone thinks the new version is going to be better,

47:50 Scott: And

47:50 Brad: right?

47:51 Scott: when the new version is worse,

47:52 that's when you that's what you meant by

47:54 Brad: That's

47:54 Scott: a fail.

47:54 Brad: when you learn.

47:55 Yeah,

47:55 that's when you learn something when your previously held assumptions get overrun by a herd of facts,

48:01 right?

48:02 And I find that.

48:03 As a person who I enjoy learning,

48:06 I always find that really interesting. I'm like, well,

48:08 look at that.

48:09 I didn't know something and I learned something today.

48:12 I think that's pretty cool.

48:13 Scott: Wasn't that one of the stories that Kevin told us about Spotify or something like that,

48:16 how they had developed this real strong culture of like test before you deploy and then on one big project like they didn't do that.

48:24 Brad: Yeah,

48:24 Scott: And it was just like they couldn't.

48:26 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 gonna conflate the signal and you're not gonna know whether or not it was you know was which of those things was the good thing or

48:50 Brad: Just like the avalanche.

48:52 Scott: worse like if you

48:53 Brad: Yeah.

48:53 Scott: If it fails, like if you roll out the prototype with all five features or six features and it's a dud,

48:59 now does that mean

49:01 Brad: all No,

49:01 Scott: five

49:01 Brad: no.

49:01 Scott: features

49:02 Brad: You're lucky.

49:02 Scott: were a dud?

49:02 Brad: Here's something that I think could help engineering go faster.

49:05 I don't know if this is possible.

49:08 If all of us actually, including the engineers,

49:10 had a longer mental time horizon about what we're doing.

49:16 Scott: Yes.

49:18 Brad: It's not this quarter.

49:19 It's not even this year.

49:21 If we're trying to build these businesses to be real enduring businesses,

49:25 TaskRabbit's been around 15 or so years and we're doing a big investment right now to.

49:31 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 serve this company for 15 years the

49:46 Scott: Yeah, totally.

49:47 Brad: thing we're building needs to serve us for the next 15 years or not maybe doesn't even needs to serve us is going to serve this company for the next 15 years and so you

49:57 If it takes a month or two longer to get us the right thing that will serve this company for 15 years,

50:03 that's the right decision.

50:05 But so many companies in America are very monthly,

50:09 sprintly, monthly,

50:12 quarterly,

50:13 yearly.

50:15 oriented,

50:16 right?

50:16 And there's very,

50:17 very few companies that think in decades.

50:20 Scott: I don't know if it's still in the code base,

50:22 but like 10 years ago.

50:25 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 pay it's like some undo buffer inside of some code that's like and it was and the where this code came from was it was code I wrote at Asymetrix

50:51 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 that

51:11 Brad: That's kind of cool.

51:12 Scott: I never worked for the company of right and

51:15 So, yeah, I agree with your point that like – and by the way, the book Incorruptible, everybody check it out, Eric Ries' latest book.

51:23 It talks a lot about that, this idea of like companies that really have a mission to live – to really make a positive impact on the world,

51:35 then those are companies that want to live for –

51:42 centuries

51:43 Brad: Mm hmm.

51:44 You know, that reminds me of another book recommendation I'll make on this podcast here called The Living Company.

51:50 I think the author was Ari DeGuisse, like a Dutch name.

51:55 And it was a study.

51:59 of companies that had been in business for 200 years or longer so

52:03 Scott: Oh, wow,

52:04 that's cool.

52:04 Brad: 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

52:24 stuff like that totally different right

52:25 Scott: Yeah,

52:26 Brad: so

52:26 Scott: totally.

52:26 Brad: something about your culture your dna is not about the product or service that you're offering it's about something else and fundamentally if i'm 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

52:45 take their foot off the gas pedal of profits just a little bit like in my mind's eye as i 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

53:03 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.

53:13 We are here to ensure that this company perseveres.

53:20 We're just stewards of this company. Our job

53:22 Scott: Yeah.

53:22 Brad: is just to keep it going,

53:24 not

53:24 Scott: Yeah.

53:24 Brad: to necessarily maximize today's profit.

53:27 And that's a very un-American thing, an American way of thinking.

53:30 Scott: It's rare in today's sort of like view of capitalism as it exists today.

53:37 But it's not unique.

53:38 Like Costco,

53:39 great example of a company that has very, very focused vision around their customers are their customers.

53:47 are their primary stakeholder right providing

53:49 Brad: Yeah, yeah,

53:49 Scott: 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 dollar 50 hot dog soda combo and when they first introduce that a big mac cost a dollar 63

54:13 And their hot dog soda combo was $1.50.

54:16 They have kept the price at $1.50.

54:20 um and it includes that they've solved the problem of they actually make their own hot dogs right they've solved

54:25 Brad: Yeah.

54:25 Scott: this problem by 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

54:45 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

55:02 Brad: It is. Well,

55:03 that's a great place to leave off.

55:04 Maybe I'll go to Costco and get a hot dog tonight.

55:06 I don't know if you know this, but I recently was applied and was.

55:10 approved and selected to be a member of costco Are well

55:13 Scott: you an exclusive member?

55:15 Are you an executive member?

55:17 Brad: i'm a gold star member

55:18 Scott: You're

55:18 Brad: so i haven't

55:19 Scott: a gold graduated star member?

55:19 Brad: to executive yet Oh, but

55:21 Scott: wow,

55:21 Brad: somehow

55:21 Scott: man.

55:21 Brad: 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

55:37 Never been a member of Costco.

55:40 Scott: There you go. Welcome to the club. It's a great club.

55:43 Brad: Yeah,

55:44 I'm in now.

55:44 I'm a card carrying member.

55:45 Scott: Card carrying member.

55:47 All right there.

55:48 That's how we're going to end it.

55:50 Scott, finally a card carrying member of Costco.

55:54 Brad: Is that the title of this episode?

55:56 Scott: Card carrying member of Costco.

55:59 Brad: Brad, this has been really fun.

56:01 Scott: The wild ride,

56:02 Brad: What

56:03 Scott: Scott.

56:03 Brad: do

56:03 Scott: It's been

56:03 Brad: we

56:03 Scott: a wild

56:03 Brad: need ride. folks to do?

56:05 Scott: Smash.

56:05 Smash that subscribe button.

56:07 Brad: Rate and review. We really appreciate it, gang.

56:10 And we look forward to seeing you next week.

56:12 Scott: All right. See you next week, Scott.

56:13 This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Heptegau.

56:19 Our theme song was AI generated by Brad.

56:23 Please follow us on all the social media platforms.

56:25 platforms at HowManyCTOsPod. You can find us on YouTube,

56:30 LinkedIn,

56:30 Instagram,

56:31 Facebook,

56:32 Threads, X,

56:33 TikTok,

56:33 and Patreon,

56:34 or at our website at HowManyCTOsPod.com.

56:38 And remember to rate,

56:39 review,

56:39 and subscribe on the podcast platform of your choice.

56:42 Thanks for listening.