Fast, On Time, or Fully Utilized? Choosing What to Optimize in Engineering Delivery

0:00 Scott: There is always one project that is really off schedule.

0:19 Hello, everybody. Welcome back to How Many CTOs Does It Take podcast.

0:23 My name is Scott Porad,

0:24 and this is my trusty co-host,

0:26 Brad: Brad Hefta-Gaub.

0:28 Scott: Brad,

0:29 I was thinking about the episode we did recently about systems thinking.

0:33 And early in that episode, I talked about how systems consist of a few different people.

0:38 I'm sorry.

0:39 Systems consist of two or more entities in a boundary and that systems have.

0:45 unspoken rules and norms.

0:47 And I was thinking about that, and I was thinking about an unspoken thing that surfaced in my workplace recently that

0:57 Brad: Oh, boy.

0:57 Scott: is extremely relevant to engineering.

1:01 Brad: Okay.

1:02 I can't wait to hear about this.

1:03 Scott: It was a conversation about engineering velocity.

1:07 And there were three people in the room and all three of these members were senior leadership team members.

1:12 And one person was saying, I want to get stuff done as fast as possible.

1:16 Brad: Okay.

1:16 Scott: And another person was saying,

1:18 I want to maximize the utilization of the engineering team.

1:22 And a third person was saying,

1:24 I want things to be on time.

1:27 They're delivered on time.

1:29 Brad: Okay.

1:29 Scott: Actually, the whole conversation started with somebody being unhappy that something was late, right?

1:35 And the utilization person was kind of saying like, I'm okay with it being late because we're getting the most out of our people.

1:44 And I was saying as the engineering leader,

1:46 I was like, well, wait a second. All I'm hearing from this whole company is they want things faster. They want velocity.

1:50 Brad: Right.

1:51 Scott: So do we want things faster?

1:52 Do we want things on time? Or do we want to maximize utilization of our resources? We can't have all three of those.

1:58 Brad: Yeah, yeah.

1:59 Scott: Okay, let me ask you a question.

2:00 So I was just thinking of that because an unspoken thing surfaced, right?

2:05 It was all kind of a thing we all had in our head, but we had never put it on paper,

2:09 or we don't need to put it on paper, but we never really actually aligned of how we wanted our system to work,

2:14 right?

2:15 And so here I am trying to figure out how to make stuff go faster.

2:18 This other guy is trying to figure out how to maximize utilization of people and this other person is trying to figure out how to get stuff to land on.

2:23 And on schedule,

2:24 I thought that was interesting.

2:26 Maybe there's not even a spicy topic in here for a discussion, but I just remembered our conversation and was like,

2:33 oh, that's really fascinating here. We have a system, software delivery with norms or expectations that are not clear.

2:41 Brad: Yeah.

2:42 Scott: And I guess there is a question in here,

2:44 which is if you were the hand of God and could wave your magic wand.

2:50 which would you choose which would you choose would you choose delivering on

2:54 Brad: Oh, yeah.

2:54 Scott: time maximizing the resources or getting it done faster or maybe how would you rank them or how would you balance them etc you

3:03 Brad: Man,

3:03 that's an interesting question.

3:04 Scott: want me you want me to just say what i think

3:05 Brad: Yeah, tell me what you think.

3:07 Scott: i think deliver on time with 80 accuracy

3:12 Brad: I think you've said that before. You've always said like your metric for like engineering velocity is if you're hitting 80% accuracy, then I feel pretty good because it means you're not sandbagging because if

3:23 Scott: Yeah,

3:23 Brad: you're 100% accurate,

3:24 you probably are sandbagging.

3:26 Scott: that's right.

3:27 I can be 100% accurate.

3:28 Absolutely.

3:29 Right.

3:29 It takes like six years.

3:32 And so actually, it would still probably be late the rate we go. But nevertheless,

3:36 I actually just think businesses depend on schedules.

3:39 Right.

3:40 Marketing launches need to happen.

3:42 Customer service needs to get trained.

3:45 Seasonality happens and customers need products,

3:47 whatever.

3:47 So I just think that companies, not just our company,

3:49 every company needs.

3:51 OK,

3:52 actually, I want to change what I'm going to say.

3:55 Damn it. Damn it. Because I thought of another thing from that episode,

3:58 which was innovation.

4:00 Brad: Yeah.

4:01 Scott: I think if you're doing innovation,

4:02 it has nothing to do with any of these three,

4:04 right?

4:05 If you're doing innovation, innovation comes when it comes, so you can't try to be on time.

