AA157 - Embracing Failure: Why "Fail Fast" Beats "Learn Fast"

0:01

Welcome to the arguing the Agile podcast where enterprise business agility coach Om Patel and me product manager Brian Orlando debate the real world challenges Agile professionals will face. We are not here to sell you anything. We are here to argue about Agile so that you don't have to. It's a John Maxwell quote. Fail early, fail often, but always fail forward about iteration and , risking failure. In the terms of small controlled experiments small, in terms of impact . In the failing forward book, he uses the term fail. I recently encountered a post that. That seemed to imply there could be benefit in relabeling the term fail, or failing fast, basically not using the word failure, and saying learning fast. we're about to have a semantic conversation I think, but maybe there's value in it. Yeah, I did see it that way too, it's just the relabeling, but you know, the rationale there was I guess Teams don't like to fail. So I struggle with that one because a failure is a failure. You've somehow determined you didn't quite make the mark so we can say we learn from that. But what do you call that which failed? Well, let's I mean, let's think about the pros. In true arguing agile fashion. The first kind of point, and the post that I read about this. The point that they were trying to make was in the culture, the word fail means a lot of different things to a lot of different people. And if you have a company, especially a large company, those people come from all over. Right. Different cultures, different companies, different company cultures, and the word failure, maybe may have strong negative connotations. So while you're saying fail fast, what you're really trying to convey is, Hey, come to your learning and bring your learning back. And like, well, let's all get over the failure. We it's a normal thing. However, some come, some, some companies, I w I would even say some companies. Even when you fail, you try to hide the evidence of the failure to try to blame other departments or try to find a scapegoat to blame them like that. That is, that is a, I don't know if it's a majority, but that is a lot. It is a lot of companies that cover up the failure, right? I think companies like that really portray the culture they have. When people are doing that, because clearly failure is not tolerated or, or, or not accepted widely in such companies. So people do all those things. You said our way from accepting full on that. Yeah, we failed now. What do we do? What do we learn from that? So they, they avoid that. Right. There are cultures that companies, I should say that Don't look at it that way, right? You say, well, take on, like you said earlier at the outset, take on a small endeavor and try it, and if it fails, just learn from it. But the word failure is not where everybody hangs their hat in such cultures, right? But the other ones, they do. And I think you were talking about, Companies where people come from all over the place. I mean, certain countries, you can't use the word failure because it's not really accepted in their culture as it's okay to fail, right? When I first read this article that kind of prompted this podcast, I had a strongly negative reaction to it because my feeling is there's a lot of blame based cultures out there. There are some cultures that. that really understand and really embody this fail fast. Mentality, but they are very few and far between. And even in those cultures, you still have people that come from these blame based they, they've just been conditioned to operate this way to seek. to deflect blame. Like they don't run straight into the house fire. They try to run away from it because that's the way they've been conditioned. So I'm concerned about trying to cut out the word failure for a better word because I would rather us as an organization. Help like find signs that people are conditioned against the word failure and help them get over whatever hangups that they have so that they can get on board with our new culture. I guess that that starts in hiring probably. Right. But I mean, really what you're looking at is you're looking at through the hiring process, trying to figure out a way to find fixed mindset people and see if this, this learning failing fast and learning from it is part of their fixed mindset that is more flexible you know, or maybe not completely fixed maybe this is one of those things that they're malleable mindset. Maybe, maybe. Yeah. I think you're right. And people that are you know, likely to, to look upon failure as a bad thing. They're probably not really vested in the outcome in their kind of on the periphery, right? They're looking from the outside so to speak or almost on it from the outside Looking at that and saying well that didn't work. That wasn't such a good idea It's it's those people that then Say to you, well, you failed because you didn't plan things properly or you know, you didn't get endorsement from everybody, right? Which is like here we here we are. Here's here's the fixed mindset coming out instead of the growth mindset Here's the fixed mindset coming out like the managers could have fixed mindset that you know So that now the team is not allowed to fail because the managers Are enforcing this, this rigid mindset on people like the, if we're talking about failure in an organization, especially when you're trying to have a team that's self managing. Like, like the team and the team members are holding each other accountable far, far more than any management is ever going to hold them accountable. Like you're, you're direct coworkers. They're vested in the outcome, right? So yeah, I agree. They're vested. So they're going to try to look at that and say, yeah, well that didn't work, right? Let's get our heads together and figure out why and we'll do something different. We'll pivot. So I agree with that. I think the team members are far better at accepting the word failure. Then the managers and then in some cultures, if the team fails and the manager is deemed to have failed because it's quote unquote their team that failed and they don't want to be seen as, as failures. So as the agile coach in the room, this is an interesting one to say, well, we're going to use learn fast. Now we're not going to say fail anymore as a culture, right? I don't know who decided this organizationally, but somebody has decided to push this, the word police into our culture. Their arguing point obviously they probably wouldn't say arguing point, right? But there, what they would be arguing is the, the emotional impact of not having this word in our culture is gonna allow us to have more open conversations and allow us to have more psychological safety in the organization, because you know, again, we don't have to walk around all these hangups that different people have. We can all rally on this different term. Yeah, they can do that. But you know, when you have new members, I mean, it's going to be hard to maintain that, I think, because when something doesn't work. What is that defined as, right? It isn't defined as, well, here's a learning opportunity. That comes later. Not much later, but that comes later. Initially, it's, well, here's what we think we're going to do. And here's the outcome we think we're going to get based on the actions we're taking. We don't, we didn't get those outcomes. Well, you don't say, let's learn from that at the beginning. Maybe you should, I don't know. But you don't typically do that. You typically evaluate it. And I think the trick is, who's doing the evaluation, right? As you're saying, if the team is looking at it. Then they're going to be much closer to the problem or problems and their attitude might be well, it wasn't a complete Failure, right? Maybe some of it worked, but this other bit didn't work. So maybe we can change that so whoever's saying that I think is I think it's it's doing a bit of a disservice to not acknowledge that failure is okay I mean are we gonna say that? Who was it that invented the light bulb? They failed 10, 000 times or something crazy. But also like after the, after the podcast, we talked about that. I was looking into it more in a, it actually might've been a bit of marketing maybe they fail a hundred times. It doesn't matter, but that's still. Maybe the bulb flickered a bit. Let me learn from it. It was more like a team activity. It wasn't like one person, you know what I mean? Okay, so they didn't blame each other though, right? Well, no, it was uh, it was diffused blame and collective claiming of the success. Yeah, yeah, yeah. Which is messed up in its own way. Well, that's a whole different podcast. I like, the point is you want to set objectives. And then you want to try to achieve the objectives. And then when you do or don't, you just want to call out like, Hey, we did not achieve the objective. Right. That is very difficult to say in a word. And then an O word AO. Yeah. Where are you at? Too much pressure. So I feel there is a lack of directness here where we need to talk directly talk about the failure. We need to embrace failure is how I'd say it, right? I think if we're just going to say, Yeah, that you know, that's another learning opportunity. Then I think we're missing out a little piece of that, which is we're treating the failure, that which failed as a binary thing, it failed, right? Which, depending on the objective, It might be a good starting point to say, that failed. Now look at it, did the whole thing fail in its entirety or were there pieces of it that were still good? That were salvageable? Then let's work on the other pieces, right? So, you can you can try to kind of dodge the word, fail. But, I don't think that's doing anybody any service, really. I I think of you can't do this piecemeal. That's another kind of pushback on this Hey, we don't want to use the word fail. We want to say, what are your learnings? Like another pushback on that is it is the potential for it to get hijacked because like if your teams, your teams are doing this thing where they're saying they don't want to use the word fail. If your middle management is not on board with this, now you're, now you've got a real shaky culture where the management is like, well, I don't know, the teams are doing all this holding hands. Stuff. And you know, they're not achieving as fast as we think that they they're not, they're not put, how many times have you heard this one? How they're not, they're not putting out code as fast as releases as fast as we think that they should. Like the managers as fast as we think. Yeah. That they should crack the whips more like I, I, I see this as being like another. Thing to get upset at teams at, well all you guys are trying to implement this, these cultural changes, but also like I've been exposed to a lot of cultural changes that the teams tried to push up through the organization and you know, management kind of having a bad, a bad time with that just because they're frustrated with. So if we actually wanted to do this, what are all the elements that had to be in place for us to change, fail fast, to learn fast in a culture thoroughly, basically, like your teams have to accept it. Your leadership has to accept it. And then, and then the middle management, if you know, again, assuming that you have middle manager and then the middle manager has to come along with both, they have to fully support in their role as a representative of management up leadership management, upper management, they have to come along and buy into it. They can't be holding the teams. Feet to the fire to say like, Hey, we said we weren't going to use the term fail, but you guys aren't doing a good job and you're failing. And we, we, we, we think you're just being complacent. That basically, that's what middle management is thinking. We think by just not using the word fail, you're actually being complacent about hitting all your deadlines and goals and whatnot. Yeah. I'd say yes. And you know, they may say, well, you've been learning a lot lately. Yeah. Right. But what have you produced? We don't pay you to learn, right? We pay you to produce stuff. So what have you released? And so in a way, what I'm saying is that can also it can, it can't end well. It can be weaponized by people because they misunderstand the intent behind it, right? Right. And again, when I first heard about rebranding failure as learning culturally, that was some of the things I was thinking of. I was, I was immediately gravitating to The the management saying hey, I see you guys quote learning a lot. Ha ha ha kind of poking right, you know at the teams and not, not committing to the chain, like resisting the cultural change to come along and like, well, what does it mean to really support your teams as they set goals and then do or don't achieve the goals we're like, we're in, we're in the 50 percent case where they don't achieve the goals, right? What does that mean? But they don't achieve the goal. I think about this like sprint goals. That's like, let's, let's use that as an example. I set a sprint goal for my team when the sprint sprint begins. Right. I set one sprint goal one., I didn't always do that. I didn't always have the luxury of having management that would back me with my one Sprint Goal, but the management understands. only ever one thing that is top priority for the business. Hey, if we could do nothing else with the team this sprint, it would be please fill in the blank and, and likely your, your management or leadership, whatever you have. Like they probably can tell you I've got to have this done if forced to tell you a top item, because most management has a laundry list of like, Oh no, I need to have a dozen things or whatever. I understand you have a lot of type items, but if you could only pick one and you could be guaranteed that it would be done. By this date could you pick one? Absolutely. I think every time. Sure. Yes That's that's what this is talking about the certainty that hey We were failing at whatever much like what can we do to succeed in this one thing? Well, what is the very next goal in front of us that we can set? Let's set that and if we don't achieve it Let's stop and let's talk about why we didn't achieve it, right? Find it very difficult to To, to have that conversation, the very straight forward conversation I just outlined, which was one of my points that I wanted to, that I wanted to outline of why I like the term fail fast, directness and clarity. We failed. We set this goal for ourselves. Again, we're self, we're self managing. Nobody set this goal on our behalf. the company has goals, but we said, this is what we can do to help the company achieve their goals. We set that goal ourselves because we're self managing the directness and clarity to say, we did not hit this goal. These are the reasons why we don't think we hit the goal. And we'll talk about it and we'll say, this is what we can change. Like you can keep the word failure in your nomenclature, have that adult conversation, come away with key takeaways to try and to adjust your strategy, whatever you're doing. And I don't, and, and, and keep your psychological safety. That's my challenge to this. I think you can keep on that. Yeah. I think that's true. And I also don't think there's just black and white, like you either use the word fail or learn, right? I think you accept that the failure happened and you immediately learn from why it happened and then move on. Right. So I, I a lot of organizations are, are, Okay, with the word fail, but if it's a big failure, meaning that the endeavor was big, they may have a bigger issue. So the teams need to understand that as well and say, let's just take on something small, layer on top of that, this whole experimentation mindset that the team should adopt. And it's pretty clear when you do that there's cause and effect. So we're gonna say, here's our hypothesis. If we do this, we expect X to happen. And if X doesn't happen, then we look at. Why it's a try and change our hypothesis and move on to the next bit. So failure isn't something that is, unless you have a large endeavor, a failure should be a very small slice. And even in that slice, not everything would fail necessarily to piggyback on your example of the sprint goal. Maybe the entire goal didn't fail, right? Maybe you did quite a few things that. I'm still pretty good. He just didn't make it all the way. So why is that? That's different from, well, we didn't meet the spring goal. Let's say what happened?, nobody did anything. Well, if we're going up to product management, I'm not communicating up to the rest of the organization in like work items in my sprint stories in my sprint, that level, when I go to, when I go to communicate with stakeholders and whatnot, like I'm usually at the epic level, so I'm reporting progress on the epic. So if we, if we didn't hit the sprint goal, even if the sprint goal was the sprint goal very rarely for me. If ever, I don't think it actually ever is, but the sprint goal very rarely is complete this bucket of work. That usually is not my sprint goals. My sprint goals usually are have to do with delivering a certain specific thing to a certain customer or solving a specific problem. That usually those are my, those are my sprint goals. The system that I use, which is Jira uh, like that system uses stories and stories roll up into epics. So usually it's it's a couple sprints before we close an entire epic. And and that is what I'm communicating with stakeholders. So as far as the stakeholders go, they could care less if we didn't hit the sprinkle. They really could care less unless my again, unless I set the whole Sprint goal around delivering something to one customer, one specific customer. And even if we feel the sprinkle. We probably have something to show at the end of the sprint to that customer to say, hey. We're not delivering you the full solution. This is what we had. We had to mock up some fake data. This is what it's going to look like when it's finished. We're gonna need a couple more days and that's the deliverable. Again I go back to this as the, the, the key, like you want KPIs, you want OKRs, you want whatever, like cool. Do all that. But all that fades away to the background. If you're just delivering , on a cadence that is regular to the customer where they can get their software, whatever it is, or they can see the changes, they can see that progress is being made. All the rest of those numbers just kind of fade away. Yeah, epics have a much larger time frame. So you don't want to fail at an epic. It's okay to fail a few stories, right? Because it's much smaller as a piece of work. Which I feel could be that's a future podcast that we should probably have. Yeah, I don't know. I think it's a fairly quick podcast in the vein of one of our more popular podcasts about splitting stories or not splitting stories. I'm sorry. That's a different, that's a big, no acceptance criteria. We had a, we had one about creating stories and acceptance criteria about the actual creation of the story. Which could be another podcast. Actually, we should have a, we have to actually, we should have a, like a couple of BA focused podcast. So like one is creating a good story. One is creating good epic. Yeah. And one is when to cut the epic off because epics, like in my world epics again, I'm using Jira like epics, I take to a certain point until we deliver enough value to the customer. And then I will slash the epic and say, we're done with this epic. I will cut off the epic, whatever grand plans that we had for other things we were going to do. They may still be valid. They may still be valid. I'll take them out of the epic I will extract them and I'll put them in a different epic to say like hey we we like if you were like like we produce this podcast like if an epic was like I want to be able to take the the audio podcast and automatically upload it with a script and Have it upload all my transcripts and everything so I don't need to go and actually touch any specific social media sites to post Like that might be an epic, like automate, it's gonna take a while. The podcast, a couple. Yeah. It's gonna be a lot of stuff. I mean, yeah. I gotta deal with YouTube. Sure. I gotta deal with a podcast from RSS. I gotta deal with transcripts. I gotta deal with files. Yeah. Yeah. There's a whole bunch of individual stories. But I might decide once I upload the thing to YouTube and once I get the transcripts and all in place and whatever, like that's good enough. Okay, cool. Done Enough. That's enough. Yep. And then I'll cut it off and say, okay, well I wanted to post to Instagram and I wanted to post to Facebook and I wanted post all these other ones. Cool. I'll open a new Epic and say, hey. Post to additional post the podcast to additional media sites, so social media sites, and that'll be in the new epic. Because as we go along and as we set goals and as we experiment the things that we do that contribute to the epic to say we've met. The business outcome we were looking for have a presence in the podcast realm, have a presence on a at least one social media platform, maybe more or whatever. Well, we're on YouTube and we're on LinkedIn. Okay. That's good enough. Like cut the rest of them, move along. We'll look at the signal on these platforms and see if we need it. Like I'll just cut, I'll just arbitrarily cut it off. I'll go back and negotiate the business and say, Hey, look, we're done with a big swath of functionality. I think this is Epic's done. I'm going to spin it off and create another Epic plus. Again, I'm talking the stakeholder level. I'm not talking to the team level now to the stakeholders. They like to see regular progress, just like team members, team members like to know they're hitting goals and accomplishing them and moving along. And when they don't hit goals. This is, this is, again, this is my problem with relabeling failure. If you want, if you don't want to say fail fast, you want to say learn fast. I mean, that's fine. But if you're saying, well, we put something out there. The product manager talking to leadership. And talking them through how we're succeeding and hitting our goals and milestones. Leadership is a, is a crowd that wants to directly engage with the failures. They want to dig into the failures. Leadership should not be strangers to failure. Absolutely. They should be completely okay with it. And if they, if they really do have a fixed mindset, and they're really pushing back against failures, and looking for someone to blame, and asking really like, if you've ever been in an awkward meeting with leadership, where they're just tearing into somebody for a failure, You should really take a step back for a second. It'd be nice if you had a good personal relationship with them, because you can kind of take them off to the side and say, you do realize that you're out of line. Like all these people are looking for you. They're looking to you for leadership. So you can't be, you can't be collapsing when we have the most minor of failures. You have to be the one that is kind of saying like, look, what did we learn here? What are we going to do different? How are we going to handle it? Like, how are you going to handle this? You know, you, you really have to be the adult in the room at that point. Not, I've seen a lot of, a lot of leaders cave in the face of what I think are minor, minor hurdles. They cave and they usually press downhill by saying, you guys, you need to own this. Right. You, it's on you. You're accountable for this. And all of that contributes to really kind of threatening that, that psychological safety. So what's, what are people going to do if that's the culture? Typically that's in the command you know, command and control culture. They're not going to take risks because they might fail and then the radio ship's going to come down on them like a ton of bricks. So, unfortunately, avoiding the word Failure and not talking about it and just talking about learning, learning. People aren't necessarily start taking risks even if they're calculated risks and say, If we do this, we're gonna do this. And if that works you do four or five of those things at a time typically, right? Let's say. And three work. Well, has the whole thing failed? I don't think it has. I think three things worked. So, okay, put those aside. Focus on the ones that didn't. Examine your assumptions. Change a few things. And prime the pump again. When I first read this post about hey, we're not using the term fail fast anymore. We're gonna use the term learn fast We're not gonna use the term fail has negative connotations or whatnot. I thought of exactly that scenario I thought of being in a company With leaders like this that were just, incensed that you were trying to avoid taking ownership of a failure because, because they were not going to take ownership of the failure. They, they were looking to blame. Right. And, if you tried to coach them. Hey, don't you think that, I don't know what the other guy, what voice was that? I can't like, there's not a, I need a voice for like a sensitive, a sensitive artist of my voice. Like if you were trying to coach them of you know, Hey, don't you think it would promote a growth mindset and, Promote psychological safety if we don't use like, oh man, that would like there's a surefire way to Get put on the naughty list for santa that that year and like that is not the I would love I would love for someone to interdict into that conversation and when the leadership is tearing into someone and obviously they're out of line, I just i've been in too many cultures and too many shops and seen it to say like look these people are stressed out they're already feeling insecure about the failure. Maybe you don't have good goals in the first place. So you weren't even expecting failure because maybe you're in this ambiguous this, this place of, of real deep learnings where you're doing some new things with your software and you're really not sure. And then all those fixed mindsets are coming out now you really need growth mindset people to Helm those new features, but all you have is these fixed mindset people. The only way that works is if the leadership themselves have a growth mindset and they can say You're learning, but learning what? Oh, we failed here. Okay, that's fine. You know, that, that's okay with them because they accept that failure is part of progress. Right. Right. Right. But that's not very prevalent. Well you know what else is not very prevalent is leaning in to this fail fast culture, leaning into the word failure, leaning into failing fast, the playbook of failing. should be you fail. You throw up the, you throw up the flag that you fail. You're whatever you pull the cord, right? That you failed. Management comes over and says, okay, what they, I mean, they, they do the whole, the, the Gemba. I can't remember the questions. Well, like what, what's the current state? What's the, what is the state that you expected? Yep. You know, what did, what did you do? What, how do you think we can improve the situation? They walk through the questions. I can't, I can't believe I can't remember what those questions are. There's a framework for that and I can't remember. You're not thinking about the five wise are you? No, it's not five wise. It's it's not kaizen. It's God, I can't I can't believe I can't remember the well you guys let us know in the post. Yeah Please let me know. This is ridiculous. I can't remember the name of the the framework Unbelievable, I think you have a learning opportunity here. 2, 000 years later There may or may not be a hard edit here that I come back from. But the point I was trying to make was. When you're avoiding leaning into failure, when you're leaning away from the term failure, like there's a certain amount of risk taking that you as a leader want your people feeling free to take on. Yes. And I guess smaller the organization, the more. Risk you're willing to, to empower your employees. I mean, again, if we're self managing, it was so we're self organizing, self managing, whatever the current version of the scrum guide says whatever it is like, We're running the business with our little corner of the organization on our team. So we're taking risks. We're making, we're, we're making bets and then we're cashing those bets when they don't turn out right. Like we're paying for it with our own time. That's right. So like, Hey man, why are we not allowed to really like Dig into this if we're cashing the checks that we write. Yeah. I think that the teams need to feel like you said, they need to feel ownership of that. Right. And like you said, when things don't work out and fail, they need to feel the hurt because they should look at it and say, what was the cost we just incurred of this? And what that does is it really puts the the onus on them to move away from there quickly with whatever learnings they can grab. And Try it again, a different way, right? But, yeah, there are so many companies out there that you know, they just say, well, let's just have this culture of not blaming one another and we'll just use the word learn. What's gonna happen there is, to one of two extremes, I think, right? One is, people aren't gonna take risks because they're just floating, right? Just going through life, everything's good. That's one end of the spectrum. The other end of the spectrum is, They will make reckless risks. They will take reckless gambles and because they're not going to feel anything or no one's going to say anything. Those are what we learned that didn't work, but you know, that, that is not their money. That is the other end of the spectrum. And I, I've seen teams like the, the. The, the experience I can bring to the table here is I have seen teams that go off for months and months and months and never deliver anything like that. They're like, Oh, we're trying this and it didn't work out. No, we're trying this and we don't have anything to deliver because all of our we tried this technology and it didn't quite work and we tried this and it was just too clunky to maintain. So we spun on those servers and we're building our own is the other one. How long are you going to go about this? Like you can't. I mean, I'm checking in product wise, the product manager in me, I'm checking in every week. I mean, every week is like extremely fast compared to the team that goes off for three months at a time. To figure out if they can, I don't know, do something with technology or whatever. Yeah. And I, I've seen that, that particular a behavior. Well, where the team goes out and experiments in quotes, different, try out different tools and they say, well, this was not quite good enough. This other one's better, shinier, whatever. Try that one. And they go, Oh, it's better than the last one. But. You know, there's this new one just came out. Nobody's using it, but it's it's much better. It smells better. It's more chocolatey. We're going to try that. And then they fail. And then what they'll do is, and this is typical in teams that are technologically driven. I mean, the leadership. Tech leads, architects, they're really kind of pulling, pulling their weight there. And they'll say, none of these tools are good enough. So we're going to build our own now, several more weeks go by, right? And you're not delivering any value. And that is also the case where in, in organizations where. Unlike what you just said, product is just simply hands off and they're waiting and waiting instead of going in there every week or every X number of days and saying, what's going on? No, you can't, that's, that's too long. It is way too long. again, in the, in the ALM system I use, I'm not going to do my spit take again, it's Jira uh, in the ALM system I use like I have a components field and one of my components field is, Like my team is doing something that's going to enhance our capabilities and learnings. We're going to bring new skill into the team. We're exploring something to bring new skill into the team, right? I have, I have a component for that. Just like I have a component for feature development, which is capitalized work was just like I have a component for like basically backend infrastructure work. And I mean the spin up servers and deal with stuff that's all not capitalizable. So I track, Hey, my team needs to go out and learn some new technology in order for them to do something in order for them to do some new capability, to perform some new capability. I track that, but I'm not about three months like that. Ridiculous. Like a two, three days. And I'm asking as a product manager aren't we done here? Because I mean, how long does it take when you're, again, my team members are dedicated to the tasks that they do. And they take on, because again, we're all self managing why would you self manage and then take on 15 tasks all at the same time? Well, because your teams are sourced from different matrixed groups all over the place, pressure and all kinds of negatives, but again we're going through this discussion of of relabeling fail fast into learning fast. We're going through this discussion of the pros and cons of this because , we're trying to provide psychological safety. We're trying to provide an environment that people understand, hey, . We want to get through the failures to the learnings ASAP and we don't want to dwell on the failures. I just, . Everything we talked about so far in this podcast is only pushed me more towards we like, we need the word failure. We require the word failure. The Maxwell quote that we started with fail early, fail often. But always fail forward that, that people always interpret as fail fast, fail often, fail fast. I like the word failure, and I like that quote because if people are reacting negatively to that quote, I immediately am worried that they do not have a growth mindset, and I'm immediately worried that that I have people with fixed mindsets in the organization that now are in management or now are in leadership or now are going are seeking to take control of myself organization and they're going to start setting goals for me rather than us setting goals for the company. That's right. And the downward spiral has begun. So yeah, I agree because longterm that cannot be good for the organization. Yeah. I don't like that. I don't like, I don't like, I like the directness. I like the clarity of failure. I like, again, I like, I like training people and if we think of this as a learning and development opportunity, so if the, if the culture wants to relabel failure as learning opportunity or whatever words that they choose, yeah, I don't like that because I like training everyone to say, no, let's say failure and then let's have a playlist that we kick off when we hear the word failure. Okay. What was the original objective? What was the, how far did we get towards that objective? You know, and then I probably would have a half a dozen questions. Well, what did you try? Like, how often did you check back in? Did you let somebody know after 24 hours that you were not making any progress? Yeah. Did you try to bring somebody in to look over your shoulder to help you? You know, is this, is this a personal thing? Basically, did we fail because someone was scared? To ask for help right right what yeah, and then collectively what we have done different And what can we do different yeah, and then and then whatever the answer is I mean like even the funny thing is This is not a new concept even even even when I was in the military you would do after action reviews Sure, even when I work with project managers you would do What is the what is the when the project ends the postmortem postmortem you would do postmortems? You mean so there is In the culture, in the, in the zeitgeist, I don't know, out there in the ether, there is this concept of, Hey, regardless, pass, fail, whatever it was, we got to inspect, we got to figure out what we can do better. And now we got to institute some changes and let's let's do it. It only works in companies that have that culture though. So if you find yourself in in a company where. Failure is frowned upon. Yeah, we have some advice for you. Keep that resume updated. I was going to say it's not good advice, but it's, I mean, it is good. It is advice. It's every penny you didn't pay for that. We can both agree on that. Well, thank you for for watching, listening and like, and subscribe, ring that bell.