Transcript: Cabinet Doors Should Open: Avoiding Assumptions in Product Requirements

0:00 Scott If you are the builder,

0:00 Scott have a conversation to be clear with the requester that you are building what they want you to build. Between requester and builder,

0:09 Scott there has to be clarity.

0:29 Brad episode of the How Many CTOs Does It Take podcast.

0:32 Brad I'm Brad Hefta-Gaub,

0:33 Brad and this is my co-host.

0:34 Scott I'll pull around.

0:35 Brad All right. And Scott,

0:36 Brad today,

0:37 Brad what do we want to talk about today?

0:39 Brad You pinged me recently and mentioned something about requirements and the frustrations that can come from poorly written requirements.

0:49 Brad Or tell me more about what was on your mind about requirements.

0:52 Scott I'll tell you what's on my mind.

0:54 Scott Brad,

0:54 Scott I am doing a...

0:55 Scott a renovation project at my house?

0:57 Brad Wait,

0:58 Brad we're talking software or we're talking hardware here?

1:01 Scott Well,

1:02 Scott we're talking both, actually. That's what's really interesting about it.

1:05 Scott I'm doing a renovation project at my house and it involves we're getting new kitchen cabinets. So they took out all the old kitchen cabinets,

1:13 Scott they're putting in new kitchen cabinets.

1:14 Scott And every Monday, we meet now they started this project two weeks, three weeks ago,

1:20 Scott and every Monday we meet with the builder, the carpenters, they have a list of questions and stuff to ask us.

1:28 Scott And what has been really surprising to me, they've got, you know, they've got some blueprints.

1:31 Scott blueprints they're not blueprints but you know drawings of what's supposed to happen including all these cabinets and how they're all supposed to fit together and all work and it has been fascinating to me the level of detail they are going through in advance to avoid

1:50 Scott problems so last week most recent meeting we're sitting there and the builder his name is zach you say okay you see this corner where there's like two countertops that come together in a corner and the way these cabinets are they're not going to be able to open all the way because the hinge is going to get pinched right and so you're going to have these two cabinets that don't you're going to be you are going to be unhappy because neither of these will open all the way because of the way this

2:15 Scott this design and he had some ways we can solve it but I thought it was so fascinating how much time he spent studying drawings and these are just drawings drawn by an architect you know they're not real-world mock-ups or anything

2:32 Scott just looking at them thinking about like each little detail how is this going to open how is this drawer going to work how is this cupboard cabinet going to work or not cupboard cabinet how's this cupboard door going to open he's he clearly had spent time thinking through every detail of these pictures before they started building and then brought it to us with his concerns saying look i've observed these things and these are challenges that you're going to run into because clearly he knew that

2:58 Scott Once we order these cabinets and have them delivered and he goes to install them, it's going to be very expensive to deal

3:05 Brad Yeah.

3:05 Scott with it. First of all, we paid for a cabinet that we can't take back.

3:09 Scott Second is it's going to stop his whole project, right?

3:12 Scott He's got a whole schedule of contractors and subcontractors and all these people all queued up to make his whole thing really efficient.

3:19 Scott And if all of a sudden he has to stop for two weeks because our cabinet doors.

3:25 Scott don't open right in this one corner or if you get to the end of the project where the cabinets are in the countertops are in the floors have been done everything's done and we go back into our brand new kitchen and we're like well Zach these

3:38 Brad Again

3:38 Scott door this door sucks this thing sucks I can only open it like three quarters of the way because we can see it hits this other one

3:45 Scott I just thought that was fascinating.

3:47 Brad I'll tell you, you're glad you've got that contractor that's paying that much detail because I have horror stories from times I've done remodels where like, you know, the two examples I can think of is a little mini fridge in the in the wet bar area of the media room where the.

4:07 Brad They didn't measure the overhang of the countertop correctly and the door for the mini fridge wouldn't open because the countertop was overhanging into the door,

4:20 Brad you know, and so they had to solve that problem after the fact because the fridge was built and the countertop was made. It's like, ah,

4:27 Brad it's horrible. And another example similar where the.