4:09 And if you're doing innovation,

4:10 you can't try to maximize your resources. You need to have a bunch of flexibility in there for people to fuck around and find out, right?

4:17 Brad: Ha, ha, ha, ha.

4:19 Scott: And, you know, and if you're doing innovation.

4:23 you're not going to go fast because you're going to have to take time, right?

4:26 So innovation is something different,

4:28 actually.

4:29 Brad: All right. Well,

4:29 Scott: We're

4:29 Brad: okay.

4:30 Scott: actually talking about manufacturing. We're on a manufacturing... Now, oh, this is fascinating. Another unspoken thing. Another... This didn't even come up in our conversation.

4:37 Here's another unspoken thing.

4:39 Are we operating an innovation organization or a manufacturing organization?

4:44 Brad: Interesting.

4:44 Scott: Because you operate them differently.

4:48 Brad: Yeah,

4:48 manufacturing organization is all about optimizing your factory line,

4:56 you

4:56 Scott: One

4:56 Brad: know.

4:56 Scott: of you optimizing one of these three things,

4:58 Brad: Yeah.

4:58 Scott: right?

4:59 But none of these three things have to do with an innovation organization.

5:02 Brad: Yeah, well,

5:03 so let me give you my hot take with your original framing of it, if it's what I want,

5:08 maximum utilization,

5:09 on time, or speed.

5:13 my first my first answer I'm going to throw out maximum utilization because I don't even know what that means or why that's at all useful that just means that you you hired the right number you hired exactly the people that you're using like I don't even that just doesn't feel like important at

5:29 Scott: Every

5:29 Brad: all like

5:29 Scott: resource is being applied to the highest priority thing 100%. There's no time in their day that is not being used for producing code.

5:38 Brad: well okay i just am still throwing that one out i just don't i just don't buy it like i i just don't think that's a goal that anybody should have i

5:46 Scott: let's look the

5:46 Brad: right

5:46 Scott: other way around like if you had zero utilization nothing would get done so there has to be some utilization

5:51 Brad: but i'm just saying like the metric of 100 utilization just seems useless to me i i wait like if i'm going really like guess what like it may be that i go faster when i am slightly underutilized because the one person that

6:05 something that does get utilized like slows us down or something like that now obviously we should we should we should probably you know performance improve that person and get them out the door but like i just like i'm just not even measuring like how busy everybody was that just doesn't seem right at all like

6:19 Scott: That is absolutely not a guesswork.

6:22 There is massive science behind that. To maximize the output of the system, you run between 50 and 80% utilization.

6:29 And we all know this because we've all been in a traffic jam.

6:32 Brad: Yeah. Okay.

6:33 So let's get that one out of the way. I'm not picking that one.

6:36 Scott: Yep.

6:36 Brad: So now I'm left with go fast or go on time.

6:42 Now, I think that's going to be stage dependent and project dependent.

6:48 And I think that if it's early stage or experimental stage or you're trying to find product market fit or you're trying to find product market optimization,

6:58 then I think you have to go fast because you just don't know. You're trying to get signal as fast as possible.

7:04 And so I would much rather optimize for give me the best shot at getting stuff done as quickly as possible,

7:11 even if that means you're taking risks where sometimes you might miss some.

7:15 something and miss the date because like

7:17 Scott: So that's early,

7:18 Brad: it doesn't

7:18 Scott: that's early stage.

7:18 Brad: help me yeah that's early stage or that's like the part whatever stage you're in where you're kind of like trying to learn as fast as possible to learn as fast as possible you need to produce as fast as possible

7:31 Scott: So I would describe the first stage as your product market exploring,

7:34 searching for product market fit stage.

7:37 And then you get into your next stage,

7:39 which is your growth stage.

7:42 You found product market fit and you are still growing.

7:45 Customers are adopting your product

7:47 Brad: I

7:47 Scott: or service.

7:47 Brad: still think that like depending on how I'm growing,

7:50 like if the way I'm growing is I'm trying to find new innovations or new features or new things that will cause my app to grow or my product to grow or my business to grow,

8:02 whatever that might be,

8:03 I still feel like I'm trying to learn as much as possible. And again,

8:08 I'm going to stand with.

8:08 And with like,

8:09 if I'm trying to learn, if I need signal of any kind,

8:12 whether I've got, let's say I've got product market fit, but now I'm trying to like, you know, land and expand or I'm trying

8:18 Scott: Mm

8:18 Brad: to, you

8:19 Scott: -hmm.

