Transcript: 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 Scott Hello, everybody. Welcome back to How Many CTOs Does It Take podcast.
0:23 Scott My name is Scott Porad,
0:24 Scott and this is my trusty co-host,
0:26 Brad Brad Hefta-Gaub.
0:28 Scott Brad,
0:29 Scott I was thinking about the episode we did recently about systems thinking.
0:33 Scott And early in that episode, I talked about how systems consist of a few different people.
0:38 Scott I'm sorry.
0:39 Scott Systems consist of two or more entities in a boundary and that systems have.
0:45 Scott unspoken rules and norms.
0:47 Scott 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 Brad I can't wait to hear about this.
1:03 Scott It was a conversation about engineering velocity.
1:07 Scott And there were three people in the room and all three of these members were senior leadership team members.
1:12 Scott 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 Scott I want to maximize the utilization of the engineering team.
1:22 Scott And a third person was saying,
1:24 Scott I want things to be on time.
1:27 Scott 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 Scott 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 Scott And I was saying as the engineering leader,
1:46 Scott 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 Scott 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 Scott So I was just thinking of that because an unspoken thing surfaced, right?
2:05 Scott It was all kind of a thing we all had in our head, but we had never put it on paper,
2:09 Scott 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 Scott right?
2:15 Scott And so here I am trying to figure out how to make stuff go faster.
2:18 Scott 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 Scott And on schedule,
2:24 Scott I thought that was interesting.
2:26 Scott Maybe there's not even a spicy topic in here for a discussion, but I just remembered our conversation and was like,
2:33 Scott 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 Scott which is if you were the hand of God and could wave your magic wand.
2:50 Scott 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 Brad 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 Brad you probably are sandbagging.
3:26 Scott that's right.
3:27 Scott I can be 100% accurate.
3:28 Scott Absolutely.
3:29 Scott Right.
3:29 Scott It takes like six years.
3:32 Scott And so actually, it would still probably be late the rate we go. But nevertheless,
3:36 Scott I actually just think businesses depend on schedules.
3:39 Scott Right.
3:40 Scott Marketing launches need to happen.
3:42 Scott Customer service needs to get trained.
3:45 Scott Seasonality happens and customers need products,
3:47 Scott whatever.
3:47 Scott So I just think that companies, not just our company,
3:49 Scott every company needs.
3:51 Scott OK,
3:52 Scott actually, I want to change what I'm going to say.
3:55 Scott Damn it. Damn it. Because I thought of another thing from that episode,
3:58 Scott which was innovation.
4:00 Brad Yeah.
4:01 Scott I think if you're doing innovation,
4:02 Scott it has nothing to do with any of these three,
4:04 Scott right?
4:05 Scott If you're doing innovation, innovation comes when it comes, so you can't try to be on time.
4:09 Scott And if you're doing innovation,
4:10 Scott 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 Scott you're not going to go fast because you're going to have to take time, right?
4:26 Scott So innovation is something different,
4:28 Scott 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 Scott Here's another unspoken thing.
4:39 Scott 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 Brad manufacturing organization is all about optimizing your factory line,
4:56 Brad 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 Scott But none of these three things have to do with an innovation organization.
5:02 Brad Yeah, well,
5:03 Brad so let me give you my hot take with your original framing of it, if it's what I want,
5:08 Brad maximum utilization,
5:09 Brad on time, or speed.
5:13 Brad 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 Brad 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 Scott There is massive science behind that. To maximize the output of the system, you run between 50 and 80% utilization.
6:29 Scott And we all know this because we've all been in a traffic jam.
6:32 Brad Yeah. Okay.
6:33 Brad 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 Brad Now, I think that's going to be stage dependent and project dependent.
6:48 Brad 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 Brad 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 Brad And so I would much rather optimize for give me the best shot at getting stuff done as quickly as possible,
7:11 Brad even if that means you're taking risks where sometimes you might miss some.
7:15 Brad 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 Scott searching for product market fit stage.
7:37 Scott And then you get into your next stage,
7:39 Scott which is your growth stage.
7:42 Scott You found product market fit and you are still growing.
7:45 Scott 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 Brad 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 Brad whatever that might be,
8:03 Brad I still feel like I'm trying to learn as much as possible. And again,
8:08 Brad I'm going to stand with.
8:08 Brad And with like,
8:09 Brad if I'm trying to learn, if I need signal of any kind,
8:12 Brad 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 Brad 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 Brad The big showy launch has,
8:38 Brad 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 Brad the only time that like my land exactly on time matters,
8:51 Brad 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 Brad anybody listening to this who is looking to hire me as a fractional CTO like.
9:10 Brad So like,
9:11 Brad yeah,
9:11 Brad I'm not saying that you can.
9:13 Brad You can just be completely willy-nilly and not hit dates at all,
9:17 Brad right?
9:17 Brad But I just think that if you're moving,
9:19 Brad 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 Brad you're more likely to hit things on time.
9:31 Scott Okay,
9:32 Scott here's a dynamic I've observed in a few different places.
9:35 Scott So if you did HealthCo,
9:37 Scott we worked at HealthcareCo,
9:38 Scott whatever we call it.
9:39 Scott 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 Scott But quality becomes more important and quality takes on some additional dimensions just besides the quality of your software,
10:03 Scott which includes the stability of your system. It also takes on like.
10:08 Scott 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 Brad like one of the things I said was like, yeah,
10:30 Brad to make your engineering team go faster, you need to make sure you have the systems around it go faster too.
10:35 Brad or two.
10:36 Brad And one of those systems I think is that launch system,
10:38 Brad whatever that launch system is, whether that's customer training,
10:41 Brad customer documentation,
10:43 Brad you know, whatever that there's some like that matters too.
10:47 Brad 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 Brad A hundred percent.
11:03 Brad Yeah.
11:03 Scott Lickety split.
11:05 Brad Lickety split.
11:06 Brad Yeah.
11:07 Brad I mean, anyway,
11:08 Brad 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 Scott 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 Brad 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 Scott That's still pretty tight in our business,
11:37 Scott honestly.
11:38 Brad That's pretty tight in our business.
11:39 Brad Or the other way to look at the 80% is I got.
11:44 Brad 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 Scott 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 Scott 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 Brad And, you know, again,
12:53 Brad like not to not to necessarily belabor this point, but.
12:57 Brad It's so often not about the code, right?
13:01 Brad 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 Brad 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 Brad Right.
13:19 Brad 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 Brad 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 Brad They're off the rails, right?
13:44 Brad 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 Scott early up front, you know, someone makes a very coarse grained technical design. They make a bunch of assumptions about like,
14:00 Scott well,
14:00 Scott 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 Scott And then you get into it.
14:09 Scott And you're like,
14:10 Scott 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 Brad 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 Brad You know, when you have a big unknown,
14:50 Brad when you have unknown unknowns or you have known unknowns,
14:53 Brad like,
14:54 Brad man, try to front load those, right?
14:55 Brad 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 Brad right?
15:02 Scott Yeah.
15:02 Brad It's such a rookie mistake to be like,
15:05 Brad oh, yeah, yeah, yeah, we think it's going to do this. We're going to do it this way.
15:09 Brad And then somehow like the team takes on like the easy parts first and they delay the hard part.
15:15 Brad 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 Brad 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 Scott 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 Brad Scott.
16:02 Brad Bye.
16:03 Brad This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Tepdekau.
16:09 Brad Our theme song was AI-generated by Brad.
16:12 Brad Please follow us on all the social media platforms at HowManyCTOsPod.
16:17 Brad You can find us on YouTube,
16:19 Brad LinkedIn,
16:20 Brad Instagram,
16:21 Brad Facebook,
16:21 Brad Threads, X,
16:22 Brad TikTok,
16:23 Brad and Patreon,
16:23 Brad or at our website at HowManyCTOsPod.
16:25 Brad HowManyCTOsPod.com and remember to rate review and subscribe on the podcast platform of your choice.
16:32 Brad Thanks for listening.