David Pereira is a Product Leader who over the last few years has led product teams to achieve exponential marketplace growth: from 5M € to 45M € revenue per year. Not only this he led product teams to discover solutions to innovate the second hand car market in Brazil, creating a business with a turn over of 200M USD per year.
🎙️ Welcome back to another episode of the Product Agility Podcast!
In this episode, David and I discuss the misconceptions about technical debt and explore could it even benefit the product and the team?
🔍David shares his insights on how to address emotional debt within teams and the power of retrospectives in improving collaboration.
🔥 Throughout our conversation, we uncover the dangers of scaling up mediocre solutions, the importance of honest communication, and the power of collaboration over dogmatism. 🤝
So, if you're curious about how emotional debt impacts our behavior in the workplace and want to gain practical tips and strategies from a true thought leader, this episode is a must-listen! 🎉
📝 If you enjoy this episode, please share it with a friend or colleague who could benefit from our discussion.
Chapters:
Host Bio
Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.
Stay up-to-date with us on our social media📱!
Ben Maynard
Product Agility Podcast
Listen & Share On Spotify & iTunes
Want to come on the podcast?
Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80
David Pereira is a Product Leader who over the last few years has led product teams to achieve exponential marketplace growth: from 5M € to 45M € revenue per year. Not only this he led product teams to discover solutions to innovate the second hand car market in Brazil, creating a business with a turn over of 200M USD per year.
🎙️ Welcome back to another episode of the Product Agility Podcast!
In this episode, David and I discuss the misconceptions about technical debt and explore could it even benefit the product and the team?
🔍David shares his insights on how to address emotional debt within teams and the power of retrospectives in improving collaboration.
🔥 Throughout our conversation, we uncover the dangers of scaling up mediocre solutions, the importance of honest communication, and the power of collaboration over dogmatism. 🤝
So, if you're curious about how emotional debt impacts our behavior in the workplace and want to gain practical tips and strategies from a true thought leader, this episode is a must-listen! 🎉
📝 If you enjoy this episode, please share it with a friend or colleague who could benefit from our discussion.
Chapters:
Host Bio
Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.
Stay up-to-date with us on our social media📱!
Ben Maynard
Product Agility Podcast
Listen & Share On Spotify & iTunes
Want to come on the podcast?
Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80
You need to understand what that encode that is and what it is for. Because the problem I see is saying that technical debt is always bad and not understanding why technical debt is created can be in different reasons. But assuming that we create technical debt because we are all bad and we cannot solve it is wrong because for example, look at the tools you have on, on the shelves, you may have a hammer there, hammer has some purpose. But if you give that to a five year old, then you have a big problem because everything is going to become a NAO welcome to the product podcast. The missing link between a and product purpose of this podcast is to share practical tips, strategies and stories from world class, thought leaders and practitioners. Hi, I hear you. I want to increase your knowledge and your motivation to experiment so it we can create ever more successful. My name is Ben and I'm your host. What has driven me for the last decade to bridge the gap between agility and the product is a absolutely and products evolving together can achieve mutual. And in this episode, we Welcome back, David and I'm David. My owner have a wealth of experience helping to build huge sizes. He's also got a massive social media following. Why you may ask? Well, because he's pretty bloody good at what he does. Now, in this conversation, the second of two, we explore in particular technical debt. We look at the eating habits of my son and when is it ever right to bite off more than you can chew. So please enjoy this episode. Make sure you recommend it to someone and just a 60 degree direction towards and our listeners will skyrocket and we'll get the best people anyway, that's enough. Enjoy the episode. Here we are again, second episode with David, which I maybe did the worst job at, at that time. Sorry, David, I'm really trying today. It's been a long weekend. Um, here with David and we've been talking about things relating to jobs last time and how sometimes the job we are hard to do isn't the job we are able to do in an organization that was episode one. And during episode one, what first of all, David gave an introduction to himself. So I'd recommend listening to episode one or checking out the show notes because time is of the essence and I don't think we should bother doing introductions again this time around second point. During the first conversation, we touched upon a very sensitive topic, technical debt and I wondered perhaps then we could have a conversation around the future of debt and perhaps not just technical but other forms of debt too. And so I would like to start this conversation by saying David, I think that the war on technical debt has been lost and that people need to accept this and move on. What are your thoughts on that? David? It's very strong thought and I can't agree to you because you need to understand what that code is and what it is for. Because the problem I see is saying that technical debt is always bad and not understanding why technical debt is created can be in different reasons. But assuming that we create technical debt because we are all bad and we cannot solve it is wrong. Because for example, if you look at the tools you have on on the shelves, you have, you may have a hammer there. Hummer has some purpose. But depending on if you give that to a five year old, then you have a big problem because everything is gonna become a nail, then you have everything broken on your house, that's not what you want. And I say that technical that is a tool that can help you if you know how to use it. But now it happened in kind of a war and then there's the product manager trying to turn a blind eye to that and trying to block soft engineers, soft engineers, getting peace with that. And then all that kind of that. But we can turn this around technical debt when it was first conceived, I believe was a conscious decision. And I think describing it as a tool when it is a conscious decision is a really interesting take on it. I think perhaps a what a lot of the issue is that organizations find is that actually technical debt was never a conscious decision. It was just part of their learning and part of their evolution as a, as an organization. But they did things in a less skillful way than perhaps they would have liked to have done. But it wasn't a conscious choice. It was an unconscious thing based upon where they were at a point in time. So II, I love the idea of using technical debt as a conscious decision to let's say, cut a corner to test something. But I want to draw a distinction between that and maybe people just kind of learning as they go and then ending up with software, which perhaps they would have never have chosen to have designed or implemented in that way. That's quite interesting because yeah, people create technical data in different ways. One can be the lack of skills that will create technical data. But how you deal with that is the most important aspect because one of the common approach which for me is the most uh like disrespectful to the matter I would say is let's invest 20% of our time dealing with technical debt. This is saying like whatever fits 20% which we all know we are bad at estimating, then we whatever fits 20% we do, we do with that. I would say if this is very important, let's say our legacy is bad and this is getting in the way of scaling for example, or getting in the way of reaching our next objective. Let's step back, focus and change it for the better right now. Let's focus on it because what I dislike is this thing of uh yeah, you know, it's just the ugly duck. No one wants to touch it and we touch it when we can. And this when we can is a problem. Hm I mean, that kind of like giving the 20% time then like, I know a lot of the time it's not gonna magically make people more skillful or, or, you know, and, and, and it's never gonna, it's never gonna Trump getting stuff done, right? When someone's breathing, like you just have to get it done. Um And actually moving back to the last conversation we had, you were talking about maybe not explicit about this but mentioning around our confidence in a product decision, our confidence in something that we want to create. And that actually one of the best ways to increase our confidence is to get it in the hands of the users or customers to let us know whether or not it's going to work or to get it to a specific segment to test whether it's gonna work. And actually gut feel is something we should have a lowest confidence in. Actually having it in the user's hands is something we should have the higher confidence in. And so then what we're saying here is that actually that even though we may be cutting a corner to get it to the customers hands to increase our confidence, if you are going to do that would be, would there be any other corners that you would cut other than from a technical implementation perspective? I'm thinking UX or anything else? Yes, I think what we would have to cut some corners because let's say in the beginning of any idea, it is an idea, you don't know whether that's gonna work. And the challenge is statistically nine out of 10 ideas will fail. And the question is how fast do you drop the bad ones? And then learning is of essence, the speed you can learn. And for me is a following start experiments, small, a small with interview, something that takes minutes, not even hours, do something that to learn and check the direction and then you go to something that will take a couple of hours like a small prototype and you increase it, then it will come to the moment you want to get to the hands of user, but you don't want that to be perfect because it will take perfect. It will take a while and you say what is the fastest way to test some of the assumptions? And that is the magic. You need to know what you are testing because if you say I'm testing everything, then you are not testing anything. So you need to know exactly. And then you build the like, let's say the fastest hack you can create that includes use bill that design that technical data to test your assumption. And I say test because it's not validation. I don't want people to fall into confirmation bias. I want them to learn if it stands true or not. And then you test it. And then after that, you can make a better informed decision saying, well, actually the assumption was right. Here's the evidence. Then you say what if now we test the other assumptions we had or maybe you say now we are ready to build it right? Then you say time to pay the debt off and that is the moment bad decisions are generally made. One of the examples would be, oh, this solution is good enough, you know, it's a little bit ugly and so on, but people can get the job done. Let's just scale this to 100% of our audience instead of 2%. And then it's for sure, software engineers, UX designers, everyone will go mad because they will say that's not what I want and these are the, where the, a lot of the problem comes from is that you get something out there, you test it. It seems like a good idea from what you can tell. It increases your confidence in which to proceed. But unless there is and who knows, maybe somebody thinks, you know what we can get it out there and the world won't stop spinning on its axis. You know, it won't start raining frogs or anything that actually do. You know, some of these little things, getting them out there and trying to scale them up could be interesting. Maybe sometimes it'll work. But generally speaking, once you've proven something and you need to scale it, there's gonna be work that needs to be done. And perhaps some of the mentality is saying that actually then that's, that's part of how we work. We test it. If it's valuable. If we have confidence, then the next stage is to then do it properly and you get more money to then carry on once, you know, it's a good idea. But then it's that expectation, isn't it? It's not having people who have made promises on deadlines. And they said, well, we're gonna have a, have a pilot out, having some kind of prototype out and then that's the promise and it's done and they think you can move on to the next thing. And actually, no, there is a lag time, there's a lead time to actually making that thing that you've tested worthwhile. And this is what I was talking to my client about this morning. Uh was this idea of a promise cycles and that if you want to make uh a real significant change in an organization and you, and you're looking at the promises that your senior leadership are making, you need to wait for a cycle or two promises to finish, finish before they can start making new promises which are better aligned to the way that you want to work. So in that instance, it would be a case of not promising that it's done when the prototype is out and we have confidence, it's promising that. Yeah, but we're gonna run this experiment. We're gonna learn and at that point, then we're gonna see if we release more funds when more funds available to then make it into something which can scale and can see a larger return on investment. Yes, it is like buying a house, right? You get a mortgage. So it's a shortcut to get access to the full value of it. So you get a house but you have a mortgage. And what if you want to get another house? If nothing change, you have to pay the tax, uh you have to pay the debt off or you get a second house and then you go bankrupt because most probably you cannot pay both house together. That's what happens with, with product. I like saying if we don't pay the debt timely, we go bankrupt because then that will scale you away that no one wants to work in the product any longer that we cannot plug new things there fast enough. And then it gets complicated because we decided not to pay our mortgage. Hm If you there's a video on youtube of Ward Cunningham and I think it is Ward that came up with the idea of technical debt. They say Ward like he's a friend, never met the guy Mr Cunningham. There's a video of Mr Ward Cunningham on the internet on youtube talking about technical debt. He says exactly that it's a culture decision to get into debt because we, we need something we can't quite afford right now, but we need it for whatever reason to test or because of a promise, whatever it might be. And then at some point when we go into debt, we know that we have to pay it back otherwise we'll go bankrupt. And I think then that's the issue here, isn't it? It's people aren't treating it like debt. So my saying the war on technical debt is dead. I I think that in many respects it is, but I think that the future of debt, then there's perhaps a more a healthier relationship with it, seeing it as a necessity rather than the root of all evil and drawing a clear distinction between unskillful or yeah, I'll say unskillful software development versus making that conscious decision. Yeah, it's a conscious con uh conscious decision on how we use it and how we pay it. Because what is detrimental to digital product development is a lack of focus because this will increase contact switching. And we all know what happens when it increase that we become less productive and also our quality decreases and everything starts going in the suboptimal way which no one wants, but that becomes a byproduct. So I miss more alignment into teams because also there's a fear for example, many product managers try introducing this but then they will face developers unwelcoming that the reason is simple. Developers had bad experience with this and they are resistant. I had this situation when I first came very excited about accelerating technical data to speed up learning. Software engineer said no way I'm gonna go that I'm gonna go that that way simple because we built high quality code. And I said, I understand you do that. But why would you build high quality code for something? We are uncertain. Then the software engineer, a team leader and said because I want to use that as a moment to learn and then then our team members will have the chance of learning how to do it correctly from the beginning. But these will get in the way of business because it's too is low and we will create a lot of waste before we create value. Then a software engineer together with the team, need all of them. Look at me and said, yeah, you come with this beautiful speech, but the moment we have to pay it off, you run away, you push another feature, you want something else. They find that so funny. But then this is where it's, it's, it's everyone, isn't it? It's that, um, it's the behavior changes and it's being able to make the right promises and being able to own the consequences and have the hard conversations with people. And, and before we started recording, I spoke about this idea of uh emotional debt, which I, you know, now that I gotta think on it a little bit more. And for those of you that obviously had no idea what I've been talking about when I mentioned emotional debt, I'm talking about the, as I describe it, the invisible rucksack of all the different wounds and experiences that we collect in our journey through life and through organizations. And often when we turn up to a heated conversation to our high stakes conversation that people, we arrive and people can see our invisible backpacks and they kind of guess how we're gonna behave and what we're gonna bring up. But whilst I still stand by that as a metaphor, I wouldn't say that's emotional debt because I don't think that, well, if I, if I drew it as an analogy, that's more like the, the unskillful work building up because we didn't know we were unskillful. Right. That's like coming down off a Mount Sten and being like, wow, ok. Um, you know, a very old friend of mine who, um, like, all good astrophysicists is now a programmer. Um, you know, when I was talking to him, he said it, the software that I wrote two years ago, I look back at that and I'm just dumbfounded why I wrote it like that. It just makes no sense. I've learned so much and that wasn't kind of conscious complexity. It's accidental complexity that I added into the system, which I think is what uh Fred Brooks drew from Aristotle in relation to complexity in code base. So I think that emotional backpack is more like the accidental complexity we build up, we go and things. It isn't like we consciously decide to cut corners and be a dick that kind of sticks to it, which is what we're saying with technical debt. Yeah, it's quite interesting. Yeah. When you said about code written two years ago, it's been some time I don't write any code already more than a decade, I guess. But I write a lot of blog posts and sometimes I dare looking at the blog posts I wrote one year ago and I look at that and say, oh my God, that's so embarrassing. But, you know, that was the best I could do back then. And I look at now I say that means evolution. I, I guess I became a bit better, at least. So I, I recognise what happened but I don't go to my old post and I start factoring everything just for the sake of refectory. That's not what I'm about to do. But when it comes to the emotional debt, I think if we don't address this with teams, we cannot function because imagine there are open conflicts there, but they are just not on the table and there are some frustrations that people are just not naming them. And until they talk about these things, there will be frictions and this is not gonna be helpful. Although I am from the from the product side, I am a big fan of retrospectives and I like moderating them sometimes this to get people to speak up and then we take action. One of the things I like doing is having a retrospective like looking at our previous action, what made you happy, sad and mad just talk about it and then we get to know and take action upon it. I also like to look into collaboration. I say in terms of collaboration, who you are happy with, who you are? Hm Not OK. And who are you angry with during the last print? And let's talk about it. So I create this room and I gen generally try giving the example. I open the room, I give positive feedback to the others. I say what I didn't like. And sometimes I even give negative feedback to me because I say I was not happy with me with this thing here than the others are doing. And if they see it's a wrong that it's safe to say that you start saying more and then the team becomes a better team. It's hard for people to speak up though. It's hard for, to create those spaces at times. It really is. And I wonder if, you know, sometimes refracturing our teamwork or refracturing our emotions. Yeah, it's or even refracturing a code base, right? To remove some of the um conscious or accidental debt, which we have accumulated over time. The one thing that I don't often see people maybe putting enough thought into is then the frequency at which that pro that area of debt will affect us. You know, if I have an emotional trigger over people wearing purple and yellow on a Tuesday between the hours of one and four, then maybe not worth kind of spending time refracturing that because it's gonna happen. So infrequently that people can probably put up with me when it happens if we have a part of the system which has got the UX isn't great. But as a proportion of our users, it's like 1 2% of our users and we've got other things actually, which are higher priority. Then why would you bother refactoring the thing which is, you know, isn't optimal for a very low percentage of eight users. We we wouldn't bother, we would prioritize something which has a higher touch rate in the same way of K basis. And you mentioned this earlier as well to me and why, why we factor a piece of the code because it is a little bit out of date and we need it to, to look better or take on board some new, some new approaches or it needs to be more elegant, better wrap in tests if no one ever changes it or it gets very rarely changed. So maybe it is the future of debt, a healthier understanding that the frequency at which we need to touch the thing which has the debt should drive our conversations around how best to resolve it to pay it back. Yeah, I think that the conversation is the key of everything because what matters in the end is the collaboration with people sometimes go to this philosophical saying, for example, some software engineers tend to define uh to defend the technical debt with the car analysis saying software is like a car, you need to replace oil, you need to change tires, you need to change the brakes. Otherwise the car is gonna break. I say, well, I disagree just a bit with that because a car is mechanical. So there is a spare part and it has a lifetime. A software is a set of complex things. And if the environment doesn't change, the software will still work, you just look at the bank. Some things were created like three or four decades ago and they still work. It's a bit crazy but still work. And what I say is if something change, we have to look there and then talk about it. So for example, are we scaling to a, a level, the current structure doesn't support, let's talk about it. Are we adding different rules or complexity? The example I gave was the invoice, a soft engineer told me we have to factor the invoice system. And for that, I need at least two months because it's a massive code. I said OK. I'm in this company for 1.5 year and there was no single need of changing the invoice system. You are here for four years. When was the last change request? And then he looked at me never, but the code is a spaghetti code and I hate it and it needs to be a clean code. He opened the code and showed me their methods here with 100 50 lines and according to clean code should be five lines. I said, OK. But let me ask you the tricky question, what would happen if we don't do anything that you say? Then he stayed quiet for a while. He looked at me. Well, another developer would not like to work on this code as I wouldn't like either. I said, but if the code hasn't changed over the last four years, it means you have, you haven't worked on the code anyway. And then he looked at me. Yeah, you're right. I haven't, I just don't like it said, Factor for the sake of refactoring is not a good excuse. It's not, uh, I said I cannot sell that to anyone. How can I say that we are using a highly qualified professional for a long time to reflect or something that has no change and makes no improvement. Said? Well, all right. Then I said, let's make an agreement between you and me. The moment I come with a brilliant idea to change the invoice system. I put that on the package, you factor everything. Is that fair enough? That's a good point. Yeah, the code was never a factor. I left the company at, after some point in time and I still talk to people who are there and nobody touched that because the invoice system in Germany didn't change. But, but I mean, you come, you can't knock people's passion right to, to fix something like that. I mean, you must have those situations in your life where you look at the thing. You're like, I know this isn't a good way of spending my time. But oh God, I really want to fix it or I really want to make that a little bit better. You know, that, that's a, that's a great quality to have granted. Maybe we need to direct it a little bit, but it's that's a wonderful quality to have in a, in people you work with that passion to wanna make stuff better. That's AAA great point. It's being proactive. I like that. But then as you said, you need to direct because I could deal if the person would tell me I need to reflect on this and it's gonna take 2 to 3 days, I would say go for it. But the person told me it would take uh 1 to 2 months and I know when we are estimating somewhere between 1 to 2, it means we have no idea. Yeah. Yeah. So that, that I couldn't defend. So, uh I said, I appreciate but how can we move on? I can. And then, and for other occasions, this person didn't ask for, for permission because then I said, inside the print, we have a goal and once we reach the goal, I don't care what you do. So we have a commitment on the goal, we agree on that. So within the rest of time, you have, if you want to reflect your code, pay off technical debt, fix bugs or try out something, just do it, go for it. But if you're gonna sell something that is consum considerable time, we need to talk more. It's a funny old game, isn't it? And it's because I say, and I say that because, you know, I think me and you maybe we had a chat about this before but and maybe let's see if we can relate this to the, the idea of debt as well. This is one of my favorite topics like team level product ownership or product owners that are really involved in all the detail like the example you provided then is that you gathered, you garnered, you gathered, collected a certain amount of respect from this person who's on the team because you didn't get involved in the detail, particularly you just drove to step the right direction and offered something which was a compromise but still played to your strength as someone setting direction and their strength is someone who is creating the software, creating the product. Now, I think that my guess is and I haven't, I said it's a guess because I haven't really put any thought into it other than now. But if you are a lower level product owner, you are involved at a team level and involved in all the refinement. If someone comes to you with a problem like that saying, this is very hard to work with, I could never work with this. If I touch it, I break it and it's a nightmare. And if you're involved in the nitty gritty detail, would you be more inclined to maybe uh have those conversations and entertain the idea that work should be done? It's quite interesting. I've entertained this idea already. So this was after some experience once in Brazil, I had a similar situation. The person wanted to factor another part of the code and was so excited about it. And I had just moved into product management. I bought it here and the three weeks soon turned out to be two months and then I, I had some trouble. So we had to have a conversation. Like I said, you know, we had, you told me you wanted to reflect her, I appreciated that. So we made it possible I could sell the prioritization. It would make the the product higher quality. But you told me three weeks and now it's taking two months and I'm having a problem. So I always say the problem belongs to all of us. We are in it together. But if you tell me three weeks, I don't expect two months because that is, it is complicated. Then we had to talk. And I said, what about next time? We're gonna go for a factor. We do that in a more digestible size. So let's start small and see how it goes. So my learning back then was you need to have a cake that you can chew. So not to put everything on your mouth that you cannot chew. I've just got mental images. My boy, Adam, my youngest boy and one day he would one day he will listen to this and be like dad, you're such an arsehole. Like the honestly, I make pancakes every weekend and this boy he will, he will sit down and I should really bring him up. I only, I'm only mentioning this because I said my wife doesn't listen to these because if she knew that I just got to let this happen and she would be annoyed, but he will sit down with the pancake and this is a good one if you watching this on youtube and he sits in the pancake like I pushes it all in to the point where you can't speak. I'm like, yes, like that's like that's the, that's why you need to break things down to bite size pieces, right? That's why a refinement of your pancake is, is important. And if you cut your pancake into smaller pieces and then you could have a choice of toppings on each piece of the pancake. If you wanted to add them, you don't have to shove it all in your mouth all at once. So with my lovely son Adam in my mind and him, his cheeks full of pancake. Is there such, oh I was gonna say, is there such a thing? I'm gonna check out a little hypotheses. I'd love to hear your opinion. David uh Technical debt builds up slowly over time and then bites us in the arse after a certain amount of elapsed time. And that the the gradual contribution to V tech debt either consciously or unconsciously is done by a wide array of actors over time. And then it gets to a certain point where it bites us and we're like, oh perhaps we should fix this. So there's a big delay in cause and effect refinement debt. So not refining something properly, not understanding the user problem properly. Like not being able to like that type of debt refinement debt. I propose as a much shorter cycle time before you feel the effect and thus is easier to fix. What do you say? Well, the shorter the cycle time, the easier to fix this become the short time between yeah, between cause and effect. Yes, exactly. Because the the biggest problem of technical that I see is very simple. We don't have a strategy to deal with that. So it's, as you said, it's something that we create and then it will buy us and we have to do that. But if we instead of putting a band aid on the problem and say, yeah, let's invest 20% of our time to fix that. We say no, we have a strategy when we create mindfully how we fix it or how we drop the whole functionality at all together with the technical that created. So I think it is about reducing the cycle time and also having a strategy because it's very, it is very connected to what we talked last time. Solution orientation. Today's investment per sprint is a solution. Is it a good one or not? You need to know which problem you're trying to solve. So what is this strategy? To solve the technical data? And how do you diminish that? For example, if you are creating technical data because of a poor software quality, what about uh leveling up your software engineers? It goes to usability and the others of the same. Then when it comes to refinement, what happens in a refinement session? Are we talking purely about solutions or are we talking about the problems we want to solve? That's a different set of things because then you will eventually understand how you solve the problem and how you use the technical data in your favor in your experience. From your years of being a senior product person. If you had to give some tips to other product professionals, aspiring product professionals or people that support them in how then to deal with this, you mentioned some strategies and we've spoken about a number of different things. We've, yeah, it's been brilliant. I've really, I've really enjoyed going through this. I feel like we can get them for a little bit longer. So I'm not saying we wrap this up, but I'm wondering if you had to give some tips, some top tips into how we can deal with this debt in a strategic way as product people, David, what would you suggest? And to just knowing what is the goal you are pursuing and then finding the best alternative for that. So if the goal is learning, I would say that building right from the beginning it's a low alternative. It will take a while to learn. But if your goal is to scale building wrong in the beginning, that will ensure you don't scale at all. So you need to understand what is your ultimate goal and then you find a way of getting there as fast as possible. He presented two extremes there, I suppose, like two different sizes, a coin. Is it fair to say that for most? it's somewhere in it's, well, it's being able to adapt, but it's somewhere in between those things. Yeah, for, for most, I would say it's the idea uh testing. So is this idea going to create the desired outcome? That's the very first thing most of the case, I would even dare saying this is 70 to 8%. And what tends to happen is we go wild, we build the solution correctly from the beginning scale to 100% of the audience and say that's it. And then we realize nobody use and we don't know why. But then we are not brave enough to remove that from the product. And the other extreme is when we started um a small wave idea and we started drawing our audience. Let's say we build a product that is scalable for up to 10,000 users. And then we realize we're going faster and now we need 100,000 users. So that is a different side of the coin. And if you're building for 100,000, a solution for 1000 is not gonna work. So you need to change it. But I think the the most important part is knowing the goal le is learning the goal then technical data is a good tool for that. It can then can help you get to your goal of learning faster. But if your goal is scaling to more users, then creating more technical data tend to be a bad choice if only if only it was that simple for people, right? But I'm guessing that then what we end up in is a situation. And I know I've been there as a, as a product owner, I've been there as a or someone who's working on a, on a product at the moment. Me and my partner have many conversations about, is this, is this a corner we should cut or is this just part of our process of learning? And actually this may feel like a wasteful thing to do and we may end up having to redo this. But it's part of us figuring out how this user journey should work or how, how it should feel for people when they're using the product. And these, you know, these are conversations which we will always have to find compromises for. I'm wondering, have you ever found yourself in those situations? Are you having to talk to more senior people in the organization or talk to somebody that holds the budget or something similar where you're saying, you know, it's gonna be hard because we have this debt to pay back or we're not gonna, you know, we're gonna do this, which result in us learning and then we're gonna have to pay the debt back. Have you found yourself in those uh crucial compromise conversations at any point? Yeah, several times. And I generally get myself there with the conversation of how much does it cost to do this? And I and I, I have another question to you, how much budget do you have to invest into this? Because he said, then we can have a better conversation. He said, because this can cost as much as you imagine. It depends how, how far we go into this. And then I say, if you give us the limitation, let's say that the budget, the available budget would cover a month of work. Then what do we have to do internally? Say like we have a month of work to get this idea to 100% of our users working backwards? What we need to do to enable that possible? Then we can figure out there's some technical data and so on and blah, blah, blah, then you come to the situation that is not doable in one month. Then I will just go back and say most probably to a month, we won't get to the result ex expect to the expected result because there are some technical debt on the way that will make it more complicated, we will need more time and I say challenge is technical debt solving from legacy is unpredictable. We may think we get it solved in one week but might get in the way and might take two weeks or three weeks. For example, the of course, I would name that a general tri picturing saying it's like a box, you know, you can only fit certain amount of things and if you put more, the box will collapse. So we need to make the boxes stronger. And so some uh senior managers would say I don't care, make it possible. I would say no, I cannot lie to you. I may say we can make it possible but I would be lying. So I try having an honest conversation, say I'm just doing my best to show you what can be achieved and what cannot and you decide if you want to make a bet or not. It can be that to invest this amount of budget and we won't get anything done, but we will get a lot of learning and we can share the learnings and you decide if you want to invest more, that's what the budget can get this better information to decide whether to invest more or not. Sometimes, but sometimes we may say hm which is very unlikely, but the budget is way too big for what you want to achieve. You know, that doesn't happen if only honestly, if we have so much money left over, you have so much money left over if you do this. So um yeah, never have. I had that conversation. I do remember the conversation where they read a budget of 13 million to deliver a replacement platform and they said they wanted it for 100% of the customers in. It was like within, within a year or 18 months or 15 months. I think it was in the end and we spent a lot of time like a week because we had a, we had a great team with some great people and we were able to get enough of the right uh experts and senior people involved and really tried to understand, ok, what do we think is possible then in the time frame that we have and what was possible was about 1% of the users and that did not go down. Well, you know, and then they say, well, in that case, well, let's speed up, let's give you some more people. So they, they, we push back and ends up giving us like two or three more teams. And it was a shit show. It ended up costing, I think nearly 50 million in the end. And it was just, it was just horrific. And what was interesting was that I remember I got asked to join some, another part of the organization because they were like, look, you know, this is, your skills are wasted here. It's going, it's going a certain direction and you can't, you can't change that now. But I stayed really close to the people involved in it. And I did get to that point where the one of the senior technology managers was asking the team, how do you speed up? Like, let me come and sit with you and watch what you're doing so I can figure out where you can save some time and then watch them doing uh like acceptance test driven development. So, you know, putting to acceptance tests into a testing framework, making sure they failed and then coding enough until the acceptance test passed in a in a test framework. You know, that's a waste of time. Stop doing that. Like just stop doing that. It's fine. We'll fix all that in UAT. So when they say stop doing it and they got to U 18 and it went horribly wrong. He was like, oh, we need to fix, we need to fix this. What can we do? Like, well, automated testing. He's like, well, I want you to go back and rewrite well, re write all the automated tests, ex acceptance tests for all the stuff you've done since I like that isn't gonna work, you know, and it was just a very, very sad story of a situation where there wasn't any, there wasn't a sensible conversation to be had about what was achievable in the time frame which just led to huge amount of technical debt being built up and then a wish at the end. But it wasn't that way, which of course didn't help anybody. It's about having the honest conversation, right? You need to say what is realistic and what is not and then decide where to go. But there is this thing of we increase the size of the development team and we expect to get more output. Well, there is this sentence, everyone knows nine women cannot make a baby in one month. And the same applies to soft engineering. Actually, if you put more people, it will slow down in the beginning. Yeah, it will take a while. And the more complex the situation is that the, the main, the longer it takes to ramp up people and for every new soft engineer, you need an order to help other person ramp up. Hm I think that relative relative speed, so relative to what you could achieve, it is always faster. If there's high alignment on what you're doing and why you're doing it. And when you add more people to the pool of people, you dilute that alignment. And that shared understanding of why you're doing it and how you wish to do it as well as then you have different levels of capability inserted into the system. It's always going to be an incredibly hard challenge to be anything but slower. If you're gonna dust a load more people into something and it's gonna be very hard then to not to end up with either some level of accidental technical debt or a huge amount of philosophical debate as to which type of uh principles we should be following? Or is this even the right technology to be using? And, and that again, just takes time and facilitation to for people to actually then align and create that new shared understanding. Now, David, we are kind of getting towards the end of our time, sadly. Um And yeah, how I would love her to have done this in person. I feel it's been a great conversation and we put some really good points and there's so much more I thought we could go into. Uh but I wanted to loop back around to the beginning of this episode with my, what I stand by which is it the war on technical debt is dead? I think we need to stop seeing this as a battle because there's always gonna be some level of intentional or accidental technical debt. So if we were gonna change the narrative, change the story on this, David, what do you think could be a suitable alternative term for technical debt? Everyone is on the same boat. So we need to talk about it and stop the conversation like o versus then I see a lot of software engineers versus product managers, product managers versus UX designers. No, we have to get a job done. How can we best use our skills to get it done and let's not stick to our guns all the time. And open up to product managers will make mistakes and you know, create an atmosphere where feedback is welcome. Show vulnerabilities. I think soft engineers. I love when they tell me, hey, Dave, did you did something bad there, you promised and now you, you didn't stick to that, then we talk about it and we solve it. So instead of saying like, yeah, technical. That is bad. We don't do this and so on. No, we're on the same boat. We want to get there. How do we get there together? Oh, maybe that's good. So let's have a conversation instead of being dogmatic. Mm And then maybe we don't call it technical debt and maybe it's just food, technical journey. I don't know exactly because I can't think of any, any product, well, any product client or work I've been involved directly, which has never resulted in any form of debt. It just seems to be the journey that we go on. Accidental intentional or otherwise. That's just a journey. It's just a journey. It's just a journey. That's it. I can only agree to that. I, I have seen some teams panicking with bugs. It's very similar to the technical discussion saying we have to fix. There's a bug, I say, wait, wait, wait, there are different types of bugs. You need to software has bugs. That's it. So is it first get in the way of delivering on the value proposition? No. Ok. How many customers are being packed? Um, only the ones using maybe Kindle. So. Oh, ok. So that might be zero, that's 0 1% of, of people who decided to browse their own Kindle. So maybe we just don't care about it. It's fine to say that I think it was and I don't know how true this is, but I heard it was Martin Fowler when they were writing the AA Manifesto, when asked about documentation said that we should document anything where the need is immediate and significant. And I think the same is true for bugs. If fixing the the need for fixing it is immediate and significant, then let's do it. If not ben, it should get relatively ordered against the other work we have to do. Yeah, that's so true. On that note, David. Uh I wanted to thank you from the bottom of my heart for coming along and having these conversations with me. It's been a pleasure to get to know you a little bit better and I really hope that we can do this in person one day because I've got a funny feeling we can have a bit of fun. It was a pleasure. I enjoyed a lot. Good, good. Um I will put links to various things in the show notes. Is there anything in particular though you want to share with the listeners as to where they can find out more information about you. Well, you can find everything about me on my website. It's D minus data dot com to say there, you will find everything. And if you want to get weekly insights, just subscribe for my newsletter and trapping product teams on substack for free and then you get my insights there straight to your inbox. Well, I will absolutely put those links into the show notes and I will thank you again. Once again, David, it's been awesome to have you on board. And I thank everybody for listening and we'll be back again next week, which is generally how things work. So we look forward to speaking to you then. Thank you very much. Thank you very much for staying to the end. It's always a treat to have you here. Conversation with David work be coming up and we have a huge backlog of brilliant game. What will I choose to edit? I'm not sure if you have any requests on social media of the guest that you, what opposed all the pot. So please reach out to us from those block me a line. And once again, thank you for that. This is the product Agility podcast. Yeah.