4:33 Brad toilet chosen for the powder room the dimensions of it didn't allow the toilet to go into the actual drain uh that the toilet goes to right like they had to you know jerry rig a solution there or buy a different toilet and it's just like you know i remember that toilet was sitting in our garage for like um two months while they figured out a plan to fix the fact that we'd already ordered the toilet and it didn't work

4:58 Scott That's right.

4:59 Scott And so as soon as this happened, I'm in this meeting,

5:01 Scott and when I say it's a meeting,

5:02 Scott I mean, it's just us getting together at our house and talking.

5:05 Scott It's a meeting.

5:06 Scott And I instantly thought about our business and software and just requirements.

5:11 Scott So this wasn't actually a requirement.

5:13 Scott I mean, we just had a requirement that there's two cabins in the corner,

5:15 Brad Well,

5:15 Scott but I just

5:16 Brad and thought, you could open

5:16 Scott yeah,

5:17 Brad them.

5:17 Scott I thought that was a requirement.

5:19 Scott But I just instantly thought about what we do.

5:22 Scott And I mean, I don't know if I reached a conclusion.

5:25 Scott conclusion like i was like huh maybe we should spend a lot more time being a little more water folly and specking this stuff out like it was one thought that came to my mind we just like thought about like wow look how detailed this guy's doing and everyone in our industry like we'll just go in there and start coding right i just thought that was a fascinating difference

5:43 Brad Well,

5:43 Brad I so it's so interesting you say that like I okay so

5:48 Brad the the example of him saying like hey if we did the cabinets the way we talked about it you won't be able to open them like they'll pinch each other you won't be able to open them completely and to then step back and go well of course

6:04 Brad I didn't feel like I had to say it's a requirement that I be able to open my cabinets completely.

6:11 Brad Like,

6:12 Scott Yeah,

6:12 Brad why would you think that that needs to be listed as a requirement?

6:14 Brad It's so obvious that that's a requirement.

6:17 Brad Do you

6:18 Scott yes

6:18 Brad even need to write it down?

6:20 Scott Yes, that's right.

6:21 Brad And I feel like I was like literally just today we were in a sort of like mid sprint demo on a new feature.

6:29 Brad And apparently like there was something that was assumed by, you know, the product owner assumed that it would be drag and drop and real time update of the drag and drop to everybody else in the app at the same time, kind of like they all saw the thing being dragged in real time.

6:46 Brad But that was an assumption.

6:48 Brad And that was never written in any of the product requirements.

6:52 Brad And the developer, of course, didn't think to build that, but was like, well, I just assumed, you know. So how many times has that happened in our careers?

7:01 Scott I think the assumption is really interesting.

7:04 Scott And there's a difference,

7:05 Scott right?

7:06 Scott Zach,

7:07 Scott who's roughly about your or my age, might be five or ten years younger.

7:11 Scott He lives in a house with a family.

7:13 Scott He can make reasonable assumptions.

7:15 Scott assumptions about how a person might like their cabinets to work because

7:18 Brad Because he

7:19 Scott he

7:19 Brad has cabinets.

7:19 Scott has a house he has a house with cabinets whereas so much of what we do in this in the software business i mean even

7:27 Brad It's a big secret.

7:28 Scott when we're not doing something novel it's new and there's no there's just no standard agreement for how these things should work in fact i was on a website recently i wish i could remember what it was

7:40 Scott and the navigation was so poor on this website and it just made me think about like there are so few standards for how anything works with software applications and it makes this job so much harder and it comes back to this assumption there's so few reasonable assumptions like the cabinet should open all the way

8:02 Brad Yeah.

8:03 Scott Did it make our job harder? What conclusion do you think? Is there something that we should take from what the home builder who doesn't want the customer, doesn't want to have his job get behind schedule,

8:14 Scott doesn't want to have to redo the work,

8:16 Scott doesn't want to have an unhappy customer,

8:18 Scott so has taken the effort to go through these plans up front in detail and have a conversation in advance before we've even ordered the cabinets?

8:26 Scott I feel like there's something we should take from that in order to do a better job.

8:30 Scott I'm just not sure what it is exactly.

8:32 Brad It's a great question.

