In this episode of the Arguing Agile podcast, Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel explore the importance of asking for help across various roles, including developers, testers, UI/UX designers, managers and executives.
The podcast explores the common reasons people avoid seeking help, such as ego, fear of appearing weak or incompetent, and cultural factors.
Listen to this podcast if you want to discover the benefits of fostering a culture where asking for help is encouraged, and learn practical tips for instilling this mindset in your team.
Whether you're an individual contributor or a leader, this episode will provide valuable insights to help you and your organization succeed through collaboration and continuous improvement.
Keywords:
asking for help, collaboration, coaching, leadership, team culture, developers, testers, UI/UX designers, managers, executives, ego, fear, incompetence, Toyota Way, agile, scrum
= = = = = = = = = = = =
Watch it on YouTube
Subscribe to our YouTube Channel:
https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
AA168 - Why Asking for Help is Critical for Success
welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. On a differentt podcast, near the end of the podcast, we said, get help. We said, do all these other things we suggest, but also ask for help. I don't know, for some reason, a lot of people find it very difficult to kind of just say, I don't know, so I should get help. So this podcast is going to be helpful for those people that have struggled with trying to put their hand up and say, Hey, I need help. Also if you're in a coaching situation and you're finding it difficult to interact with people who are uncoachable or are very resistant to your coaching techniques. Let's put it that way. That's a nice way. You're swimming upstream with them, with your coaching. That there might be another podcast in the offering on coachability, I think. Right? Cause today we're going to focus mainly on this one topic, asking for help or get help as we call it. Getting help. I just finished the Marty Kagan transformed book, for example, In the Marty Cagan book even he says the modern manager in an organization, coaching is a large part of your job. And if you're not doing coaching what are you doing with your job? Like what you're, you're a manager. This is, the purpose of a manager in, in the modern day the 2024 or whatever year it is that you are listening to this. Yeah. I mean, he's right, but also this is not very prevalent. So unfortunately a lot of people don't see their role as being a coach. You know, they just basically say, we're going to hire somebody for a skill set and some expertise that we believe they already possess. We're paying them for it. So they shouldn't need to be nurtured further in order to be more productive in our organization. Yeah. And there's nothing further from the truth because even if that person has the best skill set that you can possibly hope for in a person in a role, let's say they don't know your business. They don't know your domain. They don't know your culture. They don't know your politics, right? They don't know your customers. So they need help and give them that help so that Everybody can succeed. If they succeed, you succeed. Unfortunately, a lot of times people don't see it that way. And a whole host of reasons. I mean, it's like turf protection playing politics, especially if they weren't the hiring person and all of these things come into play. So this episode is going to be helpful for people that have wondered, should I put my hand up and say I need help? Or other people that say, Why are people asking for help? So it goes both ways. So we're going to tackle this by personas, Who, who is it that might be seeking help? Yeah, so kind of the structure that we talked about for this podcast is to talk about the persona, who it is that you normally interact with who may need help, may need to ask for help. And we're going to talk about the reasons that they do not ask for help. Right. And then we're going to talk about some of the benefits that if they, if they were. Kind of free of the burden of some of these things that we're holding them back. What, what, what they could gain, what their gains could be. It's about gains, bro. Guess what? Gains cashing out and bro-ing down. Let's dig straight into the first category, the most relevant category for us, which is. Developers. if you've ever been on a team where they resist collaboration, it's like six, seven, eight people, 10 people, and it's 10 teams of one. They all come and say, I got my work item. I'm working on it today. I didn't finish. I'll be working on it tomorrow. No blockers. And then you're left there saying like, What? I don't understand your first reaction is I'm in utopia. There's no blockers. We're gonna be great at the end of the sprint. I think a lot of that at the developers level comes down to like the amount of psychological safety that exists or doesn't exist in the team, right? They don't necessarily feel Safe because they're looking at other developers, their peers, and they should be really linking arms, so to speak, metaphorically to lift the sprint goal over the finish line. But oftentimes what happens is they're hesitant because they're afraid Of how they're going to be perceived by their peers, right? If I ask for help, it means people are going to know that I don't know what I'm supposed to be doing. And I can't have that image of myself out there. I feel that one, like that human element of, oh, I'll be perceived as weak or I'll be perceived as not confident or whatever, like inadequate. So that's going to be a through line for every single persona that we talk about here. Yeah. So that's a good one to get out of the way right away. the concept that asking for help in any way, shape or form, especially in a collaborative modern development environment is perceived as weakness. Your tech lead, your managers, they should be the first people to identify, Hey, you have some odd hangups because of bad places that you worked or the way that you were raised or whatever, Here, we're safe to say we don't know how to do something, and then to ask for help. I don't even think I would be able to be a product manager and say, I don't know something. I expect like definitely early in my career where I was in QA and also doing a kind of dual role as a business analyst. I mean, the bread and butter of the business analyst is, I don't understand this. Can you please explain it to me? Can you please tell me more about whatever, XYZ? Yeah, I agree. And also, coming back to the persona that we're discussing now, developers, it should also be their , bread and butter, or whatever, right? I mean, whenever they're in a meeting with, let's say, their PO, or at the refinement, Or a customer, yeah. Stakeholders or customers. They should feel safe to say, can you tell me more about this? I don't quite understand. There's nothing wrong with saying you don't understand. You're not expected to be suddenly like the genius that understands everything. You know what the funny thing about that is, a lot of developers, They'll say, oh, you have this problem? Oh, I have a solution for that I have a solution for that. But wait a minute. You haven't heard the whole problem yet. They go straight to solutioning, which is a huge issue, right? They don't know what they're trying to solve for, but they have a solution for whatever the problem is. We've already solved that. They were already thinking ahead to the solution. And that, that's an issue. That's a real issue. I think that's also. compounded with some of the personalities I've seen, and I'm not saying every developer is like this by any stretch, but a lot of developers tend to have pretty big egos because they've worked in this technology and that technology or the ex Google. So these people feel like it's beneath them to ask for help. It's like, it's going to be belittling for them, and that is completely not right. Well, that's, Pride and the ego, either or, or both. That is pride and ego. One fuels the other sometimes. so I understand pride and ego. I would hope that your culture is vetting that out in the hiring process. And if it's not vetted out in the hiring process, I would hope that your leadership, management, whatever you have in your company, I would hope that they are constantly screening and watching out for that and having one on one kind of counseling sessions to say, Hey, I've noticed that you don't seem to ask for help, or I've noticed that you seem to take big things on your shoulders, and are working nights and weekends or whatever, well listen, I appreciate the extra effort, but wouldn't it be easier if, you know what I mean that's the opportunity for some coaching right there. Some of this is what we said well, you're afraid to get help and asking for help is an invitation for coaching. But if you are not open to coaching in the first place, you have these ingrained habits , it's a pretty visible trigger, I wanna say, to invite a coach. To say, Hey why don't you think about this to invite some coaching. but I also understand that somebody with a certain level of pride or taken to the extreme arrogance is not going to be open to coaching. They're not even going to be open to you're saying, Hey, why don't you hey, we got some junior team members. You seem. Very knowledgeable about this type of solution. Why don't you include them in your architectural brainstorming and whatnot. Yeah, and, for that specific topic, like being open to coaching or not, I think we're going to do that separate podcast for that. but a lot of times to your point about the culture of the organization, I've also seen Environments where it's frowned upon to ask for help. I'm talking about management here. Right? Sometimes even leadership. Unfortunately, they look at that behavior and say, How come you don't know? We hired you. Aren't you an expert in all of this stuff? You should know. I was in a development environment one time that, that, I remember the phrase, it was so and so Brian always needs help to complete his tickets. And that's, that's really a slight on Brian because he's asking for help that, that's a shame because that should be the opposite. It should be turned upside down and say, oh, Brian needs help. Who can help him? Right. Go ahead and pair with the guy and go figure this out instead of, why does he always need help? Maybe we should replace him because he's not working out. the implication is all of my other developers are able to take a work item and finish it by themselves without peering with anyone, without any help. Yeah, that's the implication. You're right. And that runs counterculture to this whole fostering of the steam spirit it's really leading towards people trying to become heroes by themselves and that's a shame that should be a red light, by the way, if you're a coach, if you see that you should say to yourself, Hey, what are we doing here? Right. Yeah. Yeah. This podcast is all about red lights. As you can see, We probably beat this up enough, but we didn't talk about the advantages of a development culture, where asking for help is a normal thing. Is completely okay, not only just okay, it should be a normal thing. Hey, I haven't seen you ask for help in a couple of days. What's going on in, in that kind of culture. Cause I've, I've been in both. I've been in the culture where everyone's expected to take a ticket, go back to their corner and be completely left alone. And if you need help, it's a, it's a slight on you a pox on your house or whatever. Apparently we're a middle English peasants now, but I've been in the other. And it, it was, it's a stark contrast because what you end up with, where, where the culture that's looking out to say, Hey I, we're going to leave you alone to work on what you want to work on for a period of time. But if you go, a day without kind of bringing your head above water for a breath. You know, we're going to check in because we think something's wrong. We think maybe you're stuck on something. I had a development manager. Actually, he was a, he was actually a excellent developer, terrible manager, but excellent developer. And he would say, when you get in the code, you get to a logic problem. He's like, if you're stuck on something for 15 minutes, you can't figure it out. He's like, stop what you're doing, go to the next cube, and get whatever developer is available. You know, somebody who doesn't have their headphones on, obviously is broadcasting Leave Me Alone. He's like, get another developer and say, Hey, I have been stuck on something for 15 minutes, I can't figure it out. And have them sit with you. He's like, don't wait an hour, hours too long. Now the amount of time is debatable, but for him, he's 20 years at that point in his career. So he was coaching me. I think the point of what he was trying to coach me at that time was. Don't wait very long at all, unless it's completely clear in your head. Don't wait very long at all. Get help right away. And this is an experienced senior developer telling me this yeah. And I think if, yeah, so that's fantastic to hear because but if you have tech leads, you can reach out to them. Don't feel ashamed to do that. So teams that actually foster that behavior, you'll find team members doing things. Like spinning up documentation libraries or chat channels where people can ask these questions and anyone who's happens to be looking can answer things so people can say, Hey, I'm stuck on this logic. How do I do this? Right. And someone else can answer or they can say Oh, I've done this before, here's a snippet of code. It's not quite going to do what you want, but you can use it as reference, right? When you see things like that happening your team is maturing, right? Which is the only way I code now is I go back to previous things I've done. The first thing you should do obviously is go to Stack overflow. Oftentimes I go to previous snippets of code I write or I've written in the past and go, who wrote this stuff? Exactly, well, it's six months away from writing a piece of code and it might as well be written by somebody else because I can't remember the story I told and the advantages here, we kind of talked about is. when you're asking for help in development and you're peering not only are you getting different levels of expertise, to help you work through the problem, but the code that you produce afterwards most likely ends up being better, first of all, it's just objectively better, higher quality code. And it ends up being more maintainable because the other person will check you to say, Oh, you got it. Like you got to handle, try catches. You got to handle errors. Just do it now. don't wait and refactor it later. Do it now. I think the net net of it is, and I don't think there's been any studies that are my knowledge anyway, but the net net of it is you're actually going to accrue less technical debt as a result of that which is one of the big selling points of Anyway, yeah, I think that's real. So, yeah, if you're in a culture that is, is it tracks your hours down to the minute or whatever with programming and all that kind of stuff. And it's difficult, like the, the, the culture itself or the financial controls that are in place over you are kind of pushing back against culture. I don't know that this is not the podcast of having a lot of good suggestions for you, but just, just know that those things are counteracting. Actual good development practices. Agreed. Absolutely. And yeah, if you're in that culture, keep that resume up. Oh, it's time. Oh, that, that advice went out in the first 20 minutes of the podcast. Oh my goodness. This is going to be a good podcast. For sure. We're talking about these roles in kind of like, almost like in isolation. Almost right. It was the developers, but if a developer has, excuse me, if a developer has a question and they're not sure they could ask a. Test or why not? They're technical to and say, take a look at this. And even if the tester can't help, let's assume the worst case scenario test can help you in this specific instance, right? Because your question is deep and it's all around like trying to do a raise of a raise or whatever. The tester can say, while you're doing that, how about doing X, Y, Z. So it makes it easy to test. Now already to your point about maintainability, the code is now getting better already, right? So their input's not wasted. Like, I realize that we talk about developers just because that's the role in the scrum team is developers. But this equally, could apply to testing. Sure. the testers asking for help. Also, I think about testers the same way I think about Business analyst though is like your job kind of is asking for help all the time. You know, if you're a tester and you've tested something, you'll test something. If you're manually testing something like something that you're about to automate. So you have to test it manually first to make sure it works. You'll test it. You'll test it and you'll see that it fails and you'll say, Oh, well, maybe it was something in the data or maybe it was some edge case or maybe something that maybe I didn't do something right. Maybe the test data was bad or whatever, and you'll do it again. You'll do it a couple times. Probably usually is what I see. And then at some point you have to just go get the developer that coded it to say I'm trying everything I can. It's just I don't understand why it's not working. Right. Because sometimes it may not be apparent to you that it's not why it's not working. I mean, it's nice if you have access to all the logs you need and the access to the environment but sometimes testers don't have that control. Sometimes they're testing in environments they don't control. They can't see everything that's available to them and they'll have to Test it a couple times like the user would see it and then stop. Mobile testing is this way too. You have very limited visibility into what's actually happening in mobile testing. You have to go get the developer and they'll have to maybe run a debug version of the mobile app that they just sent to you to figure out what exactly is going wrong. But, that's, if you're not asking for help, the risk of escape defects is going to skyrocket if you're not asking for help along the testing process, or you let things slip because you're afraid to ask for help or I've been in the corporate environment where every time you stop to ask the developer for a question or whatever, you're perceived as slowing down development. Cause likely in that type of environment, when they've handed you A fix or a release or something, they've moved on to the next thing. So when you're asking them, Hey, I don't understand this, or hey, this test doesn't seem to be working. Can you work with me? It's perceived as, Oh, Brian, your tests are slowing down the active development work. I've been in that culture. It's, I understand when I say it out loud, it sounds ridiculous. No, it doesn't. But I have been in that culture quite, quite often. In fact, these people are measured differently in that culture, right? So the developers are heads down, like you said. They moved on to the next stuff. And it's almost looked upon as a bother. When the tester says, hey the stuff that you passed over to me, quite working. I think in those kinds of environments, you can make some slight tweaks. Make sure the tester has access to the code so they can step through it. And figure out where it's wrong. And go back to the developer with meaningful input like, here is where it's breaking. Yeah. Go fix it, right? in the mobile world, for example. We had to talk through the requirement. We had to talk through what we're trying to do with the customer. We had to explore the use case with the customer. Then we had to take it internal talk about what needed to be changed behind the scenes to make it happen. Like We had to design how we're going to work through the work. So, at that phase, where you spec'd out all the stories, And wrote all your subtasks and broke out all the work. You could have asked the tester for help at that phase, because the tester, as you write out, Oh, we got to change this table and we got to do this request and we got to get this back and we got to verify that the data is as expected or whatever. The tester could be telling you along the way, well, okay, you're getting this back from the database. Well, we got to check what happens if the time's out. We got to check what happens if you get garbage back. We got to check what happens if you the happy path, if everything goes well. So the testers can be helping you spec out how you're going to code something if you're a developer. And if the testers are not normally involved in that process, the testers could lobby to, Become involved in that process under the banner of helping, Hey, I want to write my tests at the same time as you write the way that you're going to develop it. And that like again, there is, there's methodologies, testers and development stuff like that. They even gets closer to doing that. But yeah, that's a, that's a persona that we, we did not originally have on here. Testers QA that I think That's another one that could get tripped up very easily, you know? Yeah, absolutely. And you know, one of the things that I've seen also as a behavior pattern is testers aren't engaged at the time of backlog refinement because we're just talking about work. There's nothing for them to test yet. No, get them in there so they can ask meaningful questions. They can figure out how to test it later, but definitely ask you those questions around Edge cases, type of data, interfaces, boundary conditions there's no limit. So having them in there is invaluable, right? And this is all the more important if you're using that old the three amigos model. The test person should be present as one of the amigos playing one of the instruments as the mariachi. They should be in there. Yeah. They, if they're not in there, then you're missing out an important piece here. You're gonna ask for help Brian. As long as we go with like the Holy Trinity, the Holy Marty Kagan Trinity of , the developer product manager and designer, let's talk about the designer for a second. the product is UI UX. Let's talk about UI UX. So UI UX where I were like only in my experience, everyone's experience could be different, but my experience is. When UI UX doesn't want to ask for things or put more meetings on the product managers calendar. Cause again, my calendar, I tell people all the time. I'm like, listen, find time on my calendar, book over whatever's there. Don't get intimidated. If it's important, throw it on there. I can be available early. I can be available late. Throw it on there. People feel like they're burdening me and the UI UX people, again, because they're user experience, they're usually the people on the team that have the most empathy. So they don't want to feel like they're burdening you by taking time to ask for help. They're actually doing you a disservice by not doing that, I feel right. Because they're going to take shortcuts at the end of the day. Well, that's, I go out of my way to communicate that, but cause I'm, I'm a, I'm a direct. I will tell people, Hey, like I'll tell my UI UX people, Hey, I don't like this, or I like it. And these are the reasons why. And then I tell them to challenge me or I tell them I leave it in and get customer validation. But this is why I don't like it. I'm very direct to tell them, to work back and forth cause earlier in my product career, I was used to being the. Product manager slash UI UX person. Especially when I was on contract, that companies, companies that are, have a contract product person, especially if you're the first product person, like they don't have UI UX people, I talked to a company that I was at on contract. I helped them hire their permanent placement product manager, I helped their product manager get up to speed. And then I separated from the contract that usually was my, Way of a successful ending of a contract. I remember the advice I told them when I flew out to the client site and I sat down with them at dinner with the executives and the new product manager I told them like, here's the things in the next year. you got a permanent product manager. Now it's their roadmap, not mine anymore. you're going to want to launch a new directions and the product manager is going to outline the vision and the new directions. But I was like you're going to want to quickly iterate with different customers, because that company had a bunch of different customers that were trying to sell at any one time I was like, you're going to want to quickly iterate on ideas. Much faster than your development team. And what I told them was your development team they're going to feel stressed because they're going to say, we can't iterate as quick as you, the business want to iterate to test new ideas. And you're going to find out that what you're looking for is high fidelity clickable wireframes. And you're going to end up hiring a UI UX person. And Get some quick feedback. So here's a new idea. We want what do you guys think about it feedback feedback feedback? Ideas go into the funnel They all go to the development team through the filter, the product manager, what I told him was. you'll do that three to six months. You'll do that three to six months until you reach a new level of understanding, which is, Hey, we don't have to implement every single idea we have anymore. We can just test the ideas. UX person and then only implement the best ideas that get the best traction. And I told him at that point, when you make that realization culturally, you will want your UI UX designer to sit outside your office, there's a very small company. So they could do something like that. It was like 20 people, right? I was like you'll want to hire that person to sit right outside your office because you'll Get off a customer call and you'll run right over their office energized with like I got this new idea Let's you know add it to the mock ups and let's blast it out to our audience and have them click it and See what the metrics look like and I was like, you'll do that every week You'll have a new idea and that should be okay For your designer that like they shouldn't be put off by that is what I'm saying. Now, if you did that to a development team, I got this new idea. Go implement it top to bottom and have it out in the application. By the end of the week, you're really stressing out that development team. It's very little work to throw it in prototypes, the funny thing with that, that customer is I saw them like it must've been like 18 months after. I had left their contract and they came to me, they were, they happened to be in town and I met with them for drinks after, after whatever event they were here for. As one does. And they're like, they're like, Oh, Brian we want to let you know, we hired a UI UX designer. I was like, Oh yeah. I was like, where's their desk? Cause I know I've been to their office many times and I was like, where's their desk? And the CEO is like, right outside my office. I was like, why are they right outside your office? Cause you're energized a lot of times and you want to test ideas in the market right away that's what you want to do. I was like, yes, exactly. That being energized and having that person who can zip those ideas right to the market and bounce it off the market. I think the same thing as I think of the product marketer as well. I want to bounce those ideas off the market as soon as possible so that we can know if we have traction, if we've really. caught on to something that's going to catch fire in the market how early do we know that something, Oh, this is a really great idea. Yeah. And to your point, it doesn't have to be high five, right? It doesn't, it can be low fidelity. Right? Absolutely. Yeah. You know, but maybe when you do that, a parallel activity might be assuming you get the nods up and down instead of sideways from your customer. It's to turn to your teams and say, here's a low fi mock up of what we're trying to do. It's barely just above the level of. Chicken scratching on a napkin. That's okay for the customers. Maybe you want something that's clickable because their experience is better and they're more likely to engage depending, depending on the customers, technical and they will engage with you even on the back of a napkin. Right. So yeah, it just depends. I agree. this should be the pro. Of asking for help as a UI UX designer is, is you're looking for different perspectives. You know, if you can fire off a new idea, that's just hot off the press out to a broad audience and you're unconcerned about burdening them with additional things you can ideate much faster than your competition. Yeah. The more I think through this of all the roles we we've talked about or we're going to talk about. This is one role. This should be the bread and butter really, right? You're asking for feedback. You can think of it that way, but you're asking for help. So help me understand the landscape of this specific thing in your business, in your business model, right? That's kind of asking for help. You could say it's under the guys. feedback. That's okay. But the other ones initiating the approach, right? By having something and say, is this work well? Oh, no. Okay, well, what can we change? If you're a designer and you're not afraid to ask for help you pretend just like a BA, you very quickly will get exposed to a bunch of different skillsets that otherwise, like maybe you wouldn't interact with, I think about UI UX designers that I've worked with they've always had a library of components. It's. That they end up using as a product manager, I end up just coupling with them to reuse their components and they reuse mine because in the world of mobile applications, your life Advances in dog years as opposed to normal years. So you get used to all the elements and everything that you would use in mobile apps. That a lot of web applications are very slow to adopt. The clickable slider buttons and everything from iOS and everything. now it's normal to have all those in websites. 10 years ago, it was barely anybody had them. Yeah. You're definitely helping them build up their design pattern library and sharing from that. So that just makes sense to me. I feel UI UX designers. Like they, the pride and self reliance negative. I think they're a little less prone to that category. by the nature of their work, They have to speak to customers. They have to understand the customer journey, their experience. So it makes sense to me. I think BAs are kind of not too far behind that. If you're a real BA trying to understand what's going on Instead of just basically being an note taker. I want to cut us to what I think is the most interesting category here. Which is executives or management, it could be middle managers, whatever layer. So, the holdups at this layer of the organization for asking for help are like Stark. And problematic, I will say. They absolutely are. And they're pretty clear, actually, as well, I think. Yes, they can be pretty clear. we can start with ego. I think that leads the whole list of these things. That's the same things that we said were going to be a through line when we started with developers. Now, They're amplified to a factor, basically. Is that ego pride, that feeling that I'm, I have to be self reliant, I have to come up with a solution myself, that kind of thing. Now it's taken up to a power of 10. Here, because we're at the highest levels of the organization, potentially. Yeah. And I think it's sometimes worse at the middle manager layer because they're striving to advance in the organization. So this kind of flies in the face of that, because if you're asking for help, it's kind of culture to you saying, I know what I'm doing here. Promote me basically and that's why a lot of times I find management. They, if you have N number of managers, let's say four managers that are trying to solve the same problem. You ask him individually. You're gonna get at least four, maybe five or six different approaches, right? Because they don't ask for help and they want to stamp their Authority and that gets in the way of them getting help because they don't ask for it. It's unfortunate because the repercussions are huge. The team follows along usually and they could be like the Pied Piper being led down the wrong street will let me give you an example. every time that I have ever had an Indian development team, they have their tech lead and their team members cannot question their tech lead. And their tech lead is assumed to always be making the best decision. So in that culture, I don't think I've ever been partnered with an Indian tech lead who has asked for help. Yeah. I mean, I'm trying to reflect on what you just said. And it's pretty much true for me as well. I think the only time I've seen that work a little bit differently is when I was a consultant for a client in India and they saw me as just the local basically and that's when you can just basically grab the tech lead, go downstairs to streetcars, get him some tea or coffee and talk it out. Right. So yeah, I agree with you. It's a cultural thing for sure. But it's real, it's everywhere. And a lot of the people do outsource. So this is something that's probably going to impact more people than not. I only bring that up because like everything that we're talking about, it could be ingrained in the culture that you're in which you are doing business. You may not be thinking, well, how is the culture responding to what I'm asking? And how's the culture responding to what we're doing? You know, like if I'm not going out of my way to promote the mission and vision of my organization and the vision of my product, and especially if we don't have a working agreement. Where we say I as a product manager and you as a developer, I expect that we're going to work through solutions to get to the best solution possible. I expect that you're not going to go off and spend days by yourself realizing that basically what we said in refinement is not deep enough. Once you get into that section of the code and you realize there's a whole bunch of other stuff that needs to be done, don't work for three days alerting somebody. I value you coming back and communicating. Hey, this thing that we pointed at a three, I think it's probably closer to an eight because once I got into the code, I realized all these other things were happening and nobody really knew it. Let me alert somebody. Let me ask for help before continuing this work and, like I said, the culture of, well, I already said it was going to take me two days. So whether it takes me two days, meaning two, eight hour shifts or two days, meaning two actual 24 hour days, you know what I mean? Yeah. And then I worked a little bit Sunday and then Monday I turned it in and it's ready for release. You know what I mean? Like it's two days, two business days, but you don't know about all those extra days. It's the same thing culturally, your team might be burning the midnight oil because they promised something and now they feel like they owe you something and that is just a culture but again, I bring it up because you're just paying for hours basically. Like if you're engaging in one of these big services for developers. You might not even know you're just gonna get hired end. Right. I would rather have a team that stops when they. Encounter something we did not expect when we talked about how we're going to implement something Yeah, I would rather have a team that stops and gets me right Versus a team that just figures it out and never alerts me and I don't know that they're burning the midnight oil Yeah, I think we talked about doing a podcast on doing things right. And this will be part of that. But if you're in a situation where you have a lot of developers that are in different cultures, right? Different offshore countries. One of the things to watch for is exactly that. it's People getting stuck. Now, they're not going to make it visible necessarily. So it's important to set up chat channels and these sorts of things where you can continuously look for and people can feel safe to ask questions. it's not a admission of failure if you just put in a chat, Hey, I've been spinning on this for a bit who can help, right? If all Developers are in the same chat channel. So you want to try and level that instead of saying, well, the developers are here. The tech leads are here. The architects are here in that striation really doesn't help. So if everyone's in the same place, the product could be in there too, because somebody could say, Does this mean a change of scope for us? And the product person's watching the chat, and they can pipe in and say, Let's talk about this. So I think you can do things like that. An astute Scrum Master, perhaps, could say to the team, Listen because they're with the team at the daily stand ups or sync ups or whatever. You can say, Whenever you get stuck, Let me know. I'll see what I can do to kind of get you some help. So it's all about that is instilling that culture of being able to put your hand up and say, Hey, I'm stuck here. Well, if you're lucky enough to have a scrum master, I would assume like, even if we go back to the most strict way that I was saying we're working before, where you're like 15 minutes, you're stuck, like ping your scrum master. Hey, I think we need to put something together. I don't know who to talk to about this, they should be jumping all over that or helping you figure out how to jump all over it, right? Cause that might be a thing too. I feel like we went down the cultural rabbit hole here, we're on the executive category, right? Or the manager category, right? Manager at this point, yeah. You may not be aware that the team members have difficulty asking for help or stopping and re syncing. And I feel that culture of saying, Hey, if you see something, say something, if you have a problem, say something, if you can't figure something out, ask for help, that culture is set from the top. So in this case of the executives, if there are the type of people that understand that When we cast a wide net to make informed decision making, when we spread our decision making to the teams involved, we get better decisions like that permeates through the organization. and if you're, an executive and you think that because you can't make a decision without engaging your teams or asking for feedback before you make the decision, you think that is seen in the organization. As being indecisive. Oh, this, this leader can never make a quick decision. They always want to ask their teams. They're indecisive. You know, that, that's a, that's a problem. Yeah, and I think that is a slippery slope. It can, it can go from indecisive to incapable or non qualified. so of course, in that scenario, and I guess we moved on to the executive category now Those executives are going to be very guarded, right? At not being perceived as oh, I don't know what I'm doing. It's more, it's more like, go do this, right? But if that's not right it's a slight on me because I told you what to do, right? So, they're not going to be welcoming when people have those questions and they raise their hands, so to speak. In a ideal situation, it should be like, here's the problem that we want to solve for. What is the best way to solve it? It's not an executive. Telling the team or even like guiding the team toward a solution through their preferred approach, right? That what they're saying is what is really the best way to do this and letting the team come up with a given the autonomy to be independent and come back with alternate solutions. Right? And then weigh up each solution by its own merit. The other thing that I don't think it's talked about often enough is, especially from an executive standpoint, if you want the culture where people feel safe asking questions, then start recognizing when people do that and start rewarding that behavior. Because then other people will follow the behavior, right? So when somebody asks a question, just think about it. Thank them for it and say, I'm glad you asked it now instead of waiting till the end of the sprint or whatever, right? Because now we can pivot quickly, and other people will see that and say, Oh, it's okay to ask questions, right? So as an executive, you owe it to yourself to try and instill that culture in your own organization, certainly in your own teams, at least and then hopefully it will rub off on your peers, and they will start doing that because that's the biggest stumbling block too for executives is being seen as, incompetent or inadequate in front of their peers. They can't have that, right? But it's not that you're actually leveraging the power of your teams. And harnessing the power of the collective many minds to land a real solution that's viable yeah. Well, you're collaborating to make decisions. Exactly. even if you have the final say, even if you are the single decision maker, you're the arbiter. You can still cast a wide net. You can still ask for opinions. You can still ask for advice and viewpoints that you may not be aware of. That's not weakness. that's actually a strength. Yeah, it's a strength 'cause you're using people who have the best skills to give you you know, a decision perhaps that's more likely to succeed. Well, or, or you're just asking people closest to the work, what they would do. And you're just making a decision. You're making, you're in making a informed an an informed, an informed, you're making an informed decision. But you're, yeah, you're right. You are making an informed decision through empowering your teams, right? And that, that can only be a good thing. Right, right. I mean, the better way is just let the teams make the decisions and then you got to mature to that level. Sure. Yeah. I bring this up the book that I just got done reading that just went off the screen. A book that I just got done reading was the Toyota way to lean leadership. it's a pretty dense book, but as far as ideas go by Gary canvas and Jeff Jeffrey Laker. But in that book they're talking about the Toyota method of leadership, basically. And one of the things that they talk about is the Toyota leaders, the senseis, the people that actually are in management. Charisma is not one of the particular things they care about. in fact, charisma a lot of times is seen. As anathema To what a good Toyota leader, the Toyota leaders are very humble and they want to ask questions, the Toyota kind of questions of hey what's the situation that you were expecting and what's actually happening now and what do you think you can do, there's a series of questions like those charisma doesn't really play a part in any of that, they're asking you, What would be the ideal? If you could solve this problem, what would it look like? You know, what is the next step you're going to try? What is the ideal situation? Well if there's a resolution, what does that look like? they're basically, they resist at all costs telling you what to do because of what they feel is, and I'm paraphrasing the entire book right now in this conversation, what they feel is if they told you then you would not have to think. critically and come to a solution on your own. And if that happened, you would lose something. You, the employee, would lose something by never having to think critically about the work you're engaged in. So they would take something away from you if they gave you the answer and told you what to do. Wow, that's that is so powerful. I really like that concept. I have to say, just because there's another hidden factor here, which is they told you what to do. You wouldn't think of any other alternate solutions. So you're not necessarily getting the best option out of this. So in parallel asking you for options, what they're really doing is empowering you to come up with the best solution. The employees are closest to the problem. They're the ones that are working the system. So ask them how They can come up with the best way of working going forward, solving this particular issue. I think that's the way to go. So there was a couple of through lines on this podcast. I mean, obviously ego is one. the fear of being seen as not self reliant was another one. Inadequacy. Project managers, we didn't specifically reference them, but. They fall into that category as well. They come in and say, I'm the project manager. The word manager there speaks lots to this, right? I'm gonna tell you what you have to do. I'm gonna tell you when you have to get it done by. Never mind the fact that as a project manager, I've never actually done that before. Right? So how can that be successful, honestly? Because people that are being told to do these things are already starting off on the back foot. First of all, they're being told what to do. goes back to our previous conversation about the Toyota way. This is the opposite of that. And we don't know that. So we haven't evaluated all the options. We haven't ruled out that bad options. None of that. Okay, that's one thing. The other thing is the time element, right? You have to do this by this date. You know, that's that little the end of the bar on the on the Gantt chart. these project manager types, and I confess to being one for many, many years hopefully I've recovered now, they don't want to seem like they don't know what they're doing, they don't want to seem like they're not putting the authority on the project,. managing the project, here's a project plan, it's really nothing more than a schedule at that point, but okay, whatever, right, they want to be able to tell leadership or management, I'll I have a project plan. I bought this. We're going to bring this in on this date, right? The teams are really kind of hamstrung at that point. the fear of rejection or the fear of judgment that you're not doing a good job or whatever. Like that, that, that could be applied to pretty much any of the personas that we talk about today. Especially executives or middle managers is People will be judging me. People will be looking down on me. Or people will be rejecting me oh, don't go to that person. They're always wrong. Oh, their estimates are always wrong. Or they always overrun their budget. Or they can never control their development teams, or whatever. You're right. So throughout this whole thread, right, it can apply to any of the roles. Yeah. But I think it's most blatant with project managers because they, they publish a schedule a project plans, not really the plan. But anyway, they publish it and then lo and behold, they fall behind and immediately they're labeled your projects running behind schedule. now you own the project okay. So these people are very guarded typically in saying. I'm going to do the best I can. I'm going to put a whole bunch of padding around everything. Yeah that's human nature. it's self preservation. So you're going to put padding around it. And then you try and sell that upstream, but downstream people are not bought into that. Even if it's bad, they're not bought into it because they didn't come up with it. That's the prima facie reason. They didn't come up with it. So how can it be successful if they don't own, they don't feel ownership in the work that they're delivering that fulfills your your Gantt chart. So, so I feel like project managers They coming back to the whole point of the podcast, they don't ask for help because they're supposed to be the authority on this stuff, right? They're the ones that come up with all this stuff, the network diagrams and the critical paths and whatever else, right? I know that hasn't worked well for us as an industry for a long time. I like you just identified a through podcast is don't inflict this on yourself. Don't inflict this, not asking for help because you feel That, oh, I'm supposed to be the authority on this. Yeah. Or I'm supposed to be whatever don't like inflicting this on yourself. It is the easiest way to start failing in this category. I'm going to give you a parallel here. Listen, when a president of a country, a large country falls sick with COVID, let's say just as an example, right? It can happen. Do they just engage the services of a single doctor? To say what to do etc. I think you'll find there is a huge group of doctors that they work with. So why do you need so many doctors? Right? Because two things. First of all, the president wants to be sure he's getting the best advice, he or she. And the second thing is, if you were the only doctor there, you're probably going to hedge your bet very widely and say, Here are ten different things you might do in the hope that one might work. But you, you're working with your peers, in this case, the other doctors, and collectively you're going to come up with the best solution. That's an example, I think, of how it doesn't matter what your role is, where you're at, you really need to ask for help. The President, in this case, you could say, is asking for help and tolerating the fact that there are 14 people that have to talk with each other before they tell him anything. That's right, that's right. Right? So this kind of parallels to our the discussion here. If you are the top dog in an organization, the CEO, president, MD, whatever, the head honcho, make sure you don't isolate yourself from this situation of asking for help because you've got a lot going on, first of all, And you've not done this before, possibly. Even if you are a serial entrepreneur, every case is different. Be open to getting help from people and you might reach out to other people that have, that are in the space or outside of the space that at your level or You know, coaches, right? Executive coaches, for example, engage with them. Everybody can use that. I feel. the funny thing about these categories that we didn't go into, because like, we're not trying to sell anybody on anything is pretty much every one of these personas has their own niche coaches. Yes. the developers have digital, but product management has product coaches. Executives have executive coaching. You know, everyone has, coaches. Everybody needs coaches. You know, the champion teams in your favorite sport. They won last year. They won the cup. They won the world cup or whatever. They still got a coach. Just saying. And hired them back again six months later because it's just not going to work. The hire and fire cycle. they point that out in the Toyota way. if you're in this when the businesses on the downturn, you just fire everyone or whatever, when the business on the upswing, you have a mass hiring, you hire too many people like that rollercoaster cycle, That doesn't work was the irony of that, right? So when the business is on the downturn, you fired everybody. What do you, when do you really need help when it's on the downturn? So that's the irony of it for me. Yes. If we're going to give any coaching advice this podcast is no matter if you're a developer or design, you are, you're X person, project manager, executive manager, QA, product management, and you feel that you're not developing your skills. Like you're not getting coaching, maybe your product leaders are not coaching you or like maybe there's nobody qualified. Maybe you're the only product manager in your company. There's no one to coach you, right? Use some of them training dollars, get, get coaching, get help, get an outside opinion, there are events. There are meetup events. There are places you can go to go to lean coffees, that kind of stuff. Maybe sponsor a lean coffee. by visiting these events, you might be able to secure a mentor. Right? and get them to mentor you. Now that's a low cost entry here, right? I mean, anyone can, should be able to do that. You just got to invest in yourself. Think of it that way. So yeah, absolutely. Yeah. Take that first step. Take that first step and also take that first step to like, as a scribe, this podcast, every time you subscribe, it helps us a ton. Trust me. You have no idea how much it helps a tiny little small channel like us. We're not trying to sell you anything. You're not going to get our newsletter. Nope. You're not going to get our, our Patreon or whatever. Yeah, we won't. I, I, and we won't ask you to buy our training book or anything like that, but every time you like and subscribe a puppy smiles somewhere, think about that.