Detailed Notes
Challenge your team to communicate better! In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit their classic discussion on constructive communication in software development—showing how to replace arguments with collaboration.
🔑 You’ll learn: • How to spot when a discussion turns into an argument • Practical steps to foster constructive dialogue in Agile teams • Tips for managers to build a positive, collaborative culture • A 7-day challenge to put these ideas into action
🎯 Take the Challenge: During your next sprint or code review, apply the three-step process: listen first, ask open questions, and record the outcome. Share your results in the comments!
Read more: https://develpreneur.com/constructive-communication-software-development/
👉 Subscribe for more insights on software development, team collaboration, and AI-powered productivity.
Transcript Text
[Music] We hit record. That's why you see us. Um, apologies last time. Uh, I don't know how much he corrected it, but if you also like I saw a freeze in the video for a while, it's cuz the internet sucks sometimes, especially we're out in the boonies as Michael is. So, apologize for that. But, at least you got to hear his voice and all the important things. If you had to see him frozen for a while, that's okay. You know, sometimes an adult beverage will take care of that problem. Today, we are getting there. Uh, this one's going to be advocating versus arguing how to drive collaboration and success in software development. So, uh, we're doing chat GPT again and, uh, I think we will dive right into it and see where it goes with our little dress dolls. Uno. Well, hello and welcome back. We are continuing our season where we are taking a past season, running it through AI, getting some feedback, and then saying, "Hey, what the heck is this about?" And we're having great conversations with AI about some of the things that we have done. And uh it's just giving us more time to like get into some of these details that maybe we missed the first time around. uh or sometimes it's funny enough AI will take things in a completely different direction from what we are used to. Uh first introductions I am Rob Broadhead one of the founders of developer building better developers also the best way we can put it is we help businesses simplify their technology and build a clear road map to fuel growth to be successful. We take that technology sprawl of all those things. A lot of times it's spreadsheets and stuff like that that you have and through simplification, integration, automation, innovation, we help you take your processes that we sit down with you and and make sure we're clear on it. And then we find ways to do them better, simplify them, do them quicker, automated, improve quality, reduce time spent so that you can work in your business. I'm sorry, on your business instead of in your business because I've been working too much in my business lately, I guess. So, I keep getting those two simple words reversed. Uh, that being said, uh, just anytime, give us a call or actually, I'm sorry, shoot us a shoot us an email. That's the wrong part. Send us something, hit us up on the rb-sns.com website and uh, you can check some stuff out there. You can go matrix.rb-sns.com and we've got a little tool there if you want to go through and sort of see like a turboquick assessment, get some feedback, and just where you need to go. It's free. Uh, all you have to do is put your email address into this. That's what everybody makes you do these days. Good thing, bad thing. This one's a bad thing. It ended up good, but I will just say, um, we had a situation where we had something left behind in an Uber on a Saturday night in Nashville. The bad thing was we had to chase that Uber around. Trying to chase an Uber driver around in Nashville on Saturday night is very, very challenging. We knew where he was. We had a device that was in there in his car and we knew where he was almost all the time. The problem is he was constantly moving. And so if you go somewhere, one, remember your stuff in the Uber. More importantly, like next time you're going to like thank your drivers and stuff like that because they are hustling especially when it is a busy time of year. Uh and actually here I guess it's always a busy time of year. A good thing would be let's see what is the good thing that I want right now. Uh good thing is actually I don't think I used this last time. Good thing is my microphone. Uh we are looking at downsizing and getting more remote and all that kind of stuff and being road warriors, digital nomads and all that goodness. And so for another podcast, my wife sat down and said, "Hm, we need to find some good mics that we can use." Not the one that's about to introduce himself either. And so we got some really cool ones and uh they've turned out really well. They're small, easy to take care of. Plug in just about anywhere and use your phone, your laptop, stuff like that. Probably at some point I'll do a little review and we'll put a show note or a link somewhere in there. But I've taken too long. So now we're going to pass it over to the actual mic that is going to be co-hosting this. Go ahead and introduce yourself. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of Developer Building Better Developers. I'm also the founder of Envision QA where we help businesses run better by making sure their software works the way it should. Essentially, we want to make sure that that the software is working for you, you're not working for your software. Whether you're managing customers, selling online, or running clinic, we make sure that your systems are more reliable, more efficient, and easy to use. That means fewer headaches, happier customers, and more time to focus on your growth. We handle things like building customer tools, fix slower or buggy systems, setting up automated testing, and make sure that the software is ready for launch before you try to launch it. In short, again, we take care of the tech behind the scenes so you can focus on running your business. Check us out at envisionqa.com. Good thing, bad thing. Uh, good thing that we had a full moon the other night and I was up for most of it. Uh, I was able to see part of the lunar eclipse, which was really cool, but unfortunately it was about 2 something in the morning and I couldn't stay up that late. Uh, normally I can, but I was fading quick. But anyway, caught a little bit of it. That was really cool. I guess the bad thing is I wasn't able to stay up for the whole thing. Yeah, that's uh we were noticing it. I guess it was just last night. It was like one of those it was cuz there's a little bit of rain and stuff like that going on. So, it's actually really cool. was one of those that had a little bit of that red orange kind of tint to it and it was uh just as it was coming up. So, it was a it was huge and it was uh pretty neat. Uh moons are like that. More importantly, AI is like this, I guess. I don't know. That was a bad segue. I apologize for that. So, we're going to dive right into this one. The title that we're working with is uh the original one and this is AI's initial thing is great title choice and it is advocating versus arguing how to drive collaboration success in software development. Says you've got a lot of space to dig into developer team dynamics and leadership. Here are some structured talking points to consider for your episode. So it gets back to uh we've seen this now a couple times where it's really going to give us I think it's like 10 bullet points and some sub bullet points underneath that. So, we're going to start with framing the difference. Advocating. Presenting your perspective with evidence, empathy, and openness to feedback. Arguing, defending your perspective to win without considering context or collaboration. Share developer life examples, code reviews, architecture, discussions, etc. Um, oh, this is really interesting because I would often say, I guess arguing, uh, I would not say that it's necessarily to win, although I guess it is cuz it's usually I always think of it in the debate contest context a little bit. And I guess debates are a competition, but for me, I guess it's like that's probably a long the wrong way for me to think about it. Um because really when we're when we're doing these things, we're having these kinds of discussions which are like I said like code reviews and architecture and we're we're solving a problem. The goal should not ever be to to win because it's not really your way if you win is not necessarily the best way. The whole point of us having these discussions is for your way to rub up against the next person's way against the next one and the next one. And it's not that you necessarily take a little bit out of everybody, but you are open to all of these discussions and all of this input and then use that and process it. It's just like anything else. If you have a little more information or a lot more information, you have a better chance of making the right decision because now you're informed. And it includes things like especially in software um things like blind spots or uh places where you just there you know ignorance general general ignorance where you just actually don't know about that process that step that piece that solution uh cost and it really is a lot of why we do what we do by we being RB consulting and even why we talk about this a lot in developers because it's really about understanding the problem and then figuring out a good solution and then the best solution for it. And if you are just jumping into here's a solution, you're probably not going to get there. This is the whole, you know, the old thing, the old saw, pun intended, of if all you have is a hammer, everything is a nail. We, you know, we want to make sure and that we're not just using that hammer, which sometimes that's our head, our experience, our knowledge. Sometimes it is really useful to have somebody maybe say it's a a Python project, but the person next to you that's coming in, they're new and they've only ever done .NET projects and they may have a way that .NET solves this that you've never done in Python that nobody would do in Python, but now suddenly you have a thinking outside of the box solution. It actually is. And I I will throw this in there just to throw the hand grenade in and then go away. um is that it is sort of like what AI gives you is that AI can when you ask questions to AI like I said sometimes it will take it completely out of context it'll take you in a completely different way actually Michael does that to me sometimes too we'll have a topic and the next thing you know we've gone somewhere else and it's not just him and it's not just me when you have a conversation sometimes people have a whole different mindset a whole different track sometimes it's cuz are not paying attention or something like that. Sometimes it's just because they're thinking at a different level. Lower above doesn't really matter. But that sometimes is the key to actually getting to the best solution. So I'll start with that very uh philosophic answer, I guess, and then toss that over to you and see where you want to go. >> Sure. So uh I'll start with just start out with advocating. So really, if you want your team to succeed in really any project you work on with your customers, your teammates, whoever you're working with, really sitting down and allowing everyone to present their ideas, listening to everyone, be open to that. Instead of, and by being open, I mean, if you hear something that you don't necessarily agree with, follow up with a different type of question instead of, "Oh, that won't work." Ask something like, "Okay, I hear you." restate that the what you heard. Make sure that one you're understanding what they're trying to say and maybe you just misheard them, but ask it is okay. So, how do you see that working or how does it work in this instance? And get more information like keep it open. Keep the conversation going. Don't just shoot it down. No is a great way. No, that won't work. Kills the conversation. Gets you back in the arguing. arguing. There's a couple different ways I've seen with arguing. Arguing I've seen from a point of view where you have like a Java developer and a Python developer and the Java developers, oh, everything has to be Python. Like Rob said, everything's a hammer and everything's a nail. You solve problems that way. That can be very contentious, especially when you're dealing with cross teams or integrating different projects together or even having multiple projects or customers. The bigger problem I see with arguing is when people have spent a lot of time or have vested a lot of work in a particular solution, they are a little more defensive, a little more argumentative about changing direction or doing something else because they might have already spent like 60 100 hours trying to get this working based on what they've been told to do. And in reality, they're too close to the problem and they need to take a step back. But the problem is they don't see that they're too close to the problem. So they're being argumentative without intentionally meaning to be argumentative. It's more of the like the blinders on. So in those situations, I recommend say, "Look, okay, I see what you did. I see where you're going with this. However, have you considered this?" Or, you know, what do you think about this approach? Change the format of the question and the approach to some of these situations. and you can easily diffuse the arguing and get back into that advocating uh more collaborative approach within, you know, this type of environment. >> And I I 100% agree. I will just uh we will all admit that that is one of those things that can be easier said than done, especially when you get into developers. We do this all the time. we're we're very focused on our project or our our thought, our process, our way of doing it. And we will just drive into a lot of us are black and white. We're not so our statements are very black and white. And while we may not intend that, that often can shut stuff down. And so sometimes you're going to have to have that conversation or back somebody up and just say, "Hey, wait a minute. Is that really what you mean?" Uh, and then yourself sometimes you're you're going to have to listen to what you just said and say, "Huh, is that really what I meant?" And sometimes you're going to have to backpedit a little bit and say, "Wait a minute. Let me clarify that because it came off not the way I really wanted it to be." And uh, trust me, this is speaking from experience. It is it can be a pain to back backpedal and do all that and people can get lost a little bit, but if you slow it down, walk back through it and say, "Stop. Hold on. Let's reset this. Especially if you're seeing things getting contentious, then you know, step back. Especially even more so if it's not your intent to find a way to deliver it in a way that is not uh offensive nor black and white is that do it in a way that is like, hey, let's talk about it. Like Michael said, if you want to say if you say no, it's amazing how fast that does. And this is just somebody that like I learned to say no a long time ago cuz I said yes too often and now I'm having to unlearn the no because too often I'll say no and it's like I don't really mean no. I mean like not right now like or hold on. And just simple things like that like well let's talk about that or let's consider that totally different same tone even everything else no versus well let's consider that dramatically different. And if you're gathering important information like requirements, I'm sorry I'm cutting you off. I don't you want to throw this one out. If you're if you're gathering important things like requirements, the last thing you want to do is shut people down. Now you can go >> like you just did. >> I'm gathering important information though. >> So we may get stuck in the first one for for this whole episode. But while we're talking about arguing and you know being advocating when you're working with software teams or with your customers and clients, it's always better to have a safe space or at least through the entire software development process. you go through different stages, especially if you're doing agile, and you're asking these questions as you're going through each stage of the process, and you're not getting into a lot of these arguments. Because if you're clearly going through talking to your customer, getting those requirements, getting the feedback, understanding what they need, you're building, you're listening, you're understanding, you're getting the feedback. go to your team, you work on building the solution, but if anyone gets stuck or anyone has problems or anyone has questions, you should have an open forum where people can spitball come up with ideas. You know, this is like not just code review, but this is background uh you know, refinement, going through your backlog, refining your tickets, refining those requirements. Going through each of the stages through agile is a great way to really keep you advocating and not arguing. If you find yourself more on that arguing side, chances are you're missing something or you're not quite following that flow of agile the way it's supposed to be. Ah, you're getting ahead, but we're going to see. We may not get there anyway. So, let's let it let us plow ahead a little bit here to uh why this matters in development. Software projects are collaborative by nature. diverse skill sets, roles, and personalities. Bad communication can derail sprints, create tech debt, or strain client relationships. Advocacy shares understanding. Arguments erode trust. Wow. This is why scrum masters are a thing even is that there has to be somebody that is dealing with the monkeys and the circus. That is almost every software development project. Uh I so much of this isund and agree 100%. Um the bad communicate it's interesting where bad communication can derail sprints, create tech debt or strain client relationships. I don't think people think about it as often as they yes straining client relationships. So like yeah, if we don't communicate wrong, we tick them off, then that's not going to work. And sometimes it'll derail sprints, but I don't think people often realize that like that is a thing. So is creating tech debt. I don't know how often that I have had with my team where we have had communication and particularly when it is uh when we're coming from different backgrounds and would say hey let's solve this problem. Okay go write the code and then it's wait a minute which is why we have code reviews. You have to go make it line back up. It's also why we have code standards. We have these standards and we have these things that we're supposed to follow because that helps us. It gives us a common language. We don't have to really we don't have to like the language because honestly the you know our our standards are about us all saying we're going to choose something. It's not about who's right or who's wrong about the standard and the approach. It's really about just everybody saying look choosing one thing is better than arguing about whatever it is. If we can make that decision and move forward at least we're on the same page now we have a common language. This is why a lot of documents, especially software requirements and and design documents, they have essentially a dictionary, a definition of terms right there at the beginning because there's going to be things that are going to be used a lot and if you don't define it and if you're not clear on what that means, things get out of hand very fast. So, your turn. >> Sure. So I I'm going to take the software projects are collaborative by nature, diverse skill sets, roles and personalities. So working for 25 plus years now in software development in many different roles, many different teams, many different companies, I have definitely seen a diversity of how team dynamics work, how customer and um company relationships work. And I will tell you a lot of times it is more negative, more hostile than it is positive than it there's more advocating. It is very hard in a company. If you are already negative, if things are already bad, arguing seems to be the norm. It is very hard to pull yourself back from a negative to a positive environment. That being said though, there are ways to keep things positive and we've mentioned them and I'll just re reiterate them a little bit though. Stick to your agile format. Keep your meetings open. Keep them positive. Ask better questions that are more open-ended, more listening, kind of explain what you're doing, explain what you mean. Keep the conversation going. Try to avoid uh answers that shut things down. The other thing is maybe have a weekly meeting like a water cooler meeting or a team collaboration meeting where you open it up. Hey, who's got an idea this week on something new they've learned or some idea that they want to teach? And if you have people that are dedicated on, hey, I think this solution will work. Hey, let's have a quick, you know, tech review or quick uh um hackathon and walk through the idea. Throw the idea out. Throw things at the wall. see what works and then maybe move on. If it doesn't work, cool. You've tried it and you've ruled it out. Little things like that really kind of shift the dial back more to the positive than keeping it negative. Just keep the conversation open. And the other thing I'll mention, especially for those managers out there or those leads, is make sure you take care of your team. If you see someone's having a bad day or very argumentative in meetings, pull them aside, talk to them on the side, find out what's going on, and see if it's something business related that you can tweak, help them grow that mentoring approach. Or if it's something personal, maybe you can help them overcome it. Or if you're a manager, maybe you can give them some additional time off. There are things you can do to help change the course of the conversation to keep things more positive. I'll just add to that that the best teams that I've I've worked with, been a part of in various ways have always had that key thing like you know the job, the work that we're doing, but there's always been other things that tie the team together. There have been other things that they bond over. It can be anything basically. I have been on teams that bonded over really stupid dad jokes. I've been on teams that have bonded over uh just dis general disregard for everybody else in the world except for the company that they work for. A whole lot of different stuff that it's like each one of them is very different and each team is unique and finding that thread basically that of uniqueness for your team is going to do a lot for you. Uh and just it it does save a lot of these problems. Even though, yeah, we're always going to run into issues, there's going to be times where we're going to be a little stressed, uh, it helps to have that that lighter kind of approach. Which moves us into uh, in our final minutes here since we're going along because like we said, we hit a couple of these and spent a little too long on it. Uh, because this is this is a season in itself probably. Uh, three signs you're arguing, not advocating, using absolutes like always and never, talking over teammates instead of listening. I would never do that, especially in a podcast. Uh, prioritizing ego or personal preference over user needs or project goals. For example, we must use framework X versus here why. Here's why framework X might fit this problem better. AI stinks. We must use project uh use framework X versus here's why framework Y might fit this problem better. At least straighten that one out a little bit. I'm going to jump right in like It really comes down to where we started with this. So, this is sort of hopefully one that we've I think we've already sort of nailed is that you've got to be open instead of no like, hey, how about this? Or instead of never say, well, let's explore that or we use a lot of time. Let's say it's it's almost a copout, but is very easy to have something like we're going to talk about the that later. We're going to put it on the backlog that'll go into future goal, future uh, you know, features or something like that. A futures list or sometimes even an opens questions list, that kind of thing. Having a place to store something that is not no, it's not we're never going to do it. It's we're going to go back to it and be sure that you do go back to it at some point. Getting back to that allows you to take the things when they're it's not the best time to discuss them. They could be contentious for a lot of different reasons or it could sometimes just require more discussion and thought than you really have time to give it right now. And that allows people to feel like they are heard essentially and not that their idea was just tossed out for no reason. It's just like, oh well, no, we're not going to deal with that. And then they're like, well, hey, that's a pretty cool idea. And sometimes it's a great idea. It's just time and place. It is not the right time for it. So, let's find a place that we can, you know, hang that up and we'll come back to it later. But we do have something else we have to focus on right now. Your thoughts? >> Yeah. So, uh I really like because you touched on kind of the theme of where I was going with that at the end. The biggest one I if you have meetings that are contentious that there's a lot of arguments going on. If you have a scrum master that's not doing their job and this can lead to a lot of these things, dedicate someone in the room. If you don't have a scrum master or if your scrum master is there, work with them to set a priorit prioritization so you don't have people talking over people. You give everyone kind of have a meeting mediator where it's like, okay, here's the baton. You have two minutes to talk. Go. And then all right, you're done. Okay, you still got more pause, add notes to the chat. We'll come back to that. Or even someone else with an ego where if you start to get contentious where people are getting heated, you you have people butdding heads, say, "Hey, let's just take a time out from this. Let's take a quick break. Maybe walk away from the meeting for a little bit, come back. If it's a long meeting, or if it's a short meeting, say, "Hey, let's table this discussion till tomorrow. However, while we're both do uh you know, while we have time between this, why don't you both write down your thoughts on each of this and then we can discuss. That way, you kind of diffuse the argument. Now, have them think about it a little bit more in a positive sense in a way of lists and then you can always revisit that as an agenda for another meeting. >> Yeah, I think sometimes that boy, there's two things. There's one is sometimes you have to have like a you have to have the talking stick in the the meeting. You have to find a way to keep things from from getting out of hand. Particularly when you're in a some of these things where people are really like they're thinking, they're on the fly, they're working their way through a problem solving, people get really excited and they start talking over each other and it can be very difficult. U a lot of times you'll end up with side conversations. So, if you have a I've been in more times I can think of where you've got a room full of people and you got side conversation, another side conversation, another side competition, then you have people trying to do cross conversations and the next thing you know there's a lot of stuff there and most of it is not captured because there's no way because it's just too much going on uh with Zoom meetings and stuff like that. Feel free to be like one person is talking, everybody goes off mute and then you you essentially you could recognize people and say okay it's your turn. Okay, it's your turn. Something like that will, yes, it will slow stuff down a little bit, but I think it also takes the the heat off of of some of those things. And then that last suggestion is probably the best. It's like put it out on paper. Like tell people as often as poss, especially if you're going to get into something that could be contentious, say, "Hey, write your thoughts down on paper. We'll put it out to everybody so everybody can see it beforehand and we can sit down and have a reasonable discussion about all of it and and walk through each of the, you know, everybody's stuff. Everybody gets their turn and then we can we can take care of it as we need to. Just like you can shoot us an email at [email protected] and let us know what you think, what you like, what you would like to do because we want to hear from you. We're not saying no, we're saying yes, yes, yes, and give us more. Love to hear feedback. What do you like? What don't you like? What are your thoughts on future seasons and some of the topics you would love for us to go to or maybe go back to because this has actually been I've really enjoyed this one going back to AI and and saying well what does it think uh because it gives us some really cool little things and sometimes just a chance to once again beat some of the drums that really need to be beaten on a regular basis. Also check us out at developer.com. We have a contact form. You can leave us feedback on any of the blog posts or anything like that. You can check us out. There's a Facebook page on X, we are developer. Any of those places or any place that you see uh that you're getting what you see that you get a podcast, you can leave us a feedback there. We'll take a look at it. Also on YouTube, there's the developer channel. We got tons and tons and tons of stuff. Yes, we've got we've been like I've been sort of surprised and and shouting at the rooftops a little bit lately about how we're like well on our way towards a thousand episodes on the podcast, but we also have got oh sheesh years and I think hundreds and hundreds of posts out on YouTube as well. So, that is also a place where there is some serious content there. And I am it is on my list, which doesn't mean I'm going to get to it anytime soon, but I'm working on it to get there to let have us sit down and uh do a little bit of reorganization so some of that stuff can be found better. Uh particularly if you're doing a search, but uh for like a specific thing. However, I do want to share that if you go out to the Developer YouTube channel, there's a lot of stuff there that is uh grouped and categorized in a way that is probably going to be the easiest way if you want to do like some learning things like learning Python or learning SQL or I think we've got a PHP one. I forget all the We've got a lot of stuff out there. That being said, I'm finally going to take a breath, but you guys can do the same. Go out there and have yourself a great day, a great week, and we'll talk to you next time. bonus material. Let me fly through these real quick. Uh because I already put the other one up there. Um wow, we didn't get even close to this. Uh I'm not even gonna fly through these. That's too much to read. So, where do you want to go for your bonus material? So, the only thing I'll throw out for the bonus is we kind of mentioned writing things down. Record your meetings and then go back and listen to your meetings. And if you're a manager, this is a very good tool to help you work with your team and yourself to see how the teams are being mediated and how the team dynamics are going. If you have a lot of arguing going on, try things in your meetings to diffuse the situation to change the dynamic a little bit. And if you're recording your meetings, you can see what works and what doesn't. And then from there, throw it into AI. have AI even do a scan if you have Zoom and you or any type of uh notetaking uh recordings. Uh let have it analyze your meeting and say, "Hey, what was the tone of this meeting? Where did things go off the rails?" You know, use the tools at your disposal to help improve the situation. I think that's great is that there's a lot of if you have a recording and you're looking at um the transcripts or you let AI look at the transcripts or have AI summarize it, you can actually get some pretty interesting information out of that. Maybe again, maybe it's a a different set of eyes and it sees it. It will see it a little differently from the way that you do. Um, I'll also just throw um be kind basically into all of this is that I think one of the things that are one of the quick ways to get something contentious is to as some of this thing is it explains where it's like uh saying you know this code is bad or this is broken or things like that or you trying to figure out like if it's always like well your code does this or the thing you wrote did that or the thing you designed did that is like try to get rid of that stuff and it's just like it's an us thing. It's a we thing. Um even if it's a manager, it is a lot of times it's one of those things you're like we're going to solve this problem and then we will make the heads roll later when we need to. But it's basically like we need to you know get in there and say let's not worry about who did what. Let's about solving the problem. Now if solving the problem is eliminating some of your people because they suck. Okay, fine. That's a little different. But that's going to be contentious and that's not really what we're talking about here. We're talking about designing uh creating implementing those things that require feedback that require trust. They require you to come together as a team, as a group, however it is in a partnership to say, "Let's fix this thing." So try to if you can remember that if you can try to remember that like yes, even if that other person seems like a blathering idiot, they still have the same goal as I do. And so maybe they're not as foolish as I think they are, maybe there are some things that they can do that can help us out here. And uh sometime it's I know people hate this, but you got to be patient. You just sometimes you're going to have to work your way through this stuff. It's going to take a while. It's going to cause frustration. go home, have a drink, and start back and do it tomorrow. I'm not condoning alcohol, but if that happens to help you through your day, whatever it is, go play games, go do your thing, get away from work for a while. Uh we've said several times if it if you're feeling yourself really where you just are like ready to explode, then just walk away. Put it, you know, write it down somewhere, whatever you need to do, and then go walk away and come back later when you can deal with it in a uh with a calmer head. All right, I'm going to go walk away. so I can deal with these podcasting things with a calmer head. Thank you so much. We appreciate your time for you hanging out with us for especially putting us on through it putting up with us at times like this when it just seems like we are stumbling over everything. Be patient and gracious with us as well and we'll pay you back by bringing you even more episodes. Thank you so much. Have a great day and we will talk to you next time around. [Music]
Transcript Segments
[Music]
We hit record. That's why you see us.
Um, apologies last time. Uh, I don't
know how much he corrected it, but if
you also like I saw a freeze in the
video for a while, it's cuz the internet
sucks sometimes, especially we're out in
the boonies as Michael is. So, apologize
for that. But, at least you got to hear
his voice and all the important things.
If you had to see him frozen for a
while, that's okay. You know, sometimes
an adult beverage will take care of that
problem. Today, we are getting there.
Uh, this one's going to be
advocating versus arguing how to drive
collaboration and success in software
development. So,
uh, we're doing chat GPT again and, uh,
I think we will dive right into it and
see where it goes with our little dress
dolls. Uno. Well, hello and welcome
back. We are continuing our season where
we are taking a past season, running it
through AI, getting some feedback, and
then saying, "Hey, what the heck is this
about?" And we're having great
conversations with AI about some of the
things that we have done. And uh it's
just giving us more time to like get
into some of these details that maybe we
missed the first time around. uh or
sometimes it's funny enough AI will take
things in a completely different
direction from what we are used to. Uh
first introductions I am Rob Broadhead
one of the founders of developer
building better developers
also the
best way we can put it is we help
businesses simplify their technology and
build a clear road map to fuel growth to
be successful. We take that technology
sprawl of all those things. A lot of
times it's spreadsheets and stuff like
that that you have and through
simplification, integration, automation,
innovation, we help you take your
processes that we sit down with you and
and make sure we're clear on it. And
then we find ways to do them better,
simplify them, do them quicker,
automated, improve quality, reduce time
spent so that you can work in your
business. I'm sorry, on your business
instead of in your business because I've
been working too much in my business
lately, I guess. So, I keep getting
those two simple words
reversed. Uh, that being said, uh, just
anytime, give us a call or actually, I'm
sorry, shoot us a shoot us an email.
That's the wrong part. Send us
something, hit us up on the rb-sns.com
website and uh, you can check some stuff
out there. You can go matrix.rb-sns.com
and we've got a little tool there if you
want to go through and sort of see like
a turboquick assessment, get some
feedback, and just where you need to go.
It's free. Uh, all you have to do is put
your email address into this. That's
what everybody makes you do these days.
Good thing, bad thing. This one's a bad
thing. It ended up good, but I will just
say, um, we had a situation where we had
something left behind in an Uber on a
Saturday night in Nashville.
The bad thing was we had to chase that
Uber around. Trying to chase an Uber
driver around in Nashville on Saturday
night is very, very challenging. We knew
where he was. We had a device that was
in there in his car and we knew where he
was almost all the time. The problem is
he was constantly moving. And so if you
go somewhere, one, remember your stuff
in the Uber. More importantly,
like next time you're going to like
thank your drivers and stuff like that
because they are hustling especially
when it is a busy time of year. Uh and
actually here I guess it's always a busy
time of year. A good thing would be
let's see what is the good thing that I
want right now. Uh good thing is
actually I don't think I used this last
time. Good thing is my microphone. Uh we
are looking at downsizing and getting
more remote and all that kind of stuff
and being road warriors, digital nomads
and all that goodness. And so for
another podcast, my wife sat down and
said, "Hm, we need to find some good
mics that we can use." Not the one
that's about to introduce himself
either. And so we got some really cool
ones and uh they've turned out really
well. They're small, easy to take care
of. Plug in just about anywhere and use
your phone, your laptop, stuff like
that. Probably at some point I'll do a
little review and we'll put a show note
or a link somewhere in there.
But I've taken too long. So now we're
going to pass it over to the actual mic
that is going to be co-hosting this. Go
ahead and introduce yourself.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
Developer Building Better Developers.
I'm also the founder of Envision QA
where we help businesses run better by
making sure their software works the way
it should. Essentially, we want to make
sure that that the software is working
for you, you're not working for your
software. Whether you're managing
customers, selling online, or running
clinic, we make sure that your systems
are more reliable, more efficient, and
easy to use. That means fewer headaches,
happier customers, and more time to
focus on your growth. We handle things
like building customer tools, fix slower
or buggy systems, setting up automated
testing, and make sure that the software
is ready for launch before you try to
launch it. In short, again, we take care
of the tech behind the scenes so you can
focus on running your business. Check us
out at envisionqa.com.
Good thing, bad thing. Uh, good thing
that we had a full moon the other night
and I was up for most of it. Uh, I was
able to see part of the lunar eclipse,
which was really cool, but unfortunately
it was about 2 something in the morning
and I couldn't stay up that late. Uh,
normally I can, but I was fading quick.
But anyway, caught a little bit of it.
That was really cool. I guess the bad
thing is I wasn't able to stay up for
the whole thing.
Yeah, that's uh we were noticing it. I
guess it was just last night. It was
like one of those it was cuz there's a
little bit of rain and stuff like that
going on. So, it's actually really cool.
was one of those that had a little bit
of that red orange kind of tint to it
and it was uh just as it was coming up.
So, it was a it was huge and it was uh
pretty neat. Uh moons are like that.
More importantly,
AI is like this, I guess. I don't know.
That was a bad segue. I apologize for
that. So, we're going to dive right into
this one. The title that we're working
with is
uh the original one and this is AI's
initial thing is great title choice and
it is advocating versus arguing how to
drive collaboration success in software
development. Says you've got a lot of
space to dig into developer team
dynamics and leadership. Here are some
structured talking points to consider
for your episode. So it gets back to uh
we've seen this now a couple times where
it's really going to give us I think
it's like 10 bullet points and some sub
bullet points underneath that. So, we're
going to start with framing the
difference. Advocating. Presenting your
perspective with evidence, empathy, and
openness to feedback. Arguing, defending
your perspective to win without
considering context or collaboration.
Share developer life examples, code
reviews, architecture, discussions, etc.
Um,
oh, this is really interesting because I
would often say, I guess arguing, uh, I
would not say that it's necessarily to
win, although I guess it is cuz it's
usually I always think of it in the
debate contest context a little bit. And
I guess debates are a competition, but
for me, I guess it's like that's
probably a long the wrong way for me to
think about it. Um because really when
we're when we're doing these things,
we're having these kinds of discussions
which are like I said like code reviews
and architecture and we're we're solving
a problem. The goal should not ever be
to to win because it's not really
your way
if you win is not necessarily the best
way. The whole point of us having these
discussions is for your way to rub up
against the next person's way against
the next one and the next one. And it's
not that you necessarily take a little
bit out of everybody, but you are open
to all of these discussions and all of
this input and then use that and process
it. It's just like anything else. If you
have a little more information or a lot
more information, you have a better
chance of making the right decision
because now you're informed. And it
includes things like especially in
software um things like blind spots or
uh places where you just there you know
ignorance general general ignorance
where you just actually don't know about
that process that step that piece that
solution uh cost
and it really is a lot of why we do what
we do by we being RB consulting and even
why we talk about this a lot in
developers because it's really about
understanding the problem and then
figuring out a good solution and then
the best solution for it. And if you are
just jumping into here's a solution,
you're probably not going to get there.
This is the whole, you know, the old
thing, the old saw, pun intended, of if
all you have is a hammer, everything is
a nail. We, you know, we want to make
sure and that we're not just using that
hammer, which sometimes that's our head,
our experience, our knowledge. Sometimes
it is really useful to have somebody
maybe say it's a a Python project, but
the person next to you that's coming in,
they're new and they've only ever done
.NET projects and they may have a way
that .NET solves this that you've never
done in Python that nobody would do in
Python, but now suddenly you have a
thinking outside of the box solution.
It actually is. And I I will throw this
in there just to throw the hand grenade
in and then go away. um
is that it is sort of like what AI gives
you is that AI can when you ask
questions to AI like I said sometimes it
will take it completely out of context
it'll take you in a completely different
way actually Michael does that to me
sometimes too we'll have a topic and the
next thing you know we've gone somewhere
else and it's not just him and it's not
just me when you have a conversation
sometimes people have a whole different
mindset a whole different track
sometimes it's cuz are not paying
attention or something like that.
Sometimes it's just because they're
thinking at a different level. Lower
above doesn't really matter. But that
sometimes is the key to actually getting
to the best solution. So I'll start with
that very uh philosophic answer, I
guess, and then toss that over to you
and see where you want to go.
>> Sure. So uh I'll start with just start
out with advocating. So really, if you
want your team to succeed in really any
project you work on with your customers,
your teammates, whoever you're working
with, really sitting down and allowing
everyone to present their ideas,
listening to everyone, be open to that.
Instead of, and by being open, I mean,
if you hear something that you don't
necessarily agree with, follow up with a
different type of question instead of,
"Oh, that won't work." Ask something
like, "Okay, I hear you." restate that
the what you heard. Make sure that one
you're understanding what they're trying
to say and maybe you just misheard them,
but ask it is okay. So, how do you see
that working or how does it work in this
instance? And get more information like
keep it open. Keep the conversation
going. Don't just shoot it down. No is a
great way. No, that won't work. Kills
the conversation. Gets you back in the
arguing.
arguing.
There's a couple different ways I've
seen with arguing. Arguing I've seen
from a point of view where you have like
a Java developer and a Python developer
and the Java developers, oh, everything
has to be Python. Like Rob said,
everything's a hammer and everything's a
nail. You solve problems that way. That
can be very contentious, especially when
you're dealing with cross teams or
integrating different projects together
or even having multiple projects or
customers. The bigger problem I see with
arguing is when people have spent a lot
of time or have vested a lot of work in
a particular solution,
they are a little more defensive, a
little more argumentative about changing
direction or doing something else
because they might have already spent
like 60 100 hours trying to get this
working based on what they've been told
to do. And in reality, they're too close
to the problem and they need to take a
step back. But the problem is they don't
see that they're too close to the
problem. So they're being argumentative
without intentionally meaning to be
argumentative. It's more of the like the
blinders on. So in those situations, I
recommend say, "Look, okay, I see what
you did. I see where you're going with
this. However, have you considered
this?" Or, you know, what do you think
about this approach? Change the format
of the question and the approach to some
of these situations. and you can easily
diffuse the arguing and get back into
that advocating uh more collaborative
approach within, you know, this type of
environment.
>> And I I 100% agree. I will just uh we
will all admit that that is one of those
things that can be easier said than
done, especially when you get into
developers. We do this all the time.
we're we're very focused on our project
or our our thought, our process, our way
of doing it. And we will just drive into
a lot of us are black and white. We're
not so our statements are very black and
white. And while we may not intend that,
that often can shut stuff down. And so
sometimes you're going to have to have
that conversation or back somebody up
and just say, "Hey, wait a minute. Is
that really what you mean?" Uh, and then
yourself sometimes you're you're going
to have to listen to what you just said
and say, "Huh, is that really what I
meant?" And sometimes you're going to
have to backpedit a little bit and say,
"Wait a minute. Let me clarify that
because it came off not the way I really
wanted it to be."
And uh, trust me, this is speaking from
experience. It is it can be a pain to
back backpedal and do all that and
people can get lost a little bit, but if
you slow it down, walk back through it
and say, "Stop. Hold on. Let's reset
this. Especially if you're seeing things
getting contentious, then you know, step
back. Especially even more so if it's
not your intent to find a way to deliver
it in a way that is not uh offensive nor
black and white is that do it in a way
that is like, hey, let's talk about it.
Like Michael said, if you want to say if
you say no, it's amazing how fast that
does. And this is just somebody that
like I learned to say no a long time ago
cuz I said yes too often and now I'm
having to unlearn the no because too
often I'll say no and it's like I don't
really mean no. I mean like not right
now like or hold on. And just simple
things like that like well let's talk
about that or let's consider that
totally different same tone even
everything else no versus well let's
consider that dramatically different.
And if you're gathering important
information like requirements, I'm sorry
I'm cutting you off. I don't you want to
throw this one out. If you're if you're
gathering important things like
requirements, the last thing you want to
do is shut people down. Now you can go
>> like you just did.
>> I'm gathering important information
though.
>> So we may get stuck in the first one for
for this whole episode. But
while we're talking about arguing and
you know being advocating
when you're working with software teams
or with your customers and clients, it's
always better to have a safe space or at
least through the entire software
development process. you go through
different stages, especially if you're
doing agile, and you're asking these
questions as you're going through each
stage of the process, and you're not
getting into a lot of these arguments.
Because if you're clearly going through
talking to your customer, getting those
requirements, getting the feedback,
understanding what they need, you're
building, you're listening, you're
understanding, you're getting the
feedback. go to your team, you work on
building the solution, but if anyone
gets stuck or anyone has problems or
anyone has questions, you should have an
open forum where people can spitball
come up with ideas. You know, this is
like not just code review, but this is
background uh you know, refinement,
going through your backlog, refining
your tickets, refining those
requirements. Going through each of the
stages through agile is a great way to
really keep you advocating and not
arguing. If you find yourself more on
that arguing side, chances are you're
missing something or you're not quite
following that flow of agile the way
it's supposed to be. Ah, you're getting
ahead, but we're going to see. We may
not get there anyway. So, let's let it
let us plow ahead a little bit here to
uh why this matters in development.
Software projects are collaborative by
nature. diverse skill sets, roles, and
personalities. Bad communication can
derail sprints, create tech debt, or
strain client relationships. Advocacy
shares understanding. Arguments erode
trust.
Wow. This is why scrum masters are a
thing even is that there has to be
somebody that is dealing with the
monkeys and the circus. That is almost
every software development project. Uh I
so much of this isund and agree 100%. Um
the bad communicate it's interesting
where bad communication can derail
sprints, create tech debt or strain
client relationships. I don't think
people think about it as often as they
yes straining client relationships. So
like yeah, if we don't communicate
wrong, we tick them off, then that's not
going to work. And sometimes it'll
derail sprints, but I don't think people
often realize that like that is a thing.
So is creating tech debt. I don't know
how often that I have had with my team
where we have had communication and
particularly when it is uh when we're
coming from different backgrounds
and would say hey let's solve this
problem. Okay go write the code and then
it's wait a minute which is why we have
code reviews. You have to go make it
line back up. It's also why we have code
standards. We have these standards and
we have these things that we're supposed
to follow because that helps us. It
gives us a common language. We don't
have to really we don't have to like the
language because honestly the you know
our our standards are about us all
saying we're going to choose something.
It's not about who's right or who's
wrong about the standard and the
approach. It's really about just
everybody saying look choosing one thing
is better than arguing about whatever it
is. If we can make that decision and
move forward at least we're on the same
page now we have a common language. This
is why a lot of documents, especially
software requirements and and design
documents, they have essentially a
dictionary, a definition of terms right
there at the beginning because there's
going to be things that are going to be
used a lot and if you don't define it
and if you're not clear on what that
means,
things get out of hand very fast. So,
your turn.
>> Sure. So I I'm going to take the
software projects are collaborative by
nature, diverse skill sets, roles and
personalities. So
working
for 25 plus years now in software
development in many different roles,
many different teams, many different
companies,
I have definitely seen a diversity of
how team dynamics work, how customer and
um company relationships work. And I
will tell you a lot of times it is more
negative, more hostile than it is
positive than it there's more
advocating. It is very hard
in a company. If you are already
negative, if things are already bad,
arguing seems to be the norm. It is very
hard to pull yourself back from a
negative to a positive environment.
That being said though, there are ways
to keep things positive and we've
mentioned them and I'll just re
reiterate them a little bit though.
Stick to your agile format. Keep your
meetings open. Keep them positive. Ask
better questions that are more
open-ended, more listening, kind of
explain what you're doing, explain what
you mean. Keep the conversation going.
Try to avoid uh answers that shut things
down. The other thing is maybe have a
weekly meeting like a water cooler
meeting or a team collaboration meeting
where you open it up. Hey, who's got an
idea this week on something new they've
learned or some idea that they want to
teach? And if you have people that are
dedicated on, hey, I think this solution
will work. Hey, let's have a quick, you
know, tech review or quick uh um
hackathon and walk through the idea.
Throw the idea out. Throw things at the
wall. see what works and then maybe move
on. If it doesn't work, cool. You've
tried it and you've ruled it out. Little
things like that really kind of shift
the dial back more to the positive than
keeping it negative. Just keep the
conversation open. And the other thing
I'll mention, especially for those
managers out there or those leads, is
make sure you take care of your team. If
you see someone's having a bad day or
very argumentative in meetings, pull
them aside, talk to them on the side,
find out what's going on, and see if
it's something business related that you
can tweak, help them grow that mentoring
approach. Or if it's something personal,
maybe you can help them overcome it. Or
if you're a manager, maybe you can give
them some additional time off. There are
things you can do to help change the
course of the conversation to keep
things more positive.
I'll just add to that that the best
teams that I've I've worked with, been a
part of in various ways have always had
that key thing like you know the job,
the work that we're doing, but there's
always been other things that tie the
team together. There have been other
things that they bond over. It can be
anything basically. I have been on teams
that bonded over really stupid dad
jokes. I've been on teams that have
bonded over
uh just dis general disregard for
everybody else in the world except for
the company that they work for. A whole
lot of different stuff that it's like
each one of them is very different and
each team is unique and finding that
thread basically that of uniqueness for
your team is going to do a lot for you.
Uh and just it it does save a lot of
these problems. Even though, yeah, we're
always going to run into issues, there's
going to be times where we're going to
be a little stressed, uh, it helps to
have that that lighter kind of approach.
Which moves us into uh, in our final
minutes here since we're going along
because like we said, we hit a couple of
these and spent a little too long on it.
Uh, because this is this is a season in
itself probably. Uh, three signs you're
arguing, not advocating, using absolutes
like always and never, talking over
teammates instead of listening. I would
never do that, especially in a podcast.
Uh, prioritizing ego or personal
preference over user needs or project
goals. For example, we must use
framework X versus here why. Here's why
framework X might fit this problem
better.
AI stinks. We must use project uh use
framework X versus here's why framework
Y might fit this problem better. At
least straighten that one out a little
bit.
I'm going to jump right in like It
really comes down to where we started
with this. So, this is sort of hopefully
one that we've I think we've already
sort of nailed is that you've got to be
open instead of no like, hey, how about
this? Or instead of never say, well,
let's explore that or we use a lot of
time. Let's say it's it's almost a
copout, but is very easy to have
something like we're going to talk about
the that later. We're going to put it on
the backlog that'll go into future goal,
future uh, you know, features or
something like that. A futures list or
sometimes even an opens questions list,
that kind of thing. Having a place to
store something that is not no, it's not
we're never going to do it. It's we're
going to go back to it and be sure that
you do go back to it at some point.
Getting back to that allows you to take
the things when they're it's not the
best time to discuss them. They could be
contentious for a lot of different
reasons or it could sometimes just
require more discussion and thought than
you really have time to give it right
now. And that allows people to feel like
they are heard essentially and not that
their idea was just tossed out for no
reason. It's just like, oh well, no,
we're not going to deal with that. And
then they're like, well, hey, that's a
pretty cool idea. And sometimes it's a
great idea. It's just time and place. It
is not the right time for it. So, let's
find a place that we can, you know, hang
that up and we'll come back to it later.
But we do have something else we have to
focus on right now. Your thoughts?
>> Yeah. So, uh I really like because you
touched on kind of the theme of where I
was going with that at the end. The
biggest one I if you have meetings that
are contentious that there's a lot of
arguments going on. If you have a scrum
master that's not doing their job and
this can lead to a lot of these things,
dedicate someone in the room. If you
don't have a scrum master or if your
scrum master is there, work with them to
set a priorit prioritization so you
don't have people talking over people.
You give everyone kind of have a meeting
mediator where it's like, okay, here's
the baton. You have two minutes to talk.
Go. And then all right, you're done.
Okay, you still got more pause, add
notes to the chat. We'll come back to
that.
Or even someone else with an ego where
if you start to get contentious where
people are getting heated, you you have
people butdding heads, say, "Hey, let's
just take a time out from this. Let's
take a quick break. Maybe walk away from
the meeting for a little bit, come back.
If it's a long meeting, or if it's a
short meeting, say, "Hey, let's table
this discussion till tomorrow. However,
while we're both do uh you know, while
we have time between this, why don't you
both write down your thoughts on each of
this and then we can discuss. That way,
you kind of diffuse the argument. Now,
have them think about it a little bit
more in a positive sense in a way of
lists and then you can always revisit
that as an agenda for another meeting.
>> Yeah, I think sometimes that boy,
there's two things. There's one is
sometimes you have to have like a you
have to have the talking stick in the
the meeting. You have to find a way to
keep things from from getting out of
hand. Particularly
when you're in a some of these things
where people are really like they're
thinking, they're on the fly, they're
working their way through a problem
solving, people get really excited and
they start talking over each other and
it can be very difficult. U a lot of
times you'll end up with side
conversations. So, if you have a I've
been in more times I can think of where
you've got a room full of people and you
got side conversation, another side
conversation, another side competition,
then you have people trying to do cross
conversations and the next thing you
know there's a lot of stuff there and
most of it is not captured because
there's no way because it's just too
much going on uh with Zoom meetings and
stuff like that. Feel free to be like
one person is talking, everybody goes
off mute and then you you essentially
you could recognize people and say okay
it's your turn. Okay, it's your turn.
Something like that
will, yes, it will slow stuff down a
little bit, but I think it also takes
the the heat off of of some of those
things. And then that last suggestion is
probably the best. It's like put it out
on paper. Like tell people as often as
poss, especially if you're going to get
into something that could be
contentious, say, "Hey, write your
thoughts down on paper. We'll put it out
to everybody so everybody can see it
beforehand and we can sit down and have
a reasonable discussion about all of it
and and walk through each of the, you
know, everybody's stuff. Everybody gets
their turn and then we can we can take
care of it as we need to. Just like you
can shoot us an email at
[email protected] and let us know what
you think, what you like, what you would
like to do because we want to hear from
you. We're not saying no, we're saying
yes, yes, yes, and give us more. Love to
hear feedback. What do you like? What
don't you like? What are your thoughts
on future seasons and some of the topics
you would love for us to go to or maybe
go back to because this has actually
been I've really enjoyed this one going
back to AI and and saying well what does
it think uh because it gives us some
really cool little things and sometimes
just a chance to once again beat some of
the drums that really need to be beaten
on a regular basis. Also check us out at
developer.com.
We have a contact form. You can leave us
feedback on any of the blog posts or
anything like that. You can check us
out. There's a Facebook page on X, we
are developer.
Any of those places or any place that
you see uh that you're getting what you
see that you get a podcast, you can
leave us a feedback there. We'll take a
look at it. Also on YouTube, there's the
developer channel. We got tons and tons
and tons of stuff. Yes, we've got we've
been like I've been sort of surprised
and and shouting at the rooftops a
little bit lately about how we're like
well on our way towards a thousand
episodes on the podcast, but we also
have got oh sheesh years and I think
hundreds and hundreds of posts out on
YouTube as well. So, that is also a
place where there is some serious
content there. And I am it is on my
list, which doesn't mean I'm going to
get to it anytime soon, but I'm working
on it to get there to let have us sit
down and uh do a little bit of
reorganization so some of that stuff can
be found better. Uh particularly if
you're doing a search, but uh for like a
specific thing. However, I do want to
share that if you go out to the
Developer YouTube channel, there's a lot
of stuff there that is uh grouped and
categorized in a way that is probably
going to be the easiest way if you want
to do like some learning things like
learning Python or learning SQL or I
think we've got a PHP one. I forget all
the We've got a lot of stuff out there.
That being said, I'm finally going to
take a breath, but you guys can do the
same. Go out there and have yourself a
great day, a great week, and we'll talk
to you next time.
bonus material. Let me fly through these
real quick. Uh because I already put the
other one up there. Um wow, we didn't
get even close to this. Uh I'm not even
gonna fly through these. That's too much
to read. So, where do you want to go for
your bonus material? So, the only thing
I'll throw out for the bonus is we kind
of mentioned writing things down.
Record your meetings
and then go back and listen to your
meetings. And if you're a manager, this
is a very good tool to help you work
with your team and yourself to see how
the teams are being mediated and how the
team dynamics are going. If you have a
lot of arguing going on, try things in
your meetings to diffuse the situation
to change the dynamic a little bit. And
if you're recording your meetings, you
can see what works and what doesn't. And
then from there, throw it into AI. have
AI even do a scan if you have Zoom and
you or any type of uh notetaking uh
recordings. Uh let have it analyze your
meeting and say, "Hey, what was the tone
of this meeting? Where did things go off
the rails?" You know, use the tools at
your disposal to help improve the
situation.
I think that's great is that there's a
lot of if you have a recording and
you're looking at um the transcripts or
you let AI look at the transcripts or
have AI summarize it, you can actually
get some pretty interesting information
out of that. Maybe again, maybe it's a a
different set of eyes and it sees it. It
will see it a little differently from
the way that you do. Um, I'll also just
throw um be kind basically into all of
this is that I think one of the things
that are one of the quick ways to get
something contentious is to as some of
this thing is it explains where it's
like uh saying you know this code is bad
or this is broken or things like that or
you trying to figure out like if it's
always like well your code does this or
the thing you wrote did that or the
thing you designed did that is like try
to get rid of that stuff and it's just
like it's an us thing. It's a we thing.
Um even if it's a manager, it is a lot
of times it's one of those things you're
like we're going to solve this problem
and then we will make the heads roll
later when we need to. But it's
basically like we need to you know get
in there and say let's not worry about
who did what. Let's about solving the
problem. Now if solving the problem is
eliminating some of your people because
they suck. Okay, fine. That's a little
different. But that's going to be
contentious and that's not really what
we're talking about here. We're talking
about designing
uh creating implementing those things
that require feedback that require
trust. They require you to come together
as a team, as a group, however it is in
a partnership to say, "Let's fix this
thing." So try to if you can remember
that if you can try to remember that
like yes, even if that other person
seems like a blathering idiot, they
still have the same goal as I do. And so
maybe they're not as foolish as I think
they are, maybe there are some things
that they can do that can help us out
here. And uh sometime it's I know people
hate this, but you got to be patient.
You just sometimes you're going to have
to work your way through this stuff.
It's going to take a while. It's going
to cause frustration. go home, have a
drink, and start back and do it
tomorrow. I'm not condoning alcohol, but
if that happens to help you through your
day, whatever it is, go play games, go
do your thing, get away from work for a
while. Uh we've said several times if it
if you're feeling yourself really where
you just are like ready to explode, then
just walk away. Put it, you know, write
it down somewhere, whatever you need to
do, and then go walk away and come back
later when you can deal with it in a uh
with a calmer head. All right, I'm going
to go walk away. so I can deal with
these podcasting things with a calmer
head. Thank you so much. We appreciate
your time for you hanging out with us
for especially putting us on through it
putting up with us at times like this
when it just seems like we are stumbling
over everything. Be patient and gracious
with us as well and we'll pay you back
by bringing you even more episodes.
Thank you so much. Have a great day and
we will talk to you next time around.
[Music]