8:33 Brad And I think that, you know, if you sort of like you, you, you, you already keyed this up as a description of more water folly in nature,

8:44 Brad right, versus I think what is mostly the norm these days, which is more of some variation of an agile process.

8:53 Brad I spend most I've spent most of my career in the in this in the startup game where we're doing novel stuff and we're doing stuff where a lot of times we don't.

9:05 Brad we don't really know what we want,

9:07 Brad right?

9:07 Brad There's so many, there's so much in the sort of like entrepreneurial space out there saying like,

9:13 Brad you know, try to be able to move rapidly.

9:16 Brad Don't, don't be too fixed in what you believe the customer wants.

9:20 Brad You need to experiment and give them, give them something good enough to criticize and then adapt quickly.

9:27 Brad Like that is a model that is adopted by a lot of software companies.

9:31 Brad And then, yeah, every once in a while it can bite you where you thought you were, you know, like I think when we had Greg Conklin on the show, you know, he was talking a lot about like get really clear about what your what your core principles of your product are.

9:45 Brad Like if performance is a core principle,

9:47 Brad right,

9:48 Brad then you better say that out of the gate. Right. Because, you know, I think he told a story once where it's like they were dealing with a system where the architect was like, wait a second, like.

9:57 Brad I thought you wanted, you know, an RV.

10:00 Brad If I'd known you'd wanted a Lamborghini, I would have designed this completely differently,

10:04 Scott Mm

10:04 Brad you

10:05 Scott -hmm.

10:05 Brad know.

10:06 Brad So certainly there can be cases where dramatic misunderstandings at the start end up painting you into a corner where you kind of like really struggle to achieve your outcomes.

10:19 Brad But there's so much energy right now in the space around,

10:23 Brad you know.

10:25 Brad iterate quickly,

10:26 Brad don't be too beholden to one idea because

10:30 Brad You don't really know what good looks like.

10:33 Brad And I think that's this wave or this gravity that pushes against the thing that you're asking,

10:39 Brad should we do more of?

10:40 Scott Yeah, and I'm going to try and split the baby.

10:43 Scott It goes like this.

10:45 Scott Agile said don't document all these crazy plans up front because you don't really know if the customer wants them. So build something and see if they want it.

10:55 Scott And what we're really saying is something different,

10:59 Scott which is if you were the builder,

11:02 Scott have a conversation to be clear with the requester that you are building what they want you to build.

11:09 Scott Now, the requester might not know what the customer wants, so they might want you to build it rapidly,

11:13 Scott but at least between requester and builder,

11:16 Scott there has to be clarity.

11:18 Scott And what I would take from this actually is not as I think there's actually a different prescription than being more water folly.

11:25 Scott I would say if you were an engineer,

11:27 Scott if I were an engineer, my ticket then pulling off the wall to go work on could just have one line. It could just say, you know, go add a flux capacitor to the DeLorean,

11:37 Scott but go take,

11:39 Scott it is worth it to take a minute just like Zach did.

11:44 Scott with my wife and I, Lisa,

11:45 Scott to look at that carefully and have a conversation with the person requesting and saying,

11:52 Scott well,

11:52 Scott this is what I see here.

11:53 Scott Is that what you really meant?

11:55 Scott Because your cabinet's not going to open.

11:57 Brad Yeah.

11:57 Scott And by the way, I've built software before and I have a hunch you're going to want your cabinet to open when I'm done with it.

12:05 Scott So let's just talk this through.

12:08 Scott We don't have to build a whole spec. Let's just have a conversation.

12:11 Brad Yeah, I by the way, I think that's 100% good,

12:16 Brad good practice, you know, in the in the in the current scale of organizations that I'm working with very,

12:24 Brad very small scale so I can kind of be in the room when those types of conversations should be happening.

12:31 Brad And 100% those are what I am trying to teach and encourage engineering teams to do is to create these very open,

12:41 Brad you know, frank,

12:43 Brad whatever you want to call it, but like, you know, curious conversations between the engineers doing the work and the product owners describing the work. And also.

12:52 Brad wherever possible involved in that conversation should be a here's what I think you're asking for am I hearing you correctly right am I understanding what you're asking for correctly so that's like a that's required that's table stakes but another part of that conversation should be my instinct is it's going to be this expensive to build what you've asked for have you considered tweaking these pieces of your ask

