Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about what level of abstraction and batch size works best for me when writing code assisted by LLMs.

[00:00:33] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking about common challenges, pitfalls, and opportunities in product development that affect many teams across industries.

[00:00:45] Allan Stewart: Our topic for this episode is whole team solution engineering. So the idea of cross-functional teams is that we have everybody we need on the team in order to ship and build our product. There's no need to wait on people outside the team, but that doesn't mean that you're necessarily working together. How you divide up your responsibilities really matters.

[00:01:07] Dave Adsit: Yeah. So one of the things that the two of us have talked about many times and have used effectively in many organizations that we've worked in is the idea of the double diamond as a strategy for breaking down a problem and solution and finding the right solution. So I was originally introduced to this through the book, the design of everyday things by Don Norman, which I recommend to everyone in product development, but it's been used across product development teams for many years. So one of the things about the double diamond is that it divides the problem identification and selection space from the solution. Identification. And selection space and has those as two separate phases in your problem solution paradigm.

[00:02:02] Allan Stewart: Right. It's called the double diamond, or at least for me, I think about it this way, just because visually you're starting with a problem. And the first thing that you want to do is engage in some divergent thinking about this problem. Say, Hey, what's going on here? What is causing this issue? And people aren't using the product in the way that we think. Is it because of this? Is it because of that? Is it because we need to add some new feature or kind of exploring that problem space before you jump to the thing that that often happens is people just jump to an idea that's like, oh, well, we can just solve it by doing this. The double diamond approach is really about checking those assumptions, slowing down, look before you leap by really exploring that space and and and you start off with divergent thinking, which opens up the first step. And then once you've explored a lot of ideas, then you move into a convergent thinking space where you're saying, okay, out of all these many ideas, which ones can we validate? Which ones make the most sense? Which ones are feasible and work towards figuring out that very specific customer problem that you want to work on?

[00:03:22] Dave Adsit: Well, and the funny thing is. You said it right there, right? Is that what typically happens in product development is that someone shows up with a solution. They say, here's my solution, please build it. And then you have to ask the question. You have to you started in the middle and now you have to go back to the beginning and you say, okay, now that we have your solution, what problem does this actually solve? And once you know what problem they think they're solving, you can walk backwards to the beginning, start with that problem and then explore all the adjacent and related problems in that divergent space, right? You're you're diverging off of the original problem and finding and talking about all of the brainstorming, all of the potential related problems that customers could have. And then you go into your convergent thinking of coming down, narrowing down to is this the one we are going to solve? And I have found with a lot of my teams and a lot of. Times somebody shows up with a solution and then we go back to the problem they're trying to solve. And then we discuss that problem and we go through the brainstorming of the adjacent problems. And then we narrow down to actually solve a different problem than the one that they would have that they originally brought. And then even if it is the same problem, you may not choose to keep the same solution because you're going to go through that same divergent thinking of brainstorming potential solutions. Right. And identifying pros and cons of each and then narrowing back in to pick a solution to implement. And so that's the that is the double diamond, right? That's the divergent thinking on problem narrowing or convergent thinking on selecting a specific problem, divergent thinking on solutions and then converging on to a single solution that the team is going to implement together. And the people involved in that process are going to be. At the very least, your product manager and your lead engineer, but most likely in a in a healthy organization, it's going to be more members of the team, the designer, multiple engineers on the team, maybe the whole team together in some kind of a brainstorming or product session. Yeah. And now that we've got a solution, now we can go implement and execute on that solution.

[00:05:48] Allan Stewart: I like what you're saying there about how when people come with a solution. Already in mind, it's very important to go back and look at the kind of question. What problem are we trying to solve? Because, as you said, oftentimes we find better solutions or adjacent problems that are actually at the core of the issue. And one of the things I've found, even depending on the questioning, like you don't want to skip on that first diamond. Right. Like oftentimes we oftentimes people. Show up with already the solution in mind. They're already at the end of the process, right? Like they skipped both diamonds, but both of them are important. But if, if I had to choose one, I would say that the problem diamond is the most important so much so that sometimes I almost feel like you need a triple diamond in some situations because problems can come at such varied scales. And so. I've participated in some of these where. What we really want as a business outcome. Is a problem that is so abstracted from the product directly that we have to come up with these different ideas, right? We're figuring out like sub problems and converge on which one of those, but then we actually have to explore that problem in earnest, which also takes some time. And we, and we look at it. Very recently, I was doing this with my team. And the thing that we converged on was not. Something that I would have. Expected at all, because we were talking about these different problems we're having in our product and how can we make the user interface better, more intuitive, and how can we have more product led growth and some of those kinds of things we were discussing. And then it turned out that the commonality between a lot of these related adjacent problems. Was the overall shell of our application, like the primary way that pages. Are displayed to the user, like our menu system and stuff like that. Like how, how wide a page is allowed to be, which isn't, that is not the thing that I would have picked. I would not have sat down at the beginning of the meeting. It's like, oh, well, here's the problem. But once we've went through that, that process, we, we discovered it.

