AA165 - Escaping the Feature Factory

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. If you read the book, Escaping the Build Trap,, and if you read any of the Marty Cagan books, you know what the feature factory is. And once you get over the fear of change and the fear of uncertainty, can I live outside of the feature factory? Can I learn all these new skills? Can I change and you've succeeded in getting over that fear of change and you escape the feature factory, Now what you will be enlightened We're gonna talk about Escaping from Alcatraz. I mean Feature factory. That's right. That's right. Again We're assuming that you've come into some sort of enlightenment a door has been opened for you and you see us a better way of working and you're going full in on it. I'm not like, this is not going to be the podcast about changing your organization or anything like that. Yeah, absolutely. the podcast idea kind of spawned from a couple of conversations I had with a couple of different people where they came to the realization that they had bad habits that they had to break and that it was, it ended up holding back their career at the time until they broke the bad habits. Right. And I've been in this spot too, right? I have bad habits. I know they're bad habits. Being self aware as a first step, right? Cause then, then you can catch yourself and that step is harder than it sounds for a lot of people because you're in that comfort zone. You know, you do things day in, day out, and it becomes the way you work. So unlearning that. Recognizes, sorry, requires a conscious effort on one's part. I'm going to do this. It's in, it was, it's with intent. Yeah. You can get into it. my thoughts on what this looks like in a feature factory? The, the waiting around for someone to hand you work for your architect. Or your senior engineer to hand you work assignment. Yeah, exactly. Yeah. That's one there are others that that we can get, get into as well. So working on something or a piece of the, the product in isolation, almost like in silo, right. Right. That's also a pretty bad thing, but if you recognize that that's what you're doing and you want out of that, what can you do? The fact that you recognize that, I think, is a milestone in and of itself. It allows you to say, here's the as is, this is where I am right now. Right? And then you gotta figure out where to go by recognizing the behaviors, the patterns that got you to where you are, right? That you're in currently. Once you recognize what they are, you can then look to changing those. So you gotta pick which ones you're working on first and then next, etc. First, next, later. Be open, be open to the fact that there is a better way and have an open mind essentially right to new learning, new ways of working. Yeah, this, this is one that we were talking about before the podcast started about you want to leave the feature factory and you want to go to a place that treats you better and you have better opportunities and, and you can advance in your career, but you have this bad habit where you, you find it difficult to collaborate on work items. You know what ? You can't, you can't, or maybe you, I think about I'm specifically thinking about a culture I had been part of where the peer review process is an architect who doesn't sit on your team, reviews every PR. So they may not know your customers or why you're putting this PR up. So everything is all completely asynchronous and, and you may not have visibility into when they're going to get to your PR. So they become more of a, an obstacle, really. Yeah. Right. Stage gate at the minimum. Right. And then like going from that to a company that either peers or peers when they need it and that kind of stuff. So it was like, who the, the, the PR, the mobbing that happens in PR is kind of done on the fly. You know, on demand kind of, it would be difficult. You know, to move from one culture to another. Yeah, definitely. So in the, in the culture where you have somebody who is of a authority position, like the architect, for example, right. And they insist on looking at everything. It could be a tech lead. They are a bottleneck at that point. And, but for them to go to the toward the other culture. Right. Well, for you to want to do that, that's hard. pretend we're all sitting together, right? We're all on a call. We're all on a zoom caller or whatever. Google meet teams, whatever you use. And. It could be intimidating sitting with someone who's reviewing your code in real time and giving you feedback and real critique in real time, basically on your code, because you've only ever done PRs like this with nameless, faceless or maybe they're not nameless, faceless, maybe they're, you know the architect that sits on the mountain and they're they're going to give you things and Send it back for work and reject your they reject your changes. They reject your change. So that, that's what you, you're expecting that, that. Rejection going into and then you sit down with someone that's like, no, I'm just trying to make trying to help you make the code better. I'm trying to help you and it's that attitude that feeling. I don't know. It's like people can feel that it's liberating when you do. I feel it's liberating because no longer is someone going to admonish you for what you're doing. Suggestions are then more kind of constructive rather than yeah. Yeah. The other way, right? Which is what are you doing? Right. But then on, on the part of the developer wanting to move into that kind of a change, I guess they have to be open to accepting feedback. You have to be open to that. Yeah. The the funny thing about talking about emotional intelligence, like sub, sub, they're not really skills, but sub skills, I guess they are skills of emotional intelligence, like the ability to take and give the, to receive critique, to receive feedback. Specifically, let's talk about receiving feedback. It that, that advancing that skill in yourself Not super critical in the feature factory, I would say. You're right, there's no room for it, right? Because in that environment, in that culture Everything stopped down and people are dictating to you essentially. I like the way you put that. There's no room for your emotions in the feature factory. Right? You're just a cog in the machine. That's exactly right. You're just a cog in the machine. And the, usually the financial model mirrors that attitude of we'll just we'll have a, A gang of developers will have 50 developers and we just throw work and throw it at the architect and the architect decides who's going to work on it and they have their favorite people and they have their less favorite people or whatever. Yeah, , I think of when we think about that model, I always think about the developers is like. Almost prisoners and the architects are the prison wardens showing maybe a slice of pizza, dried up, crusty pizza, and just get back to work. Otherwise known as development in the nineties and early two thousands right there, that was their model. But the first part of EI really is self awareness, right? So you've got to be aware that you are the way you are, and then you got to be aware that you want to make an intentional, intentional change. Towards something better or different, at least for now. You know, you think it's better. You don't know that yet. So you gotta be open and be somewhat vulnerable to your point about asking people for, for help, for feedback, right? Yeah. Yeah. The interesting part about moving from the feature factory mentality out to a more durable team product model, I guess we'll call it that because as Marty Cagan didn't call it agile transformation, right? But the interesting part about moving from a feature factory to a product model here is if you were in development in order to be promoted. Those skills that you need to develop are these EI skills, the soft skills, conflict resolution, your empathy, the ability to take and give feedback the ability to collaborate your ability to, to communicate and, and I think someone looking to leave the feature factory, like looking to leave that culture in a feature factory to say, Oh, these skills are not, these skills are not prized in the feature factory. Someone's going to listen to this out of context and be like, those skills were always prized. Sure, sure. But those skills are not prized in the feature factory as much as they are in the product model, in the collaborative very flat organization type of product model. So you would, you, you, you may not want to leave the feature factory because you're afraid that, your career has been stunted now. Because you never had to develop these skills. No one was ever pushing you to develop these skills. Yeah., so, so all along your career thus far, only your hard skills were assessed and valued, right? And now you have to learn these soft skills. Yeah. Often people's skills basically dealing with others, right. And not just sitting there at a keyboard, pounding out excellent code. Yeah. You know, the scary part about what you just said is you, you work in this teacher factory for 10 years. You're an expert at these skills or whatever and then like new technology comes along and Wipes that out. You know, I think of like there was a point in the market where God, what was the I'm trying to think of a couple technologies that got wiped. Did we hit that when? Object oriented technologies came about. That's exactly what I was going to say. I was, I was going to point to the early Microsoft VB language and stuff like that. Like that it was good for what it was like automation and stuff like that. I remember way early in my career, we were doing VB scripting for automation. And and then better languages came along, better tools came along, and all that stuff went away. The point is those skills have a expiration on them. I remember telling people in QA until when I was a when I was a manager in QA, I remember telling them get ready to, to, to like revolve your entire skill set, evolve your entire skill set about every three years, like the tools and languages and things that you're using now, day to day, three years will be 100 percent different, completely different. It's incredible how quick that turnaround is really., I, I, when I, the reason for that diatribe, the reason for that departure was to say like, what, what you said to me really scared me because I really believe there are people that are saying Hey, I'm, I'm an expert. Why would I want to leave the feature factory? It's comfortable making good money. You know, I can't, I understand what we're doing with our software, understand our products. Oh boy. Well, unless you're like three years away from retirement, that's not a good strategy. You know, you got to keep abreast of what's coming next. At least be aware of it and then make a plan for yourself. Yeah, , the competitiveness here is, you can say, well, , there'll always be a need for these skills. There'll always be a need for this, this NET development, the old school NET development the original COBOL. Yeah, COBOL. It's still around. Right? Yeah. Sure, it's still around. But the developers that are getting those jobs, first of all, assuming that they're, they've not just been there for 20 years and they're not going anywhere. Right. Assuming they have spots. Those developers that are getting those jobs are masters of the technology and they've got these skills. Yeah. Yeah. I think you have to have. These skills in order to ensure your longevity because the hard skills, they're going to churn very quickly. And this is the funny thing is we're talking a lot about developers on this podcast, which is, it's interesting, but also I started the podcast by talking about a product manager, leaving the feature factory a conflict resolution, empathy, the ability to take and give feedback. Especially take feedback, right? And not take it personally , I don't even know how you can be successful in product. I don't know how you get hired! I could see it in the feature factory., your domain, we talk about product management, hiring, you get hired because you're a business domain expert. Yeah. Okay. Well, you now you realize years later that you want out of this feature factory trap, right? Yeah. Yeah. Well, maybe now you know how development works and doesn't work. And whereas before when you were a product manager in a feature factory because you're a domain expert, and you just walk in the room and say, no, I've got to have it all by next week on Tuesday. Just get it done. I don't care how, I don't understand why it takes so long to do this and that you just didn't know. But, but you're the bull in the China shop because you got all these developers who they don't want to Kind of don't want to challenge you and then or maybe they're contracting, they really don't want to challenge you right now. You learned that this is not, this is not the best way to make quality. This is not the best way to make a product. There's not the best it's not a good way in any way, shape or form you've learned all these things. Yeah, for sure. I don't know. I think it's just across the board., we talked about developers and product managers, but you know, testers, anybody, scrum masters, for that matter, coaches., you have to have these skills to a degree or another, right? Especially in modern ways of working. You could be in banking. You still need to have These skills because without collaborating with others, you can't do it all alone. Right. let's talk about collaborating right quick, because in the feature factory, you, you, like you don't collaborate., maybe if you're the architect on high or the program lead or something like that, maybe you'll go across programs to collaborate, but , collaborate only so far as you can claim ownership of something. Yeah. We'll complain about dependencies. Right. Yeah. Right, but the collaborating communication, collaboration, when I think about the team's facilitation, like these are just not these, these are not skills that are, I was going to say they're not highly prized in corporate America, but that's not really true because the people getting the promotions, most likely they've got these skills. That's right. In addition to hard skills, perhaps, but definitely these skills. So now you've got this person who's recognized that they need to develop these skills. How do they go about doing that? Right. What's the first thing they have to embrace when they do this? Well, if they are currently working in the feature factory, the way they do it is they do it on their own time because you don't do it in the feature factory. There's, there's no budget for training. It's not you, you have to ask. Okay. To use training dollars and then you most likely will get denied most likely your training dollars are are insufficient to cover the cost of a modern training in a modern organization Yeah, so you got a like kind of scrape for you know, something here and there type of thing So that how are you doing a feature factory? I don't know. You do it on your own dollars. That's what you do. I think that's right. You do., you've got to be super motivated to do that and your day job, but you've got to do this for yourself, right? Cause you want to change you because you can't change the culture. We're not going there today, but yeah, definitely doing it in your own time, develop these skills and then it's not just like reading a book or You know watching a video, you could practice them. It could be it could start that way Yeah, learning this the matter itself Yeah, okay, but yeah practice these skills and maybe you could start doing that in a feature factory slowly Yeah, right without upsetting the apple cart. You certainly could try if that's outside of the scope of where I want to go on this podcast, but you you certainly could one way to do it would be, if you wanted to kick off trying to change your work environment, definitely And your culture, you could do a pilot program using these concepts to try to cut across programs or whatever., assuming you can even cut through the resistance of one of these heavy, heavy feature factories, right? Or if you have a PMO or something like that, right? You could try a pilot program and then get yourself some wiggle room. And even if the pilot program fails or they don't want to do it or whatever, like you still got some skill. You know, you still learn something out of it. Absolutely. And you got to keep that resume updated too. Yeah, I agree. I think starting small within your team, perhaps work with your product person and say, can we talk to customers, right? We're going to understand their real motives, what they want and why they want what they want, those sorts of things. It takes time. That's the thing you got to appreciate. It takes time to build that or start to formulate that new culture, even if it's a microculture within your own team. Yeah. the other thing we sort of touched on was that, that feeling of control that you have to be in control. And if you're moving to a more agile way of working that is only going to hold you back. The feeling you have to be in control of everything. You have to be okay of letting go. Of control. Let me, let me step back. Cause people are like, okay, I'm, I'm okay. Letting go control. Okay. Let me challenge you for a second at your company. How do the decisions get made? Like, do the decisions all get made by one person and then all, and now they top down and we all gotta wait on that one person? Is that how the decisions get made? You know, are the decision makers, the individuals on each team is, are decisions decentralized and pushed down to the teams, or does one person at the top make them? And when you say, oh no, Brian, the teams totally do them. Let me go, let me, let me climb that ladder and say, well, out of the decisions that your teams make, how many are related directly to business goals? That letting go of control, it does work, but I feel in a lot of company and probably like 90 percent of companies, it works up and you keep climbing up to a point, you get to a point in the company where it doesn't work anymore. That's the ceiling you've reached. Yeah, exactly. I agree. So this is one that needs to be unlearned because, even though you unlearn it, it still is in your company somewhere. Kind of haunting you when you press against it. Yeah. And this again is a hard one to win across your company. Right? So try and do that in that little pilot that little pilot that you're a part of. Hopefully people can see how it's working in that pilot and hopefully it'll catch on that. That's really it. When you have those successes. Sure, go ahead and evangelize them, right? And, and bring other people up to speed and say, we're working in a slightly different way and it's really effective. If you want to come in and watch or go and talk about it with them. Shared ownership is a difficult concept to, to, to. We, we did a podcast one time. I don't remember what it was called and I'm not going to find it right now because I'm not doing it. I'm not digging through our back catalog. Nope. You can find it and find it and throw it in the comments and let me know what it was, but we did a podcast one time talking about if, if nobody owns it, if multiple people own it, nobody owns it. Like that, that, that type of thing. I remember that. And shared ownership is a difficult concept to go from the feature factory where one, there's one and only one neck to choke to this, where it's a, it's a team that owns something. Yeah. Yeah., it, again, I transitioned from the former to the latter, right? Shared ownership or collective ownership, unless you've got that trust among your team members. It's going to be hard to implement something like that, because I have specific skills and I know I'm going to do a good job of whatever it is I'm working on for me to entrust someone else with that. First of all, I don't know how the quality of that's going to be, because I don't know their skill sets, right? In other words, I don't necessarily trust this other person, Mary, Fred, whoever to do a good job, and it may not be. the same quality of job that I'm doing. Yeah, . But you know, this idea that the team owns the work of the team that once you have that understood among team members, they start to Get around the trust issue a little bit more. And, and this goes both ways. This also goes top down, right? So top down when someone who's above the team in the hierarchy of things, once they feel like they want to just let go a little bit and trust the team, what they get back is of a much better quality. Cause now the team's empowered to make decisions, right? So. You know, it's got to start somewhere. Start with yourself, whoever you are in the hierarchy. Start with yourself and start looking left and right and maybe extend your arm across the aisle and say, Hey, how can I help with that? Who can help me with this? That is the other one. Feel free to ask for help. Yeah. You know, that doesn't mean that you don't know what you're doing. Right. That just means another pair of eyes on the work. We'll, we'll make it better. That's a good call out right there because in the opposite of letting go of control, seizing control, that, that is what it means. So, Oh, what are you saying? You don't know how to do this. Does that mean that maybe you're not the team that I thought you were, or maybe not yet, but we wouldn't be talking about team. We'd be talking about individuals but why am I spending this money on your team if you can't do this thing or whatever, but you're right. We released something and it wasn't exactly perfect the first release. And so it's all terrible. Yeah. Right. That binary. Yeah. And the, and the, and the idea that if we release something, oh, the, Oh, we're never going to come back to it no, we're like, we're putting out a small release and we're going to stay on it until we all agree that we move on to something else. What you said a couple of seconds ago you, you didn't say it exactly, but you said trust. You default to a mode of trust with the other teams that you work with. As opposed to defaulting to a mode of trust. Mistrust? Distrust? Mistrust, yeah. Yeah, exactly. But that transition too, it takes time because you've got to let go of that control. Yeah. Right? And the fear that you have that if I let go, someone's going to drop the ball and I'll get blamed, right?, in that scenario, you really don't have collective ownership. You're owning a piece of it. Everybody's owning a little piece of it. So you may as well go into your corners And develop something and come back and hopefully it'll integrate., that just doesn't work. We've known this for a while. That doesn't work. I mentioned that we're going to stay on this. We're, we're going to stay on working on the thing until we quote, get it right. You know, until, until we evolve it to the point where it's accepted and everyone's happy with it to a certain level. And then we cut, cause we got other things to work on. Right. You can't really do that if ambiguity and uncertainty is a foreign concept to you You know or or a hostile concept Yeah, you want the comfort of of certainty, right? You don't want to have any wiggle room in what you're doing lest it be interpreted as wrong, you know? Yeah, and I this, this this is, this is past just like, Oh, I delivered this one thing or I delivered this release this, this goes off to this goes off to your, your processes and your plans for work and your how you, how work is broken down and to what level of detail before you start. This all, this, this all is pervasive through every layer of the organization. Because I've been in organizations that say, Beau, before we start on anything with development, before we engage the development teams, we have to have everything planned. Everything up front, yeah. The developers are the most expensive, quote, resources in the organization. I'll tell you how many times I've heard that. So before we, quote, waste their time, we have to have all the, quote, requirements done up front. Right. And then we bring it to them and then they do it one at a time. We get sign off before they accept their resources. The development resources are nothing more than basically. Dare I say it? Code robots, a better phrase, they're not knowledge workers. They're not required to use their ingenuity in any way to ask questions that maybe others didn't think about. You're just saying go build this. Yeah, right. That's horrible. But that is exactly what happens in those in those cultures. So you don't have it. The authority to say, oh, but why do you want that? You don't have that. Because you're told, hey, stay in your lane, bro. Yeah. Right? We're telling you what to do. You're a developer. Go develop. Right. And the planning up front pieces is, is important here. The best made plans up front never materialized the way they were planned. They always have to change with the passage of time, even if it's short time. Right. So knowing that, why would you bother? It's expensive to plan up front and then have to rework your plan when the inevitable happens. Why do people still do that? It's beyond me. You got me. It's like, look, if I bang my head on the wall, it hurts. Look, I'll show you. I keep doing it. It's like, come on, stop doing that. It's, I think it's exactly the category we're talking about. They're not comfortable with uncertainty sitting out there. All, even up to the point where they are willing to spend money. It's beyond me. To feel like, even though the numbers and the evidence after the fact, tell them that, Oh, these projects are only 14 percent successful. They come in on time on their budget or whatever that even though they know statistically, they logically know they want that feeling. We should do a podcast on feelings versus logic in software development. I like it because it's so much stuff like this, like they will pay extra and they'll spin up this whole organization, this whole. project management organization that that just gives everyone feeling you know, feeling of control, feeling of control. There's, there's science there. It's okay. There is science there, but yes, this feeling of controls like to your point, projects are successful when they're What? Right. 10 percent successful for 15, 15%, 50%. It doesn't matter that definition is not there to begin with. So I was going to, I was going to fill in what you just said. Projects are projects are successful when like all of the variables are completely known and don't deviate during the project. Projects are successful. Like if we're going to build where, if we're going to build a, people love to talk about building a house with regard to development, they love to make that analogy. And I said, sure, you're going to build a house in the exact same geographical area. So the, the soil and the earth is exactly the same with the exact same materials in the exact same configuration to the exact same plan with the exact same crew. Then yes. Yes. We can tell you how long everything's going to take after the first one. Yeah. Yes after the first one. Yes so that's really yeah, that's really a Mechanical factory right there. It's like, you know what it takes to stamp out the house, right? Right and if we roll all the way back to how how all these people learn this we roll all the way back That's we roll the clocks back to taylorism our friend on this podcast, It makes total sense because he spent extensive amount of time studying workers, working in different ways to figure out what the best way was. And then he wrote down, you should do it exactly this way. And everyone looked at that and they skipped all of the, how he got to those learnings and they just took the checklist and said, okay, we got this. We will just write a checklist and that'll be it. There's always going to be some variable though, that you don't have control over. You know, in our analogy of building a house, whether it becomes a variable, you built the first house, it was sunny for a whole week or whatever it took. And now it's not thunderstorms and you started to frame the roof, but now it's raining. That's right. And the house is flooded, right? Yeah. This is always variables. So the best made plans really need to change. Yeah. So like I like to tell people when they ask me about scrum, I like to tell them scrum is just enough, just enough process to temper the chaos. And that is it. That's all I'm looking for. Just enough. So that everyone kind of understands what, what the next goal we're headed towards looks like. And that's it. Right. That's all the process we need. And then people usually listen to me and say, you're, you're just being ridiculous, Brian. And I tell them actually, It does work. It does work. It's a lightweight framework. It does work. It's supposed to be a lightweight framework. That understanding that it's balance, the balance of structure versus flexibility. True flexibility would be every day we come in and we look at the plan and we decide if we just want to throw out the whole plan and should be open to that. Oh yeah. We should be open to that., we're not, we're not writing anything down. You know Everyone eats pizza at 7 00 a. m But we need to stay up all night. We don't report anything to anyone with unlimited money unlimited time You know I don't think that world exists. I don't think it does either so it's but there's Doesn't stop people from criticizing agile ways of working saying pretending that it works like that I agree. Absolutely. You're always gonna get the naysayers. Moving on to something else that I think is the cornerstone of moving out of the feature factory is you may run into some things moving out of the feature factory that directly conflict with your personal identity, right? I'm a, I'm a great, I'm a great let me try to think of what, what I'm trying to think of something making, making it personal to me that moving out of the feature factory. Oh, Oh, I know a good one. I know a good one. Uh, moving out of the feature factory for a product manager. Right. Hey all, all those people's strategies are terrible. I can come up with a great strategy. Nobody says that coming up with a great strategy is Difficult, right? You thought you were a great business person or whatever, because, cause all the strategies you were engaging in the feature factory, we would just sent you to the moon and back. Oh, he's just signing up left and right. Then you change companies and you found out that like all your strategies don't work and maybe you thought you were not as good as creating a strategy and executing a strategy or you know, the other the other one is actually a much better example. The other one I've seen is. People selling themselves as I am I am a what's called not executor. I'm Oh, I'm a, a software delivery expert, a delivery expert. What do you do? Just put it on your back. I can, I can whip a team in the shape and have them delivering fast, fast delivery Om. And people sell themselves as a delivery coach. Great, great software delivery. And then they get coupled with the team. That just can't deliver the, yeah, that's it. Yeah. Now they have to question their whole identity. The other the other role that falls along with that is a process coach. I'm a process coach. I can improve the process and get the teams ship shaped. They deliver and yeah, it's quite revealing when when you recognize that he's not working the way you. orchestrated this plan both in your head and you try to install your plan upon the team, right? And they rejected it or it didn't work. They wouldn't outright reject it necessarily, especially if you had positional authority, but you know when it doesn't work It's like ah, yeah, this is on me, right? So that revelation is something that you should really absorb and say, should I be working in this way? Right. Seeking help and, and, and getting other people's opinion requires you to really become somewhat vulnerable and say, I need help. It doesn't mean I don't know what I'm doing, right? I bring expertise, but I value your opinion, your expertise as well. So it's respecting someone else's skillset and what they can bring. Yeah. I wouldn't say above yours, but necessarily like, okay. You are not the whole and soul person who can do all of this by yourself. So get some help, think about the analogy that we have of people like rowing a boat, right? Every, every rower is important. And they need somebody to keep the rhythm, but yeah, you get, it only takes one person to not understand the pattern and their. The boat goes around in circles, basically. I like this category, personal identity. You built your own identity around your work skill. You know, your, your, your, your skill or your expertise in one particular area or something, and I think about people that have built their expertise around a particular product that a company has that they work for, what happens when they don't work for that company anymore? Like they don't have an identity now. They, they don't know what to do with their life now. Like that's, that's tough. It is tough. A lot of times people, when they have this personal identity that they formed over many years, possibly they feel like it's, you know. It's solid. It's like you don't knock that that's who I am. You know another I'll give you another good example Of somebody building their identity around One of these things C level executive. I'm a great leader sure cuz I'm a C level executive Yeah, and suddenly People are leaving, they can't they can't coach. They can't, they can't give feedback nor receive feedback. They're a terrible leader and they're not coachable. Yeah, yeah, exactly. You're right. That's a good example, actually, because you live in this aura where you believe you are a superhero, basically., I don't know where we're going to go with this category because all, all I've ever seen, this is be a blocker to a person's evolution to the next step. I've, I've really seen this., I only other, I only bring this up to say, unless you have something prophetic, hopefully you do. I only bring this up to say be self aware about this, like the way you perceive yourself for whatever reason that it is it really could be undermining you and, and look, and Oh, and the other thing is, is you, we would post something like this and people would say, what's wrong with working in a feature factory? It's, it's not that bad because again like now I'm challenging their personal identity, you know? Oh, I'm maybe I'm the one in the feature factory that tells everyone what to do. Maybe I'm the architect. That's my, that's my identity now is I'm the guy that tells everyone what to do. I'm very important. Yeah. Yeah. Well, enjoy your life as long as it lasts in that company, because you know, another company that you might go to, cause your company goes belly up or whatever happens. You good luck getting hired. They may not prize that kind of a person, right? They may be looking for those soft skills. They may be looking for some leadership and if you don't have that you're probably not going to land that job. So the next thing I want to talk about is building trust. Building trust, because again, you leave the feature factory. There's really no value in doing this in the feature factory. You told what to do. Why are you still here? Get out of my office. I don't want to talk about building trust, but when you move into a structure that's more flat, especially in product management you have to have a lot of one on ones, a lot of calls that are just getting to know you type of calls. You have to manage personal relationships. We flashed the Roman Pitchler stakeholder management quad on the, which I might link in this podcast. If, if I'm, if editing Brian is gracious to us, you never know what you get out of that guy though. Building relationships with people at different frequencies, different touch points, depending on how important they are, right? All that is meaningless. In the feature factory, maybe nearly nearly meaningless. Yeah, exactly. You may on the off chance encounter somebody who might understand one or two aspects of this. And that's about it. Only when you're trying to get something out of somebody. Of course. Do you need to do that? Right, exactly. Building trust is a great topic. I feel you know, how do you, there's no real, there's plenty of books, first of all, that talk about this. But. How do you implement that advice that you read in the books building trust? Well, first of all, I think you've got to, you've got to know the other people to point about these calls, you've got to know the other people that you're working with. You're not working with parts of another machine or anything like that. These are individuals, right? They have lives. They have families, they have this., so get to understand your colleagues as colleagues. Yeah. Not as titles essentially. And once you understand them, you may find that you have things in common with them. And now you can start to formulate that trust. Another way to put it is you could, you could start to break down the trust barrier between you and the other person or people for that matter. And yeah, , look, there are things that can help like team building exercises, things like that can help, but they're not enough because you yourself have to say, okay, I trust you to do this or I trust you to give me your opinion. So that's the extra step other than just simply the gamification of it. Yeah. the other thing about moving to like when you're kind of shopping around for another culture and you're in the interviewing and you're asking questions about Hey, what do you, what do you guys do organizationally to continually build trust? Oh boy, I don't so when you ask that question, sometimes you get you get responses like, well, we have a Friday pizzas together or whatever, right? It's not really building trust., I'll take a pizza. I like pizza. Never turned out a pizza. Oh boy. I can't nevermind. No, it's so that you, you get those kinds of things, right? We have a social room where people can Play. Yeah, right. Foosball, right. During that day, if they want, that's not really building trust. Right. So I think that the new generation is looking beyond that, right? They're looking at the actual culture and see if their voice is heard. Do they have opportunities to contribute elsewhere other than just what they're hired for? So if you're if you're in that organization, you want to build trust, open these avenues up, right? Let people have some time. To do some skunk works type of work, right? Just go court something. It doesn't have to be anything that you necessarily put into your product. Learn something from that. Do some skills building without micromanagement, without micromanagement. Exactly. That's, that's the key here. Yeah. Autonomously basically just say, go go spend half a day. And, and. You know, collaborate with one another and see what you can build. Yeah, in product management they sometimes have a difficult time with that because they'll say, Oh, well don't work on that because that's this other product, or that's the, that's the purview of this other product. Well, You can, although I'm not the biggest fan of fluid teams, that kind of concept. And that's a whole nother podcast. You can bring the work to the team, even if they have to reach across program or another team's basically the default behavior should be trust Hey, we want to do this thing. This team's overloaded and their stuff is all priority. Can we use this other team or this other roadmap or whatever to accomplish? Yeah, sure. Sure. You can. You know, I think on the path to building trust, you gotta lead by example, lead by example, people mimic the behavior they like. So if you do that and you're seen to be the person who trusts others, hopefully that rubs off on people, you know? And when you see someone trusting someone or asking someone's opinion or something like that. Go ahead and call out that and say good job on doing it that way. Right. Yeah, that's, it's a slow battle, but you can win it. Well, speaking of calling out wins let's, let's talk about that one because I feel like in the feature factory, the only time you get any attention is when you screw up and celebrating small wins it may be minor to people listening to this podcast that maybe, maybe not, I don't know. But. Something as small as the achieving a sprint goal or putting out an MVP and getting feedback from it. Or like demonstrating that you've successfully moved to smaller, more frequent releases, or that you came online with some CICD technology that allows you now to release. On demand instead of holding everything to the end of the two week sprint or Lord forbid Three months or whatever, right? Celebrating small evolutionary wins In in your teams and their technology On a regular basis. Usually this stuff falls between the cracks because it's again. It's it's not anyone's Persons, you know The manager's job to put, put the stuff on a list and show it at the company meeting once a month or whatever but a leader should be aware of that this is important, right? First of all, it's super motivational for people. If you just give them a pat on the back, right? So if you're a good leader, you know this and it costs nothing. Right. To do this. Right. That's the thing. The barrier is so low, right? Come on. Why would you not celebrate with small wins? Why you would not is because you, in the feature factory, you are, you, you have been conditioned to this culture where getting attention from management is only ever negative. Right. And, only when they're, when they're positive, they're being disingenuous because they want something. Yeah, that's the culture you're coming from. So you, so you're, so when you, when you get, when you're celebrating small wins, you're expecting the other shoe to drop. You're expecting something negative to happen. And you have to realize that, Oh, this is a bad behavior that I programmed. It's been programmed to me. I don't know that, that I've been conditioned with. Right. You got to break that because again, it's going to hold, like people will feel that. You know, definitely, definitely. You're right. And unfortunately in those kinds of environments, feature factories, it doesn't matter if you just say it for the sake of saying it, people know that. Right. And so, yeah. And, and some, someone who makes a mistake or the team, whatever small failure there is we're talking about celebrating wins, but if there's a small failure and the team. Reflects on it and learn something. Celebrate that and just say that that was a good lesson learned. But in the feature factory, the teams just basically keep their heads down. Right. And just do things they don't necessarily retrospect. Yeah. There's no time for that because it highlights the failure. Yeah. It's looked down upon. That's exactly where I would seek to build this in. I'd build it in with time after the retrospective. You know, maybe if, again, if you're in person you have a little more opportunity than a lot of teams have. If you're in person you have the opportunity to get everyone together. Do the retrospective for lunch and then take everyone out for team lunch to celebrate. It's their favorite day. Sure., it used to work really well before the pandemic when we did that on our teams. Yeah. It was great. free food always makes me happy. I don't know, it tastes better. That's why at the end of the day, the pushback against it is we don't have budget for that. Right. And I laughed and I'm like, the amount of trust you're building and the camaraderie you're building, come on, how much does a lunch cost anyway? any team should be able to lobby for that. And again, you got to have, Someone on the team that says, Hey, we need to do this right again. Be bold, be brave to ask. As you never know, you might get a try, try it. Just say, well, let's try it for a couple of sprints or whatever. And you see how it goes. I'm telling you now, free lunch is always appreciated. That's a great motivator for me, especially I'm getting hungry just now talking about it. You mentioned failures. And that made my brain think you have to adjust where failure and setbacks are not a four letter word anymore, where failure and setbacks is just viewed as a normal cost of doing business in developing new things. Right. And in software development, I think we have a podcast on this. I thought we did. We did. Yeah. We have a podcast on failure. Right. We did. So here's the dichotomy I have. If a team fails, then in the feature factory, it would be like, well, you didn't get the requirements, right? So next time do a thorough job. Right. Right. Cross all the T's, dot all the I's, and get sign off in blood. So it kind of works against you in that culture. We didn't test this well enough. Yeah. So now, now everything's got to spend more time in testing. Yeah, I know. Yeah, exactly. So the focus is in the wrong place in that case, obviously, right? So that contrasts to the other culture where failure happens, right? And people dust themselves off, get up and say, I'm Well, that didn't work. So we're going to try something different again. We've talked about this on several podcasts. If you're in that culture where people are saying, it's not necessarily saying it's okay to fail, but they're saying, they're not saying it's bad to fail in that culture, treat things as an experiment, right? So retros are a good idea. After the retro, you just say, look, well, we're going to try differently. And it's not, this is how we're going to be from now onwards. It's. Try for a sprint or two. If it doesn't work, feel free to change up, but push that decision of adopting something or a new practice or a pivot in your practice or whatever onto the team. So how do you want to change the way you're working now? And why don't we try it? When I think about a company or a team that's not okay with failure, or that seeks to find blame and cast off the blame, right, cast off the failure, I think about teams that I've been on that have been like this, where the management has no patience for anything other than whatever the plan was. That we started on right they have no patience for any deviation from the plan Even though the deviations were for the right reasons. They don't care because you share you share the plan with them and it became A set of expectations, right? You're gonna deliver on this date that it says so on the Gantt chart Yeah, and you say yeah, but you know They don't hear the rest of it. Yeah, but organizationally they also have no resilience basically, correct? Like they can't handle any deviation that you know that they have they have they probably have very little creativity organizationally At the same time, well, they certainly have very low to no trust because the person who is looking at that and admonishing the team is reporting up and feeling the same from his or her superior and it goes on and on like that, right? So that's pervasive in the culture, right? If you're in that kind of environment stick to your team and try and change from that level and see if it spreads. If not, we always fall back to our other advice, keep your resume updated. Yeah, yeah, I , keep their resume updated always is valid. But at this point, I assume that your resume is updated because you do realize that you're, you're sick of working for management that has no patients and and have to have everything planned and can't do anything out of the off the script basically. Yep. Yeah. But you know, again, the, the idea with this podcast is that you've already taken the leap that you need to change and you want to, but you've you know, you got all these bad behaviors holding you back or these, and they may not be bad. They served you well up until this point. Right. But if you want to evolve. You got to change. Yes. Yeah, exactly. So hopefully we've given you something to think about if you're looking to escape the feature factory. Escaping the feature factory. Yeah, let us know your thoughts in the comments below. And we're always welcome new topics that you'd like us to tackle.