13:19 Brad Because in my experience, if I tweak these pieces of what you're asking for,

13:23 Brad it will have a different cost outcome.

13:27 Brad Like it'll be less expensive.

13:28 Brad It'll take me less time to build it.

13:30 Brad For example,

13:30 Brad I can build it the way you're asking.

13:32 Brad I can build you what you're asking for.

13:33 Brad But if I take that requirement off or I add this other slight nuance,

13:37 Brad it changes your investment profile.

13:40 Brad Have you considered that?

13:41 Brad I think that is a super important conversation that also should be happening and probably doesn't happen enough.

13:47 Scott Yeah, that's right.

13:48 Scott In fact, that's similar to what happened with Lisa and I in our cabinet.

13:53 Scott Because we wanted to have the cabinet a certain way and I won't go into the detail and he could figure out a solution,

14:04 Scott right?

14:05 Scott Or we could have it a little different.

14:08 Scott I think what we're really saying though is we're saying a lot of things, but another thing we're saying is as an engineer,

14:14 Scott to be a really good one, to deliver a high quality thing that your customer will be happy with that's on time.

14:19 Scott time and sometimes your customer is just the requester it's not the end user but just to deliver a thing on time that's high quality that meets your standards of quality etc you're not an order taker you have to be engaged in the process it is a creative process

14:33 Brad Yeah.

14:34 Scott You got to participate and you can't just pick a ticket up.

14:37 Scott The expectation that someone can write a perfect ticket implies that they have the forethought to say and the cabinet should open all the way.

14:46 Brad Yeah, right.

14:48 Brad Right.

14:48 Brad Exactly.

14:49 Scott Isn't that obvious?

14:51 Brad Right. And we've talked about, you know, recently we spent some time talking about software development lifecycle.

14:58 Brad And one of the parts that we talked a lot about was this question of like,

15:01 Brad well,

15:02 Brad you know, and we talked about quality and we talked about the idea that like.

15:06 Brad quality begins and your software development lifecycle begins way upstream when you're just trying to figure out like what are you building what are you what problem are you trying to solve

15:14 Scott Mm

15:14 Brad right

15:15 Scott -hmm.

15:15 Brad not the writing of the code but the description of the problem you're trying to solve is

15:19 Scott Yeah.

15:19 Brad is critical one of the other practices that I encourage teams to implement and I'm seeing some good success with this in some of the projects I'm working on now is

15:32 Brad That back and forth, that dialogue, that curious conversation between the future implementers and the ideators, right,

15:41 Brad the product team and the development team,

15:43 Brad you don't even want to wait. You would like to get that conversation started as soon as the ideators are starting to ideate.

15:51 Scott Mm

15:51 Brad Right.

15:51 Scott -hmm.

15:52 Brad Because if they can say,

15:54 Brad hey, we've been thinking about adding a new feature X and here's some stuff we think we want to do with that. Right.

16:02 Brad Right out of the gate, the engineers can start thinking about it and go, yeah,

16:06 Brad OK,

16:06 Brad you're not done with your.

16:09 Brad You don't know your requirements on us yet,

16:11 Brad but here are some things on our mind that we're going to want to ask you when you finally do come to us with this idea.

16:17 Brad We're going to want to ask you about, is it real time?

16:20 Brad Does it need to work on low-end machines?

16:24 Brad Does it only work on high-end machines?

16:25 Brad The things that are going to pop into – because most engineers,

16:29 Brad as soon as they hear the description of the thing,

16:31 Brad they start to imagine how they will implement it.

16:34 Scott Mm-hmm.

16:35 Brad And they can start to ask questions early that then might inform and hopefully improve the.

16:46 Brad The actual feature requests the requirements before the okay now we're really trying to understand your requirements

16:53 Scott Well, and they can,

16:54 Scott I think this is something I see a lot.

16:58 Scott Engineers can push it further in two different ways.

17:02 Scott One is a technology way,

17:04 Scott which is like, I'll give you a simple example. It's not perfectly simple,

17:08 Scott but if else,