[00:08:13] Dave Adsit: Well, and that's fantastic because that allows you to actually, as a team come up with a solution that you are willing to go exercise, execute on and deliver and see if it solves the. Problem. And one of the reasons why it's so critical for me that we have the double diamond in mind is because it frames solutions in terms of a problem. And you might go and try the solution that you guys decided on and work on it, and it might solve the problem that you identified. And it also might not solve the problem that you identified, but the problem is still there, even if your first solution didn't work. And so there's this idea. Of loops in the double diamond method, which is to say, okay, we, we have a problem we want to solve. Now we're going to try a solution and we're going to measure the results of the solution, et cetera. We're going to build it and we're going to execute it and we're going to see what happens. And if it doesn't work, we can loop back either to the notes we took during our ideation and pick a different solution. Maybe it was a different, our number two solution, or maybe we have more information. That we feedback in and we re ideate solutions based on the additional information that we've captured by having a solution fail. And we can do that loop several times until we get a solution that we're actually happy with. We can also, if we fail to solve the problem after several attempts, we can say, Hey, maybe this wasn't the right problem after all, or maybe we are, don't have any good ideas for solving it. Okay. Let's go back further in the process and re ideate solutions or select a different problem to work on. That's in that overall problem space and see if we can solve that problem. So I like that. I like the, the double diamond separates problem and solution and that it provides multiple opportunities for looping back and trying additional solutions, trying adjacent problems until we are. Satisfied. That we've either come up with a good solution and implemented it well, or we've discovered that we are not capable of solving this problem in this space, given our current. New level of skill, technology, and knowledge, whatever. Right. Yeah. And so for me, this is a really powerful strategy for doing product development work because product development work is very often very iterative. And so this gives you iteration points.

[00:10:52] Allan Stewart: The thing you were talking. About earlier about involving everybody in the process is something I think is really important. Coming from the perspective of a coder, right? An engineer or, or even an architect. If I understand the goal, what we're actually trying to achieve, it helps me so much because oftentimes when you are just presented, here is the already baked solution. This is the thing that I want to do. I'll get in there and I won't understand. Because I don't understand the intent. Why are we doing this thing? It can feel. Gigantic. It can feel like, oh, well, this is just like an impossible task that never ends. Or it can feel like I don't. Really understand. What they're trying to get out of it. And as we go through feedback cycles in the design and implementation. They're giving me feedback that I don't have the context to place. Like, well, why are you saying that? It seems like it's coming out of left field. As soon as I understand the problem. Then. then it makes a lot more sense. And then additionally, there are additional options for us to explore, right? I find that sometimes solutions that are created without technical input are not particularly feasible, or sometimes there's just easier ways to do a thing. I've had situations where we'll offer up an alternative solution and they'll say like, oh, we can just do that. I thought about that and I think it's a better idea. I just thought it would be more complicated. And so they didn't want to do it because they thought it was more expensive. And so they chose this alternative thing, which actually would have been a lot more difficult. And so ultimately I feel like this gets us into that idea of the product mindset instead of a project mindset. This is one of those places where I feel like outsourcing work often falls down because you're handing solutions out just in the form of tickets. I want you to do this. I want you to do this. I want you to do this. I want you to do this. And without that context, it's hard for the engineers to have a holistic vision of what they're building. And so they're incentivized to just like plow through each one and add up the garbage code until you get a big ball of mud that doesn't work anymore.

