AA79 - The Case Against Psychological Safety, with Stormy Dickson

So stormy. I wanted to do a podcast for a while about psychological safety, but from a perspective that I've never seen before, which is I'm going to try to, to make a case against. Oh my gosh, this came up. So just saying, did it, it's kind of, can I, can I shoot you this cuz it's short. Yeah, yeah. Send it over. So this is interesting because we talked about this today, okay. Per perfect. I like to blow it up to a point where I cut out the yeah, yeah. Or author. So, which is yeah. So it says, if I were to write a book about slash for organizational leadership, It would be a condemnation of the leadership message today, which is about self-help being more purposeful, empathetic, motivating, people-centric, et cetera, cetera. He says don't get me wrong. Air quotes, leaders, leaders, quotes leaders. Mm-hmm . People go to work to work their work. Why is, why is it working caps? Mm-hmm should be motivating, purposeful, and done in connection with others here. Here's the thing leaders. It's not about you. It's about the work, how it's done, why it's done and where it's done. I think I've read enough. you need to really stop looking in the mirror so much. And instead of focus on the process, protocols and rules behind preventing work from being meaningful and collaborative, I'm not even sure what yeah. This is why I love slash hate LinkedIn. Why are we concentrating so much on this warm and fuzzy BS mm-hmm and just go to work, listen to your leaders and just do what you're told. That's kind of what I distilled from that. I mean, that, that is a lot of people's. Point of view, that is a lot of people's. And does that, does that kind of fit into what you were talking about? It certainly fits in the category of psychological safety is a bunch of nonsense. Get back to work, like do what I say. I don't even know if it's do what I say though. I don't know if that's a fair assessment. Of the category. Yeah. I wrote some points before you got here expecting to like, boom, get right into it. The first point that I had listed was you have not earned the right to autonomy yet. Mm. Like you're like, oh, empower my team. But I, as a leader, I'm like, well, I you're new or you're a new team, or I still have to check in on you. I think that's gonna be the flow of this podcast is I'll give you a point and then you tell me what arguing against it. yeah. Cause because the arguing point here is you have not earned that trust where I trust you to be empowered, to figure out , the way to get to the goal. I guess my question, my, my immediate question to that would be what would be your definition of earning trust? What does that mean to you? So you're speaking from a leadership perspective. So the team has earned your trust to be autonomous. Yeah. And to work to be self organizing and figure things out on. So I'm until you've earned that trust, then I'm gonna tell you what to do. Mm-hmm or now it's not even just, I could, I'm gonna tell you what to do. It could be like, I, the manager I'm gonna come to all of your events and whatnot, you know? Okay. I see. I've seen this a lot. It's micromanage. Yeah. I've seen this a lot in my career with teams of contractors. Mm-hmm I don't, , a hundred percent trust the teams of contractors. So I'm gonna come to your refinements. I'm gonna come to your sprint planning. I'm gonna drop into your retrospectives. Okay. So it sounds from a leadership perspective, you are trying to check some boxes to make sure what that definition of trust is like, are they actually working I've hired you to do a job. I'm gonna come in and make sure that you're doing something that qualifies to me. Checking that box of whatever work that I've hired you to do. Is that what you're saying? I mean, it could be, I'm not a hundred percent certain cuz I, I think this one is like sometimes people just are on different wavelengths mm-hmm that, that could be what's going on with this. It could be that it could be, we're just not on wavelengths. See, we're not on the correct wavelengths yet. One of the goals. I dunno if it's a goal, one of the key points of psychological safety is you should be able to be your true, real self mm-hmm . And if you have somebody in the equation who obviously is not being their true, real self they're not willing to go out and say, These are the things I need to be able to trust your team. Like that was the first thing you went to. You're like, okay, well, gimme, gimme a checklist of things that you need to be able to trust my team and then let us prove that and then get outta my life. That's not actually what I was going for. I was asking your so what I was trying to do is understand your perspective. So from a leader, it sounds like there is some checklist, some mental checklist that you need to be able to fulfill, to say, Now I trust the team. So what I'm trying to do is go, okay, from a leader's perspective, what does that mean to you now? I'm not saying that that means you're gonna give me your checklist and I'm gonna make sure to meet those checklists so that you can trust me. But what I'm trying to do is understand where you're coming from. What is it that you're looking for so that you feel comfortable in saying team do your thing? Here's what I believe. I am vehemently opposed to micromanagement and I feel like we you know, we're doing a good job in hiring good people. And as a leader, hiring people smarter than. Which I'm comfortable in doing so that I don't have such a huge ego to say I wanna make sure that I'm the smartest person in the room.. So I'm gonna hire people that are smarter than me that are gonna do a better job at what they know how to do best. And I am going to allow them to go free and do that thing. That becomes self-limiting. So, yes, there is a period of time. So we need to go through for particularly as a team that forming storming norming thing. But particularly as a team, when we have people who are working together and the expectation is that we succeed together and we fail together, the team will keep a team accountable. They keep themselves accountable. And I, as a leader am reliant on that and becomes self-limiting. If I have somebody who's not pulling their weight. Then that's something that typically the team deals with. Yeah. And if it isn't something that can be resolved within the team, then it is something that's, that's elevated up through management and then will come to potentially to something that, that a leader needs to handle. Mm-hmm so and, and kind of the short way of saying that is if I'm hiring somebody with the skills that I need to do a good job, or do the, do the job that I need them to do, I'm gonna trust them to do that. And if it turns out that they can't do that job, or they can't do it well, mm-hmm then they, like I said, it becomes self-limiting and they can't hold their weight. Then I will either work to find them an opportunity that maybe is more appropriate or get rid of them. I think like this is an interesting category the empowerment category and the, the dealing with things as a team category. I wonder why most people don't do this when they claim to have empowered teams I'll give you the example I'm thinking of your company claims that have empowered teams, but then you do, yearly performance reviews that are one on one. and all of your metrics and all of your judgments and whatever are based on individual contributions. Mm. Normally the performance reviews are directly tied to whatever pay and bonuses and raises or whatever the end of the year., how can you do that? And claim to have this at the same. It seems like you can't like you are not gonna be able to play in both worlds or am I conflating this with another bullet point or something else? So not sure you could be, but my mind. Yeah. But my mind went kind of in a, so I think that there could be individual and, and really should be in individual evaluations, but perhaps in combination with a team evaluation. And even input from the team. Yeah. But the other thought I had about this is wow, what an opportunity. So I think you bring up a really great point, what an opportunity to do an experiment. So as a team, we succeed together and we fail together. So what if our incentive is based on that? Yeah. Right. What if our, if we have an annual incentive or some other incentive, a quarterly or whatever what if we're judging each other or grading each other as a team? So what I can tell you is, for instance, I've been in retrospectives where I would have someone say, do you know what, the last six months I've been going through? whatever. And I, I can honestly say I have not been pulling my weight. Yeah. I haven't. And so if we have, let's say the standard 3% raise every year, right. And let's just say that across the board our team could decide what, just, everybody gets a 3% raise mm-hmm . , and I'm using this not a bonus structure, I'm saying a raise, and this is from a very corporate kind of thought process. Sure, sure, sure. This may not apply, but just an example, the, the accounting center corporate, like. 3% raised so that you're only 5% below inflation. I mean, whatever. Yeah. I hate it, but whatever that's, it's, it's very common. So, but let's just say, so as a manager of that department, you have to decide, you give one person 4%. That means somebody else gets 2% mm-hmm right. But what if you had input from your. What if your team was able to be involved in that, and this is just all hypothesis, maybe people are doing this. I don't know. Yeah. But what if your team was able to be involved either at the level of deciding what race and how it should be dis dispersed within their team or a combination of individual evaluations along with a team evaluation, have some kind of a metrics there. I don't know, just some thoughts that, that, that just. Thrown out there people may be doing this. I, I really have no idea. Well, there, there are 360 feedback type models out there where you get feedback from your entire team or, we've even floated that on the podcast. The idea of like a net promoter score at not an individual level at a team level. I floated in a previous podcast, don't ask me which podcast it was. Cuz I have no idea. I floated in a previous podcast, if you have a program that has a bunch of product owners slash managers, doesn't really matter what you drop title, a bunch of product people. The idea that the people that those product managers slash owners interact with. On a certain time basis, give them a survey, how happy are you that your product ideas being taken into consideration? How happy are you that your product needs are being met? That kind of stuff? Just, just, this is a very simple net promoter score thumbs up, thumbs down, or it could be a one to five, whatever it could be, anything. and as a product organization, you start getting your you start getting user feedback. Now your, your users is a very broad category, right? It, it could be a mix of internal, external could be external, only customers, users. It could be yeah. Customers, users. Yeah, exactly. It could be a breakdown of the categories across like you survey a bunch of people and you aggregate it all together, but then you break it down and there could be a lot. In that discussion, but I, I floated that on the podcast before well, maybe we just do a very simple survey of five questions, one through five, and we come up with a score but I feel like at a certain point you have a, I don't even know if I can say this with a straight face at a certain point, product managers, even I like probably even scrum masters. Like you probably know where your weaknesses are No, like the reason I bring this topic up is because like the, the next segue to this topic is psychological safety is the arguing point that psychological safety is just a shield versus accountability. Right. Because the, the, the, the team structure, I, I know I'm gonna this is a heavy, heavy topic. Need to make some notes, like the team structure. Yeah. Yeah. Take it. The team idea. Like what we were talking about oh, well, if you're gonna have a net promoter score, it should be a team level. It shouldn't be an individual level. Or if we're gonna do feedback, it should be a team level feedback. Shouldn't be individual feedback. Mm-hmm well, the arguing point, the management argument point for that I feel would be well that like, at that point, like how do you know, on a team who's carrying most of the way to the team and who's dragging, you know what I mean? Like there was a, you're using the team as a shield to accountability. So what you just said was like, well, let the team figure. Who makes bonuses or whatever. the difficult part of that is it's tough for any group of people to point at any one person and be like you are the low performer or you're the weakest link you're voted off the island. I just confused all kinds of things when I said that, but People, a lot of people get. Yeah, yeah, yeah. Like that is tough for a team to do. So they might like dealing with that tough conversation might be harder than just giving everyone on the team in equal bonus or whatever. Okay. So I, I agree with that point. However, I think that it would be a lot more difficult for your new. Who are still working because building psychological safety and trust, particularly within the team takes time. Yeah. Right. So if you are, I don't know, say you have a review within the first six months just because it happens at the same time every year, you know? So within the first six months, you haven't had the time with your team to really get to the point where you can call somebody. in a safe way. So that that person doesn't feel attacked. Mm-hmm right. So they are taking it as a point of opportunity and appreciate that saying, you know what, I appreciate you bringing that up cuz that's helping me to grow and develop. Yeah. So I would imagine that a team at, particularly at the beginning would probably take the safe route and say, all right, everybody just gets the same raise. Right. Mm-hmm but this would be the perfect, I mean, this would be kind of, I think the perfect opportunity or thing to discuss in a retrospective. So when we're talking about process yeah. We're talking about improvement. The other thing I would say is you will always have. A variation of skills and abilities within a team teams, things are gonna be some team members are gonna be stronger than others and that's necessary. I think, within a team you're not going to have every person on a team that's going to be the rockstar in everything that we have to do. Yeah. And depending over a period of time, what we see is we have people really shine in some areas and better than others. And sometimes people find that they realize that they shine in places they didn't even know. So you have these kind of norming happen, right? Yeah. So as you go through the teams, so I think that as your team matures, that you would have, that feedback loop within your team, that. Usually have a retrospective mm-hmm , that would be more and more honest and more and more readily received and appreciated if we get to the point to, as of incentives, now we start this, this actually I think could cause a real rift. Actually when you think about it. So now thinking about this a little more going like, wow, all of a sudden we're talking about money. That's almost counterintuitive. Mm-hmm right now we throw incentive in here. Ah, does throwing the team into it. So from a self evaluation perspective, I think that that would be a good thing. So the team to self-evaluate as a team, but for the team to maybe. come to terms with who gets, what, in regards to monetary. I don't know. There would be some I, that, that, that would take some, I would say maybe some experimentation mm-hmm well, this, this is the part about teams where , in the modern implementation of. Air quotes. I'm doing air quotes for people that are only listening to this agile where assuming you have some kind of mechanism for the team members saying, Hey, we value this person. We don't want this person to leave. We absolutely can't survive without this person that kind of thumbs up, thumbs down type of voting. They have to have worked out some sort of bonus structure based off of. Consensus style vote. Mm-hmm but I don't know I don't know, it's part that, but it's also part like you, if your team is truly cross-functional people in that specific skill set, like for example, if you have somebody on your team, every team has one QA engineer, for example, mm-hmm and all the QA engineers together. represent a community mm-hmm inside the company and maybe, maybe the bonus structure is part. Maybe the bonus structure is three parts. Sorry. The I'll do the, the own German three. There you go. maybe the bonus structure is three parts. Maybe the three parts is number one that person's whoever hired that person, their direct people manager. I don't know, hiring manager. I don't know what to call it. Number two, their team, number three, their community. mm-hmm and or community lead, right? Maybe it's that maybe it's those three pieces put together and the HR person kind of walks around and, and does the hard work of consolidating the feedback and giving the feedback that, because you, you could be talking about a lot of people. I mean, you could be talking about you, community manager, all the other people in the C. when you're doing community practice events, mm-hmm you could be talking about your direct supervisor, who person who hired you into the company, the person who's like, oh, I, I hired you into the company. I expect you to grow as a person and I'm kind of your mentor, but you know, I'm not really there every single day, that kind of person that I don't, I don't know, like I, in terms of what, what they would be day to day and then your team, obviously. So someone's gotta mesh all that feed. And then present it to you in a way that is constructive. Sounds like a lot of work. Here's a thought. Yeah. Yeah. I, yeah. HR is a lot of work. Isn't it? Yeah. What I'm just saying though, is it necessary? So what if oh, what if we just didn't have bonuses? What if we just, I don't know, paid people appropriately and didn't have this competition. Between team members, which if we started off with this talking about psychological safety, if we're having, if we have team members or even multiple teams that are, are, are we've created an environment, which is actually going to impede that mm-hmm, , it's going to be a detriment to trust. What is the incentive of this person? Why are they saying that like, Hm. And potentially breed bad behavior to incentivize themselves. So, I mean, maybe all context is key here. I get that But maybe bonus should be looked at more at a much higher organizational. Hey, we made some profit and let's distribute this amongst our employees and not have to quibble about it because. our teams. Yeah. Our teams fail and succeed together, but the cross functionality of those teams and the bigger picture of those teams working together are what makes our entire organization fail or succeed. Yeah. So if our organization is succeeding, it is. To some extent, a piece and piece parcel of every one of those teams working together. Mm-hmm and some of those teams will have back pedaled for reasons under no control of their own., and still we're able to somehow kind of pull through, right? Yeah. So all everybody's gonna have different challenges, but if at the end of the year, we've all come together. right. And we have all moved forward and been profitable. Mm-hmm so I, I just wonder almost if, if this whole incentivizing or bonus structure is almost counterintuitive to the the ability for teams for the sake of agile to create the motivation, the support and the trust that is needed according to, to agile principles. Right. I, I see where you're going and it goes against my arguing point, but I think it's a good point. So I'm gonna highlight it , this specific bullet point we're talking about is, oh, you're just using this as a shield against accountability. But if you're one team, one product, one team, right? Okay. We're making some assumptions right here. Let's say small, let's say small company. Maybe you only have one product on one team. Yeah, it could be. Well your, if you are product owner slash manager, if you're product owner. and your team together, they have full visibility of the P and L for their product. Mm-hmm they know how much it costs. They know how much the salaries, the entire team, basically the, the run rate of your team. If you are not hiding from your team, how much it costs to fund the team versus how much revenue comes in from the product, the team is creating and maintaining. If you are not hiding financial information from your team, then your team, when they make decisions, what to implement. They can take financial information into consideration and make the, be the best decision. So where, where I was going with that is this, this category we started with was shield like, oh, I'm gonna use this as a shield against accountability. Well, you can't really use it as a shield against accountability. If you're saying it costs a hundred thousand dollars a month to fund to, to, to basically keep everyone employ. And keep the servers running and whatever. So whatever you guys do, if it, you, that was a, that was a Jersey. You guys use guys, whatever use guys, whatever use guys do that was that inclusive. You use guys, whatever you use guys do. it's gotta be above this amount per month. Mm. So you you've kind of delegated that to the team to say, Hey, bring me more revenue than this. Per month. And assuming that the whole team is included and involved in talking to customers in drumming up business, in reaching out and in trying to , make, make the number of what it costs to fund to, to run the product versus what the product brings in to, to, to drive that number apart. Mm. Not in a negative way. mm-hmm to drive that number to apart. If the whole team is involved in that, like your business development, just you you've you've went from business development, being all, one person's responsibility to business development, being everyone's responsibility. I don't see why you would try to hide that unless you were like I don't see a lot of good reasons. To hide all those numbers so, I mean, what you described was transparency. Hello? Right? One of the pillars. Yeah. So we should in, in my mind or, and in, from an agile or from a scrum pillar mm-hmm we should. Providing complete and utter transparency. Now, what I imagine that will do is all of a sudden it takes this kind of with them, it deflates the, with them mentality that what's in, it, what's in it for me. Right. So all of a sudden you're going like, Hey. Yeah, I wanna get what's in it for me, it's important that I, that, that I get my bonus or that I get paid and all those. Yeah. But all of a sudden, and, and particularly if in, if you were in a team in which you have developed relationships trust, and you are motivated, you are all in line with the, you know the vision and the strategy, and you are embracing it as a team. Mm-hmm, it becomes your baby. even more. So you become more accountable as a team. If you are aware that, Hey, you know what, we have to keep the lights on so transparency actually then fosters trust. And it also, it, it fosters additional innovation keeping in mind the minimal that we need to accomplish. I've been at one company, they called it, keep the lights on. So yeah, this is, yeah. These are the things that we have to do no matter what to keep the lights on. Yeah. Right. So these things need to be accounted for it's the over and above that we need to work towards mm-hmm so if we have a team that has an understanding, even if it's minimally, so, I mean, they don't have to get into minutiae and the details of all that. But all of a sudden we have somebody if, and, and they are they're onboard with our vision. They, they have an understanding and, and, and they're dedicated to this as a team. now to your point, they're going like, well, we need to surpass that. Yeah. You know, the minimum we need to surpass the baseline because we have an understanding of what that is, keep the lights on. Right. And we need to go above and beyond that. How do we do that? It also helps when we're talking about prioritization, sprint prioritization, mm-hmm . If they have an understanding of. That really does help with the prioritization of a sprint and how we might pull things in and get things done. Yeah. Yeah. Like going back to the previous category of unearned autonomy, like you haven't earned the ability to stand alone, prioritization is a great topic of that. Like once you do your prioritization and you say, Hey, we could do this, we could do this, but I think this is the majority to, to, to bring those people into that conversation.. To say, Hey, this is what we decided. What do you think about that? I do this a lot in backlog refinements. I invite a lot of people to backlog refinements and be people that are not necessarily on the team mm-hmm to backlog refinements because backlog refinement for me is where prioritization happens. And also backlog refinement for me is where the team has a chance to dig in or not to a lower level to be like, Hey, do we really understand X, Y, Z, right. X, Y, Z, for those listeners over the pond. Hey, uh it's but usually at back lower prime, we'll get. Way deeper than a lot of people want to get in to the discussion. And that like, that's fine. That that's part of why I bring people to backlog, like to say, Hey, we're working on all these other things. Plus plus usually if you're a product person that a different initiatives in the organization are sponsored by different people. So if you can bring in the sponsors for different things, you can let them discuss it between. Each other, and like, at, at that point you're just facilitator. You're just a moderator. Yes. You know, or, or, and they are refer, prioritizing themselves. a referee sometimes. Well, it depends. I mean, if you have something that like, I've been in a lot of organizations where you have CEO level discussions of like, we gotta have this by this date mm-hmm and like that that's it that's it mm-hmm the decision has been made. Mm-hmm , there's not really lot to this. There's not really a lot to discuss after that. Mm-hmm so bring those people. To your decision process and then yeah. You know, Hey, you're done well. No, what, what I would say is what might be enlightening for that CEO is to go like, yeah, CEO wants this. Bring them into the refinement session or even the planning, if, if you're at that point and all of a sudden you realize, yeah, you want this, but we can't get this until we get this, this, and this done what you're asking, requires us to prioritize these other things before it can happen. so it does help people to align and empathize with other P you know, parts of the organization. The other arguing point against psychological safety will be well, you're driving consensus. By a committee or the arguing point against us will be you know, oh, we can move faster. If, if we just go to our leader and ask him, should we do X or Y or Z or whatever, and he'll just pick something and that'll be the end of it. we can make decisions much faster that, that, that would that like, that's, that's where I was going when, when I was listening to that point. Gotcha. Just to back up just a little bit. So psychological safety I would like to hear your perception or definition of that, because what I'm hearing now might be aligning might not align a hundred percent with mine. So when you think of psychological safety, it sounded like from your description right there, it was basically the ability to make decisions on your own versus asking leadership for permission. Was it. So I would like to hear your definition of what that means to you. What does psychological safety mean to you? Not really. I, I don't like I like I'm terrible at demonstrating the other side of the argument sometimes. Like, this is, this would be one of the right, right. No, and that's terrible. The, the, the argument against in this perspective would be, if I'm empowering my teams with the ability, my teams, teams being, they each have a product representative, right. Who's carrying out if I'm the CEO, or even like a director of an entire business unit and I have five teams under me, five, seven teams, whatever. I need to go to those teams. I need like, I'll go to my product management meeting. With my five product managers and maybe their technical reps for all their team or whatever. And I'll say, Hey we, we need to do this new functionality. We need to be pressing in this direction or whatever make it happen. And then they'll ask me questions. They'll do experiments. They'll they'll they'll pick apart my dissertation from the, from the product meeting. So, so the, so for, for me in a meeting like that, the definition of psychological safety is they are number one. They're willing to ask questions in that environment. And number two, I guess, is different tiers. Number one, they're even willing, like I've been in organizations where all the teams are contractors. Like, Hey, you guys need to do this. And then nobody says anything. And then offline, they quietly figure out and fail and do whatever on their own. The, the better organizations in that meeting, the, the product, people with their teams will ask questions and try to figure out what they can do to prove or disprove my. Dictate my, my requests, my demand. It could be anything. And then they will question what makes you think that they'll ask for the why from me the leader, and then they'll go figure out what they can do to prove or disprove pieces of the why. And then turn around and implement that with their own teams. They'll they will run with my vision. I think that this is important to the market. They will take that and pick it apart and distribute it between the teams and they'll run with it. Mm-hmm right. They'll take my vision, break it up into goals between teams and try to prove it, disprove it, and depending on what they find, they'll run with it and implement it. Okay., psychological safety is tiers in my opinion not to cut the end of the podcast, but tier one is, do you even feel safe to question what I'm asking you? I, I guess we were talking about product psychological safety at this point. There's a whole nother side of psychological safety. This team related that we're not even getting into. I feel that there could be a whole nother podcast could cut right here and separate. So we're talking about psychological safety from my experience starts at leadership. So leadership's ability to not micromanage. Yeah. To be able to say I have a vision. and more importantly, and, and rather than coming into a, a meeting or making a, a demand, use the word demand mm-hmm . But instead of that, describing the problem that we're trying to solve, right. So I'm not gonna make a demand of you. I'm gonna describe, okay. Here's the problem we're trying to. You know, here's the, what mm-hmm or, and the, and, and, or the why, and maybe, maybe the, what we don't the, what they know and the why is something that the PO or product person needs to needs to determine. Right. Sure. So, so I would say that but psychological safety from my perspective, is it, it is that, that leadership that allows teams and individuals to be comfortable enough to your point, to even ask a question yeah. To maybe disagree. Yeah. Or have a discussion or be brave enough to come up and say, Hey, have we thought about it this way? So the point of you know, there's been obviously studies Aristotle being the, probably the, the. Famous Google's project Aristotle, but where psychological safety was determined to be the number one determination for an effective team and what that and, and you can go in and Google it. I forget the name of it, where they have all of their basically white paper and documentation that they have. I forget the name of it. Yeah, you can Google about it. Yeah, Google it. but they they determined that psychological safety was the number one factor in, successful and effective teams. Now, their initial hypothesis was the most effective team was to match up the appropriate personalities with the appropriate level of maybe education or knowledge base. Yeah. Or all that. They ended up finding that none of that was true, that psychological safety crossing across multiple you know, levels of experience and all that. But the psychological safety is what. Allow and fostered innovation because you come in sometimes with actually very little experience, but the right question, because you're not biased because of this long term experience. So, but if you're in a psychologically safe team, you can go, that doesn't make sense to me, or what have you ever thought of it from this way? And that starts with the leadership who. Allows that to happen with the knowledge that in a new team they're going to, that it's going to slow them down initially that it's actually going to impede their progress, but as they become more and more stable as a team, and that psychological safety is fostered and more and more trust is developed. Then people really start to learn their strengths and their weaknesses, both inwardly and within the team mm-hmm and then they start pulling and, and pushing to augment the team in the most appropriate and effective manners. we were talking about decision making via consensus now. Like, oh, well I don't, I don't want to have decision making via consensus because somehow that's bad. I mean, is it bad? Like I, I feel that the, the decision making via consensus is it bad? Like, or, or. Is that, not the question, like, it doesn't matter how many people you have in the room with coming to your consensus. Even if people are like looking at the evidence and voting bases based off of the evidence, shouldn't taking it an account, the evidence be more important than worrying about , oh, well, it's more important to have one dedicated decision maker, so you can, so we can make quick decisions. That's the point here is, is I'm worried about us making quick decisions versus getting stuck and bogged down and the whole analysis paralysis paradigm and getting stuck. That's the underlying concern here. I think if we have, so number one, the, the product, I mean, if we. If we have an agile organization. So the product person is going to be the one that make, that is ultimately responsible for this decision. Mm-hmm , if they are practicing transparency and adaptation and inspection, then this should be an iterative process. Yeah. And not something that is made just in one meeting in during during a sprint or every month or something to that effect. So. This should be an ongoing iterative process where everyone on the team would be. getting and providing information, along with, of course our, our, our review, which we're getting that feedback loop at the end of the sprint, if we're, if we're doing scrum. Yeah. Right. Yeah. so I don't think that it would be, there would be consensus by a majority, but not necessarily what it, during like one meeting, it would be over a period of time. Yeah. Right. Where we have you know, a consistent feedback. Yeah. So I think that, that you end up with a person being able to make a decisive decision based on consensus. Mm-hmm consensus over a period of time by maturity. Yeah. Yeah. Like I feel also like we've landed on like the, the arguing point against this one, which I'm, I'm not doing a great job fighting for it. The arguing point against this one is like the, the product owner slash manager on the. Is the person that makes this decision, this, this prioritization decision mm-hmm . So if you're having difficulty delegating, these big decisions to your product, people on a team like you kind of need to step back and kind of figure out what you're really doing. I mean, you could be in some kind of scaled organization where you have like a. Product person who does like your product person could be like, well, we, we did this and we did this. And, and the evidence leads us to believe this is the next thing we should do. And you're chief product person could say like, all of your evidence based decisions. I respect and understand. But I want you to do this next mm-hmm like, you can get that from a CEO as well in a small like, oh, and I could happen crash and burn. Yeah. So as a good product person, it would be my job. Uh ultimately it, it does come if you have a hierarchy like that. Yeah. Then you can be overpowered as far as decision making. But if I am a good product person, I should be able to present. Effectively lobby is what I was gonna that's my term for it. Lobby. Yeah. Lobby. Yeah, yeah, yeah. With valid data to be able to prove my point. Yeah. And to be open-minded to hear, from the other, the other side. So just, so there, there, if you have someone who's a portfolio manager, they have a lot of information that I am not privy to. Mm-hmm so once we are collaborating together, there may be some really good reasons why we need to reprioritize. So, as long as we have transparency and communication, then there's real opportunity to align. I'm sold. Hey, sign me on. Okay.