17:10 Scott so conditional,

17:11 Scott a conditional solution.

17:13 Scott versus a probabilistic model solution.

17:16 Scott Lots of times someone will come and say, I want to build this thing.

17:19 Scott And if the customer does this,

17:20 Scott then we should do this. And if the customer does that, we should do this. An engineer might be able to say,

17:23 Scott we know actually a better way to solve this is to use an ML model.

17:29 Scott right because we actually get might get all types of different scenarios with customers and we want to respond appropriately so that's one example of where engineers can bring their understanding of what technology can do to the table the

17:41 Brad Yeah.

17:42 Scott second the second place I see it happening a lot and I'll be honest earlier in my career I think I I think I earned a lot of the success that in my early career because this is something that I was good at bringing to the table

17:55 Scott example is a requester or product manager would bring an idea we should do this and I would be able to sort of say well like okay here's how we could make that generic so like we can solve that specific problem but then like the thing we build will solve many problems in this category so I think I've maybe mentioned on this podcast if I haven't like the first three companies I worked at

18:20 Scott back in the early days of the internet i worked on content management systems right and so that's very much someone say hey i want you to put a web page up on the site that has these words on it right and i was okay well i can do that for you i can build the system and then you can put up any pages you want on this website right and that's where you take one category of solution and then extract it to a

18:40 Scott generic solution to solve it and I think when that when product pulls in engineering and when engineering is involved earlier and engaged in the process those are two actives what can technology do that you're not thinking of and how can we make this generic to solve a greater set of cases instances of this

19:00 Scott type this is the way to put it right yes

19:03 Brad Yep. I have certainly seen in some organizations a reluctance in product teams to engage in those early conversations.

19:13 Brad So first, have you observed that in your past and what do

19:17 Scott i've

19:17 Brad you think that might be about?

19:18 Scott observed it i think it is about i think it's cultural

19:26 Scott And I think my initial reaction is that it has two aspects to it.

19:32 Scott One dimension of the culture is I don't want to spend,

19:37 Scott this comes from the product management direction,

19:40 Scott I don't want to spend a single minute of my time having my engineers do anything other than coding.

19:45 Scott So I want to get as much out of these engineers as I can get.

19:48 Brad Which is clearly that right there is a misunderstanding of what it takes to have.

19:53 Brad engineers be efficient.

19:54 Scott Yeah.

19:56 Scott I think another aspect of the culture is from the engineering.

20:00 Scott I don't want to go to a meetings. Can you just put it in the ticket?

20:03 Scott Can you just write the PRD? I'll just put it in the PRD. I'll just do it. Just whatever the PRC says,

20:07 Scott I'll get it done.

20:09 Scott And that reminds me of a conversation about

20:16 Scott This is a little bit of a tangent,

20:17 Scott but it has to do with just writing things down.

20:20 Scott An engineering manager I worked with, his name is Johan Heller.

20:25 Scott He actually now is an engineering director at the company I'm at now, but he was an engineering manager then.

20:29 Scott He gave a presentation at a company we worked at a few companies ago about the importance of being specific in your requirements.

20:38 Scott And he talked about if you give me a requirement that says I want a...

20:42 Scott the square i talked to you about

20:44 Brad Yep.

20:44 Scott this before okay

20:45 Brad Yeah,

20:45 Brad you mentioned this in an episode in the past.

20:47 Scott well then i'll be brief and our listeners can go back and find that easter egg but there are many definitions for a square is it a square cash register is it a square box what kind of square do you want is it a square is it a t-square for for measuring things so it was just a really visceral explanation that non-technical people could understand for here's why as an engineer i need specific requirements

21:09 Scott But I only bring this up to say, I think culturally on the engineering side,

21:14 Scott we have engineers who say,

21:15 Scott I don't want to go to meetings. I want to have conversations.

21:17 Scott I want to do this. I don't want to be engaged with it. I just want to take tickets and crush them.

21:22 Brad Yeah.

21:23 Scott That's contributed to it also,

21:25 Scott I think.

21:26 Brad Yeah, sure.

21:27 Brad And I, you know, look,