[00:13:08] Dave Adsit: That's right. This is why, I mean, that's actually one of the failure modes for a lot of outsourcing is the feedback takes too long. When you run into problems, you can't go back to selecting a different solution because the necessary people are on a different part of the world at a different continent, whatever. So one of the things that this makes me think of is something we've talked about before. It's a technique that we've used many times in retrospectives, which is the idea of going into the five whys. When somebody brings you a pre-baked solution, how do you get back to the problem that they are trying to solve? And one of the things that you can do is dig into, oh, why do you want this? Okay. It's for this customer. Why do they want it? Okay. What are they trying to accomplish? Why do they want? Why, why, why? And you can use the five whys to get back to the root of the problem so that you understand. And everybody's starting from the same point of we have this problem in the product and we need to come up with a solution for it. This was my solution, which is why I brought you this fully formed solution document. But if we can, as a team, dig back through using that technique of five whys, just keep asking, well, why does that happen? Well, why was that put in place? Well, why did somebody do that? Why is the code like that? And why is this feature implemented in this way? And why was, you know, why did we, I don't know, why did we do this feature at all? If it's causing so many problems, did we not understand what we

[00:14:46] Allan Stewart: were doing? Well, and sometimes those five whys are part of that. Problem discovery, right? We say, Hey, well, we've got this problem. So obviously this is the solution. But when we go back and use a technique like five whys, and I don't think my understanding is there's no particular magic around the number five. It just was catchy to say five whys. The idea of five is just don't stop at two. Yeah. More than one, more than two go a little ways in and say, Oh, well, why are the, why is the customer having this problem? Because sometimes it turns out to be kind of like we mentioned before is, there's something else, there's some other real issue. And the better that you get at identifying those and finding the right issue, building the right thing, you save a lot of money. Yeah. And time. So the other thing I think that's really important about this concept is, is letting teams own their problem space. Again, this kind of goes back to that question of like, are you participating in the process? Or are you just a code, a monkey that take that takes their orders? When you own the problem space is not just the code base that you own, but you own the problem domain, then you can start looking at working together as the team, you are participating in these things, you're having the right discussions that help you build something more effective. I've seen counter examples in my career where teams were really defined, either externally, or I think worse, internally, if they define themselves around a particular feature set, maybe even just a single persona, but they're not thinking about the broader customer problems, then they can really get into a myopic vision where they're not really serving the needs of the company, not even really serving the needs of the customer, but they're serving the needs of the feature set that they used as they identified themselves. That's how they thought about. Who they were as a team and how they work, and it makes it very difficult to change gears and to be agile in the lowercase a agile sense of the word.

[00:17:04] Dave Adsit: Well, if you think about it in terms of evolving technology, one of the technologies that came to mind for me is in automobiles, it used to be very common that automobiles came from the factory with a cassette deck that played cassette tapes. And later it became common for a car to come with a CD player. And if you are the CD player team for Volkswagen, and all you do is build CD players, then you're not thinking about the problem and the solution in terms of what the customer is actually trying to accomplish. You're thinking about it in terms of I build CD players. And so I need to put CD players in this car. Mm-hmm. And the last Volkswagen that I owned had a CD player that was in the glove box and very difficult to access as the driver of the car, but it actually had a USB stick or a USB slot in the dash that you could use to plug in your USB stick full of music. And now my current vehicle that I drive on a daily basis doesn't have even that, nor would I want it because my new car has a cellular signal and it can download music directly from my Spotify playlist and play it directly without me having to go through the intermediary of some kind of media that I plug into the car. And so if I'm focused on the customer problem, which is I want to play music while I drive, now I have evolving solutions that could be part of the product that we ship, which is a car that has a solution for I want to play music when I drive. But if I define myself in terms of a solution, now I become obsolete fairly quickly. I mean, I say fairly quickly, but let's just not talk about how many years it took for those various media technologies to become obsolete. I remember having an eight track player in one of our cars. One of my friends had an eight track player, but he did it as kind of a throwback to the seventies as like he, he went and found one used at a pawn shop. And then it and he installed it himself because he thought it would be kind of cool in a retro type of way. But yeah, so again, that, that goes, that speaks to, as a team, we want to be responsible for a specific problem versus a specific solution. We want to work earlier in that process and have more full ownership over that entire space.

[00:19:39] Allan Stewart: And when you are responsible for the problem and you're thinking along that space, I find that it's often the people closest to the problem that have the best idea how to solve it. It's true. So it's the delegation principle of letting the people who are the boots on the ground make those tactical decisions because they aren't understand what's going on, whether that's in the code or whether that's they're understanding their problem space really well, their customers really well, you get a better outcome.