8:19 Brad: know, I'm trying to build into new segments of my market, right?

8:24 I'm, I still feel like I'm going to want faster and I, and I feel like, well, a part of me like.

8:34 The big showy launch has,

8:38 like I haven't seen the big showy launch be that effective at growing businesses anyway.

8:45 Scott: No.

8:46 Brad: And so therefore,

8:47 the only time that like my land exactly on time matters,

8:51 I think, is when I've got these externalities of like the big showy launch or something like that.

8:56 Scott: It matters if there's some financial result tied to it that people are expecting.

9:01 Brad: Sure, of course, I agree with that. And that's about and so yeah,

9:05 anybody listening to this who is looking to hire me as a fractional CTO like.

9:10 So like,

9:11 yeah,

9:11 I'm not saying that you can.

9:13 You can just be completely willy-nilly and not hit dates at all,

9:17 right?

9:17 But I just think that if you're moving,

9:19 if you're optimizing your systems and you're optimizing all of your tech and your systems and your people to be able to move quickly,

9:28 you're more likely to hit things on time.

9:31 Scott: Okay,

9:32 here's a dynamic I've observed in a few different places.

9:35 So if you did HealthCo,

9:37 we worked at HealthcareCo,

9:38 whatever we call it.

9:39 call it um starting to observe it a little bit where i'm at now company gets to product market fit you're getting bigger you've got more customers um and you know maybe doing a lot of revenue and you're still wanting to move fast

9:56 But quality becomes more important and quality takes on some additional dimensions just besides the quality of your software,

10:03 which includes the stability of your system. It also takes on like.

10:08 the information security and

10:10 Brad: Or

10:10 Scott: and

10:11 Brad: the quality of

10:11 Scott: uh yeah

10:11 Brad: your training or the quality of your documentation or the – well,

10:15 Scott: so i've seen what's kind of slows stuff slows stuff down is all this quality stuff that gets out there right that's

10:22 Brad: this is – I think that same message

10:23 Scott: what gets

10:24 Brad: that

10:24 Scott: out

10:24 Brad: you – the episode that you were talking about where we talked about this last,

10:28 like one of the things I said was like, yeah,

10:30 to make your engineering team go faster, you need to make sure you have the systems around it go faster too.

10:35 or two.

10:36 And one of those systems I think is that launch system,

10:38 whatever that launch system is, whether that's customer training,

10:41 customer documentation,

10:43 you know, whatever that there's some like that matters too.

10:47 Right.

10:48 Scott: Well, or actually this is interesting back to that episode you think about like maybe you're doing something in engineering and it needs a legal review or it needs a security review that needs to happen lickety split.

11:00 Brad: That stuff has to happen really fast.

11:01 A hundred percent.

11:03 Yeah.

11:03 Scott: Lickety split.

11:05 Brad: Lickety split.

11:06 Yeah.

11:07 I mean, anyway,

11:08 so I think my answer is go

11:10 Scott: fast. Yours is fast.

11:11 Brad: I

11:11 Scott: Yours would is fast.

11:12 Brad: go fast.

11:12 Scott: Optimize for going fast at

11:14 Brad: Optimize for

11:15 Scott: the

11:15 Brad: going

11:15 Scott: expense

11:15 Brad: fast.

11:15 Scott: of schedule within reason.

11:18 The expensive schedule within reason.

11:20 Brad: Within reason.

11:20 Scott: What's your within reason?

11:23 Brad: I mean, I kind of like your 80% rule.

11:25 That's not a bad rule.

11:26 Scott: So 80% would be if you said it was going to take a week, it could take six days, or if you said it was going to take a month, it could take five weeks.

11:36 That's still pretty tight in our business,

11:37 honestly.

11:38 Brad: That's pretty tight in our business.

11:39 Or the other way to look at the 80% is I got.

11:44 80 of the stuff landed on time and 20 of the stuff

11:47 Scott: was way off track i

11:48 Brad: was off track and i should know that i'll know the 20 is going to be off track pretty early right

11:55 Scott: was having a conversation with somebody outside our company the other day a cto whose ceo was very upset because some project was very off schedule and like didn't quite know what to do about it i said look

12:10 my experience there is always one project that is really off schedule there's always one there it's like it's like a conservation there's always something going poorly and if you get that one fixed there's going to be another one going poorly and so somehow you just have to get the ceo to understand there's always in our business there's always something not going right and you just kind of have to be in your do your best to mitigate it and deal with it and get it back on track but if your idea