21:28 Brad I think it takes all kinds, right? So I know there are some engineers that are most effective when they don't have when they can just be given tickets and crushed it. And I think that's we should try to find ways in our organizations to support those types of engineers.

21:41 Brad I prefer to see engineers that are really, really interested in engaging.

21:45 Brad And I think that, you know, in a prior episode,

21:48 Brad we were talking.

21:49 Brad We're talking about the Dora metrics around AI and this notion that some organizations have more user-centric engineering cultures,

21:55 Scott Mm-hmm.

21:55 Brad right?

21:56 Brad To me, user-centric engineering organizations are the types where engineers tend to be really, really curious about understanding the needs of the users,

22:07 Brad and therefore they probably are more likely to want to have those conversations early on.

22:11 Brad They're less likely to be just writing in a ticket and I'll build it type.

22:14 Brad type person um but that being said um yeah i think you're right that like it's cultural one cultural thing you didn't mention that i think i have observed um which i think maybe is good enough to call it an anti-pattern that we want to try to fix if we saw it in an org is a fear of um it's not yet ready for review

22:40 Scott Mm-hmm, mm-hmm.

22:42 Brad Right.

22:44 Brad And or fear of I don't want to be criticized because I'm not yet done with it or I'm not yet ready for it to be critiqued. I'm going to go so far as to say that's a that's an anti pattern that we should try to.

23:01 Brad If we identify it, we should probably try to address it, you know, culturally.

23:06 Brad I mean, the earlier we critique it, the better, honestly,

23:10 Brad right?

23:10 Brad Like if there's a glaring problem in it, we want to find that sooner,

23:14 Brad not later.

23:15 Scott Yeah, that's right. That's right.

23:18 Scott And yeah,

23:19 Scott I'm going to take a page out of my lazy developer playbook, which is

23:26 Scott Sometimes when there's a thing I need to do and it needs to be more thoroughly fleshed out,

23:31 Scott I will actually intentionally do a very,

23:36 Scott very quick and rough and not ready for primetime first pass on purpose and put it out there.

23:43 Scott just to get just to get the feedback like it's better to spend 10 minutes on it and just get something out there and start getting feedback and feel like i need to spend two hours or two days and then get it out there and still get feedback and so there are moments where i feel like oh god i don't even know what to do here and i'm just like well effort i'm just going to throw something on paper or whatever it is and just put it out there and just see what people say and it's remarkable how effective that is first of all people are glad that they're getting something

24:10 Scott Some people are so good at reacting to things.

24:11 Scott They're glad they're getting something to react to.

24:14 Brad Mm

24:14 Scott And-hmm. it's super helpful for me because I'm like, oh, yeah,

24:17 Scott here's all these things I hadn't considered and it's helped sharpen my thinking. And then usually I can just pound out whatever the thing is because I've got that input.

24:25 Brad You know, it's so funny is I think was it our first real episode out of the gate, not after our sort of like why we call ourselves how many CTOs and introducing ourselves was our interview with Marcelo Calbucci about his PR

24:39 Scott Is it here?

24:40 Brad FAQ book.

24:42 Brad And didn't he say that one of his little magic tricks that he personally uses is even if he's he's labored over something when he sends it.

24:51 Brad Sends it out for review.

24:52 Brad He tells people it's

24:54 Scott Yeah,

24:54 Brad a draft.

24:54 Scott interesting.

24:56 Brad And as you recall,

24:58 Brad if you recall his reasoning behind that hack is there are a class of people who are less likely to give you.

25:07 Brad you know, candid critique if they believe that you will take it personally if you give them candid critique.

25:13 Scott Yeah, or,

25:14 Scott you know, you spend a lot of time on this already.

25:17 Scott I don't want to hurt your feelings,

25:18 Scott that kind of thing.

25:20 Brad Yeah.

25:21 Brad And so it's, that's a, that's a, so these are, I mean, again, like, so,

25:26 Brad so we started this conversation down the whole question of like, how do we get better requirements before building things?

25:34 Brad And it feels to me like what you and I seem to be gravitating towards is, man,

25:42 Brad the more conversations we can have earlier,

25:44 Brad the better.

25:45 Scott For sure. I thought of another cultural thing,