[00:20:11] Dave Adsit: That's right. And speaking of outcomes, one of the things we've talked about, again, there's the inputs outputs. Outputs outcomes and impacts model of measuring your productivity in software development, right? Those are all, those are four distinct parts of a system phases of a system. If you will, like we can measure inputs, we can measure how much time you're sitting at your desk, how many lines of code you're writing, how many ideas we've generated and put into the system. We can measure outputs, which are, you know, PRS that are shipped and merged features that are released. Yeah. Yeah. Yeah. Yeah. We can measure outcomes, which is the change in user behavior based on the changes to the, to the product. So outcomes in the music player model is like, I no longer buy blank CDs because I don't have anywhere to play them, but I have higher quality music at my fingertips all the time. And then impact, which is, can be considered the business impact or the business outcomes, right? Like how does this change our, our revenue? How does it change retention? How does it change expenses? So if we want to measure at any one of those points, inputs, outputs, outcomes, or impact, then we can effectively measure the team on how they are contributing to the success and health of the business. I like to measure primarily at outcomes. If I had to pick one, I would pick outcomes because outcomes is where we actually change customer behavior and where we can. Can start to see if what we're doing matters to people who buy and use our product. And so obviously you can measure at all of those points. And there are things that I like to measure at each of them. But if you had to pick one, I would like to know, did what we release make our customers more sticky? Did it make them less sticky? Did it make them more likely to use one of the features in our system? Did it make them more likely to upgrade to the next tier or all of these are being framed in terms of like positive customer behaviors from this perspective of the business. But I mean, also negative, which is usually what you're looking for, right? Right. Yeah. Which is what we're, we're, we're trying to drive positive customer behaviors through the development of software typically for us that meets their needs.

[00:22:42] Allan Stewart: And what I like about this is. Yeah. Yeah. It gives it kind of a scientific method flavor to it, right? Each of these solutions that you go out to build is like a hypothesis. We believe that if we do this, we build this thing, we will see a particular change. And when you're thinking about it that way, that you're, you're thinking about experimenting, then it leads you to want to measure and it leads you to think about what is it that I'm going to measure? Even before I've finished building it so that you can, you can say, Hey, did it work? Did we get the outcome that we want? Because otherwise we're just kind of spraying the world with stuff. And sometimes like there's some things that the measurement is, well, we need some kind of a feature parody perhaps, right? Like people need to be able to log into your website. That's the kind of thing that almost every product has. Some account and you can log into your account, but nobody cares about like, nobody's worried about that because it's not distinguishing. It's not, you know, you from, from others, right? It's not differentiating, but it's table stakes. So for some of those things, maybe, you know, checking the box is good enough because if, if you don't do that, you know, you're not going to get off the ground probably. And then somebody comes along and challenges one of those assumptions. And sometimes it turns out that's not actually true. And so if you're really measuring, what it is, what's your hypothesis, what do you think is going to happen? And you've identified that and you figured out how you're going to measure it. Then you go and build the thing and you can know that it actually worked or didn't work. Because sometimes that's just as important. If we're shipping out things that are causing negative impact and we're not measuring, we'll just keep adding to the slot pile and eventually you lose customers that way.

[00:24:41] Dave Adsit: Right. Well, and I, I like how the, the inputs outputs outcomes and impact overlays really well with the double diamond of problem followed by solution, which is that we can have the same types of loop backs. Like we had our input, which was a problem we were going to solve. And our output was the solution that we built. And now we're going to measure the outcome and measure the impact. And we're going to see if this was the right solution. And we can then go back and try something new each time. Or maybe the input is the solution we decided to implement and the outcome and the output is the code that we shipped to do that. These two models for thinking about product development work really well together because they both have the idea of distinct points where we can measure and then move, go backwards if we fail to accomplish what we wanted with them.

[00:25:39] Allan Stewart: So there are a lot of ways that you can work together. The, the double diamond is a way I don't feel particularly dogmatic about it, but it helps me like even just kind of visually, I think about, okay, well there's a diverge and converge and almost as a symbol of, or like a, like a visual mnemonic of how I want to work. But there are lots of different ways to work. And I think the important thing in our conversation here is really about how are we working together? How are we bringing those whole teams together to think about the solution to problems and not just, build solutions, but understand what you're trying to accomplish. What is the problem that you are solving? Not just taking the Jira ticket of the day and implementing it, but really understanding how can we work together as a team to help each other to find the best solutions that deliver the best value for our customer.