12:37 is that you can have everything always go smoothly like you're in the wrong business it's just not the way it works there's just a conservation a conservation of projects that have gone off the rails

12:50 Brad: Yeah, totally.

12:51 And, you know, again,

12:53 like not to not to necessarily belabor this point, but.

12:57 It's so often not about the code, right?

13:01 It's so often it's, I mean, sometimes it's like you tried to take something on and it's like it actually was harder to build than you thought it was going to be.

13:10 Yeah. But more often than not, the projects that go off the rails are going off the rails because you didn't really know exactly what you were trying to build.

13:18 Right.

13:19 Like a

13:19 Scott: Yeah.

13:19 Brad: classic example of this is did you did you pre sell something? Did you sell something to a customer before you actually had it nailed down? Right.

13:29 Scott: Yeah.

13:29 Brad: And then once the customer hears about it, then they start.

13:33 But you haven't really delivered it to them yet. Then next thing you know, it's like feature whataboutism and you're like adding more and more features and that's what's causing the project to get further and further off.

13:43 They're off the rails, right?

13:44 Like

13:44 Scott: Yeah.

13:45 Brad: that happens all the time.

13:46 Scott: I think the other place I've seen it happen is, okay,

13:51 early up front, you know, someone makes a very coarse grained technical design. They make a bunch of assumptions about like,

14:00 well,

14:00 I think this is how this is going to work. And then they give a very rough estimate like, yeah, I think this is how it's going to work. I think we can do this in a month, like so on and so forth.

14:08 And then you get into it.

14:09 And you're like,

14:10 oh, there's some bad assumptions in there.

14:13 Brad: Right.

14:14 Scott: it turns out the whatever there's some bad assumptions on there so and i've seen that be a and then all of a sudden the unraveling starts because you're you're like several stages down the process but practically speaking you actually need to go back to square one right

14:30 Brad: Yeah.

14:31 Scott: but you're not in the position really to go back to square one and so now you're just like running as fast as you can to keep from falling off the back of the treadmill and it just turns into a mess

14:40 Brad: Yeah, totally.

14:41 And I think that, you know, the one thing I would say about that is, and I'm sure that this is consistent with your experience as well, is that like.

14:49 You know, when you have a big unknown,

14:50 when you have unknown unknowns or you have known unknowns,

14:53 like,

14:54 man, try to front load those, right?

14:55 Like front

14:55 Scott: Right.

14:56 Brad: load those as fast as you can so that you can – so the bad news can travel fast,

15:01 right?

15:02 Scott: Yeah.

15:02 Brad: It's such a rookie mistake to be like,

15:05 oh, yeah, yeah, yeah, we think it's going to do this. We're going to do it this way.

15:09 And then somehow like the team takes on like the easy parts first and they delay the hard part.

15:15 Then

15:16 Scott: always

15:16 Brad: you're

15:16 Scott: do definitely the hard questions yeah

15:17 Brad: going to get screwed in that case, that

15:20 Scott: yeah that's right and now Brad I'm having a senior moment because as we were just talking there I thought of another angle to bring up and I've forgotten it and I think that that statement there in itself probably makes the least interesting podcast content in the history of the world but I thought maybe by saying it out loud it would come back to me it has not

15:37 Brad: you thought,

15:38 oh, I have an idea of something I should say, but I forgot it.

15:42 Scott: I know that's isn't that great we should make a clip of that and put it all of this this needs to be on our socials right here this is how we're going to sell getting people to listen

15:49 Brad: that's

15:49 Scott: to this well

15:50 Brad: right wrap

15:50 Scott: we wrap it there little

15:52 Brad: it there a little mini episode on a little

15:55 Scott: mini episode

15:55 Brad: mini episode on go fast break things

15:58 Scott: Go fast and break things.

16:00 All right. I'll talk to you soon,

16:00 Brad: All

16:00 Scott: Brad.

16:01 Brad: right, talk to you later,

16:01 Scott.

16:02 Bye.

16:03 This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Tepdekau.

16:09 Our theme song was AI-generated by Brad.

16:12 Please follow us on all the social media platforms at HowManyCTOsPod.

16:17 You can find us on YouTube,

16:19 LinkedIn,

16:20 Instagram,

16:21 Facebook,

16:21 Threads, X,

16:22 TikTok,

16:23 and Patreon,

16:23 or at our website at HowManyCTOsPod.

16:25 HowManyCTOsPod.com and remember to rate review and subscribe on the podcast platform of your choice.

16:32 Thanks for listening.