25:47 Scott though. Before we wrap up, can I share the other cultural thing?

25:49 Brad Yeah,

25:50 Brad absolutely.

25:51 Scott You had mentioned the cultural thing is not ready for review.

25:54 Scott I think there's another cultural thing, which is sometimes,

25:58 Scott you know, people bring us the solution they want us to build.

26:01 Scott But they're not totally dialed in on the problem they're trying to solve always.

26:05 Scott I mean, they kind of know the problem they're trying to solve. But now engineers often say,

26:10 Scott well, just give us the problem and we'll find a solution.

26:13 Scott But it's in between,

26:15 Scott right?

26:16 Scott It's like whether

26:17 Brad Yeah, totally.

26:18 Scott it's the product manager or the CEO or the startup or whatever needs to be able to engage with the engineer on both the problem and the solution.

26:28 Scott Right.

26:28 Brad Yeah.

26:28 Scott Like, let's let's not only talk about the solution you brought me and I see that.

26:32 Scott OK,

26:33 Scott go back to my cabinet example from the beginning of the thing, which is, OK,

26:39 Scott the problem you saw was these cabinets were going to have a pinch point.

26:42 Scott What's the what's the problem you guys are trying to solve here? Well,

26:45 Scott this is a corner cabinet and we want to utilize all the space.

26:48 Scott So we're trying we're trying to have one of these pull out.

26:52 Scott kind of lazy Susan kind of things

26:54 Brad Lazy

26:55 Scott and

26:55 Brad Susan thing.

26:55 Scott that's what that's that's that's what we're trying to put there it's not fitting he's like oh okay your problem you're trying to do is solve is trying to maximize the use of this space let's see what so we had to engage in both the problem now that was obviously self-evident because he's a builder and builds kitchens all the time so he knew what we're trying to do but with within software it's that same thing I think

27:17 Scott One of the cultural things is people come to engineering teams just with the solution.

27:24 Scott the engineering teams react and say that react with the pendulum swinging all the way the other way which is just bring us the problem don't bring us the solution but actually it is in the middle it is you got to engage in both the problem and the solution and it reminds me of something i just posted it on linkedin recently i'm just we're would work and we're doing some creative thing and this guy worked with just he just kind of said innovation is messy

27:48 Scott right and that's what it is you got to get in there and just explore these things and it's messy it's not

27:53 Scott linear waterfall like we want you know like we talk about it is you got to talk about the solution the problem the solution the problem maybe go think about it come back iterate on it a few times it's messy yeah

28:03 Brad Yeah.

28:03 Brad And agreed on that. And on the whole point of like, understand your problem before starting to discuss solutions.

28:11 Brad I think that's a that's a there's certainly very good.

28:15 Brad uh wisdom to be found in the do you really understand the problem uh part of the solutioning i agree with you i've seen cases where there's essentially a pendulum swing and a blowback like don't ever bring me solutions only bring me problems right and and um i'll come up with a solution and i agree with you that that's a that's equally an anti-pattern right like

28:37 Scott It's a further anti-pattern.

28:40 Scott I think this is where a lot of that comes from.

28:42 Scott I don't, this is what I say a product manager writes it.

28:45 Scott They might not say it, but implicitly, I don't really know the problem.

28:48 Scott My boss just told me this is what I was supposed to do.

28:51 Scott Someone told me I needed to go put a flux capacitor in the DeLorean.

28:54 Scott So that's what I'm asking you to do is put a flux capacitor in the DeLorean.

28:57 Scott I don't know why. I guess they want the car to go faster. That's what it seems like. I don't know. Right.

29:01 Scott So who

29:04 Brad Yep.

29:04 Scott wants the car to go faster?

29:06 Scott Why do they want to go faster? You know, et cetera, et cetera.

29:08 Brad They want to go faster or do they want to go safer?

29:11 Brad Are you sure they want it faster?

29:13 Brad We

29:13 Scott Well,

29:13 Brad don't know.

29:13 Scott for anybody who doesn't catch the reference I'm talking about,

29:16 Scott it has to do with Back of the Future. Right. And and and and what was the guy's name? The professor.

29:21 Scott whatever he wanted to go back in time was there a reason he wanted to go back in time do we remember why that he wanted to go back in time or did he just want to make a time machine because he thought it was fun

29:31 Brad I think it was just he wanted to make a time machine because he thought it was fun.

29:34 Brad But then it turned into all kinds of trouble when you go back in time, you got the you got the, you know, meet yourself paradox.

29:41 Brad What happens if you meet your parents and break up your break up your mom and dad and you cease to exist?

29:46 Scott Things get very messy.

29:48 Scott So yeah, I think I think part of the problem there is the requester doesn't always know because they've been instructed.

29:55 Brad So think, yes,

29:56 Brad 100 percent that happens.

29:58 Brad Uh,

29:59 Brad and, you know, as long as we're kind of like talking through all the cultural things, right? Like the key here is that as leaders, we want to be able to identify when there are these, you know, cultural impediments to actually,

30:12 Brad you know, making progress in the business objectives and meeting the needs of customers,

30:18 Brad right?

30:18 Brad And then we, so being able to identify them are a pretty important part of that,

30:22 Brad you know, and we should.

30:25 Brad We can't look past the fact that a lot of people's ego is wrapped up in the solutions that they come up with.

30:33 Brad And that can happen on both sides of the equation.

30:36 Brad It can happen in the engineering team. It can happen in the product team.

30:38 Brad And ultimately,

30:40 Brad building software is a team sport.

30:43 Brad We need to encourage people to have a team mentality about it and recognize that the team as a whole deserves the credit for.

30:51 Brad solving customers'

30:53 Brad needs.

30:54 Scott It is truly a team sport.

30:56 Scott Engineering, product,

30:57 Scott design,

30:58 Scott data all have to be working together to make this thing work.

31:01 Brad So there you go.

31:02 Brad Work together,

31:03 Brad people.

31:04 Scott Yeah, I mean, I think the lesson to take from all this is it is a requirement of a cabinet door that it opens.

31:11 Brad did it be able to open it seems obvious but sometimes we got to write down the obvious it's

31:16 Scott All right, Brad, it's been nice talking today.

31:19 Brad been good talking to you this is a good episode remember what do we say kill

31:22 Scott Smash that subscribe button,

31:24 Scott rate and review,

31:26 Scott leave a five-star rating,

31:29 Scott tell all your friends.

31:31 Scott I actually,

31:33 Scott believe it or not,

31:34 Scott This is a little bonus episode on our episode.

31:38 Scott Met my first person in the wild who is a listener of our podcast.

31:44 Brad That you didn't know?

31:46 Scott I didn't really know them. They were they were a friend of a friend.

31:49 Scott And

31:50 Brad Uh

31:50 Scott so

31:50 Brad -huh.

31:50 Scott there was a relationship that they probably that's how probably the algorithms got it in their feed and they clicked on it and thought it was interesting.

31:56 Brad Nice.

31:57 Scott And the person is not a software engineer.

31:59 Scott They're a data scientist analyst type.

32:02 Scott They worked they work at Starbucks. They work on.

32:06 Scott whatever you call labor capacity management basically scheduling people but how to efficiently schedule people in stores and i met this guy and he listens to our podcast

32:15 Brad Nice.

32:16 Brad That's

32:16 Scott so

32:16 Brad cool.

32:16 Scott he's one of the faithful 39 all

32:18 Brad There you go. All right.

32:20 Brad All right. Well,

32:21 Brad next week, we'll have more.

32:23 Scott right bye

32:25 Brad Bye.

32:26 Brad This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigow. Our theme song was AI Generated by Brad.

32:34 Brad Please follow us on all the social media platforms at at HowManyCTOsPod.

32:39 Brad You can find us on YouTube,

32:41 Brad LinkedIn,

32:42 Brad Instagram,

32:43 Brad Facebook,

32:43 Brad Threads, X,

32:44 Brad TikTok,

32:45 Brad and Patreon,

32:46 Brad or at our website at HowManyCTOsPod.com.

32:50 Brad And remember to rate, review,

32:52 Brad and subscribe on the podcast platform of your choice.

32:55 Brad How many CTOs

32:56 Brad Thanks for listening.