Constructive Communication in Software Development That Drives Results

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. 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? We're having great conversations with AI about some of the things that we have done. It's just giving us more time to get into some of these details that maybe we missed the first time around. Or sometimes it's funny enough, AI will take things in a completely different direction from what we are used to. First, introductions. I am Rob Brodhead, one of the founders of Developador, Building Better Developers. So the best way we can put it is we help businesses simplify their technology and build a clear roadmap 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 make sure we're clear on it. And then we find ways to do them better. We buy 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. That being said, just anytime give us a call or actually, I'm sorry, shoot us an email. That's the wrong part. Send us something. Hit us up on the RB-SNS.com website and 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 turbo quick assessment, get some feedback and just where you need to go. It's free. All you have to do is put your email address in and 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 we had a situation where 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 a Saturday night is very, very challenging. We knew where he was. We had a device that was in his car and we knew where he was almost all the time. The problem is he was constantly moving. If you go somewhere, one, remember your stuff in the Uber. More importantly, next time you're going to be like thank your drivers and stuff like that because they are hustling, especially when it is a busy time of year. 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? Good thing is actually, I don't think I used this last time. Good thing is my microphone. 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. For another podcast, my wife sat down and said, hmm, we need to find some good mics that we can use, not the one that's about to introduce himself either. We got some really cool ones and 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. 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 Moulache. I'm one of the co-founders of DeveloperNUR, 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 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. Good thing, we had a full moon the other night and I was up for most of it. I was able to see part of the lunar eclipse, which was really cool, but unfortunately it was about two something in the morning and I couldn't stay up that late. 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. We're noticing it, I guess it was just last night. It was like one of those, it was because there's a little bit of rain and stuff like that going on. It was actually really cool. It was one of those that had a little bit of that red orange kind of tint to it and it was just as it was coming up. It was huge and it was pretty neat. Moons are like that. More importantly, AI is like this, I guess. I don't know. There was a bad segue. I apologize for that. We're going to dive right into this one. The title that we're working with is 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. It 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 episodes. It gets back to, we've seen this now a couple of times where it's really going to give us, I think it's like 10 bullet points and some sub bullet points underneath that. 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, wife examples, code reviews, architecture, discussions, etc. This is really interesting because I would often say, I guess, arguing, I would not say that it's necessarily to win, although I guess it is because 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 lot the wrong way for me to think about it because really 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 solving a problem. The goal should not ever be 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, things like blind spots or places where you just ignorance, general ignorance, where you just actually don't know about that process, that step, that piece, that solution 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 development or is 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 want to make sure 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 Python project, but the person next to you that's coming in, they're new and they've only ever done dotnet projects. And they may have a way that dotnet 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 will throw this in there just to throw the hand grenade in and then go away. 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. People 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 because they're 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 philosophic answer, I guess, and then toss that over to you and see where you want to go. Sure. So I'll start with just start out with advocating. So really, if you want your teams to succeed and 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 and say, oh, that won't work. Ask something like, okay, I hear you restate that the what you heard to 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. 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 of 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, a hundred 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 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? You can change the format of the question and the approach to some of these situations. And you can easily defuse the arguing and get back into that advocating more collaborative approach within, you know, this type of environment. And I 100% agree. I will just 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 very focused on our project or 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? And then yourself, sometimes 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 backpedal 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 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 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 have stepped back, especially even more so if it's not your intent to find a way to deliver it in a way that is not 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 somebody that like I learned to say no a long time ago because 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 just want to throw this one out. If you're if you're gathering important things like requirement, the last thing you want to do is shut people down. Now you can go. Like you just did. I'm just gathering important information though. So we may get stuck in the first one for this whole episode, but while we're talking about arguing and, you know, being advocating, when you're working with software teams or what your customers and clients is 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, you know, refinement, going through your backlog, refining your tickets, refining those requirements, going 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 where you're not quite following that flow of agile the way it's supposed to be. 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 why this matters in development. Scrum Master 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 in the circus that is almost every software development project. So much of this is a hundred and agree a hundred percent. 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 know. Yes, straining client relationships. So you can't 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 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 but 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, it's 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. That's why a lot of documents, especially software requirements 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'm going to take the software projects are a 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 work, how customer and company relationships work. And I will tell you, a lot of times it is more negative, more hostile than it is positive than 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. I'll just 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 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. Let's have a quick tech review or a quick hackathon and walk through the idea, throw the idea, 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 worked with, been a part of in various ways, have always had that key thing like 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 have been on teams that have bonded over just general disregard for everybody else in the world except for the company that they work for. A whole lot of differences. Each one of them is very different and each team is unique. And finding that thread, basically, of uniqueness for your team is going to do a lot for you. 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, it helps to have that lighter kind of approach, which moves us into 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 because this is a season in itself, probably. 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. Prioritizing ego or personal preference over user needs or project goals. For example, we must use framework X versus here and Y. Here's why framework X might fit this problem better. AI stinks. We must 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. It really comes down to where we started with this. This is hopefully one that I think we've already nailed. You've got to be open. Instead of no, hey, how about this? Or instead of never say, well, let's explore that. We use a lot of time. It's almost a cop out, but it is very easy to have something like, we're going to talk about that later. We're going to put it on the backlog. That will go into future features or something like that. A futures list or sometimes even an open 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. 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 it's not the best time to discuss them. It could sometimes just require more discussion and thought than you really have time to give it right now. 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. Then they're like, well, hey, that's a pretty cool idea. Sometimes it's a great idea. It's just time and place. It is not the right time for it. Let's find a place that we can hang that up and we'll come back to it later. We do have something else we have to focus on right now. Your thoughts? Yeah. So I really liked because you touched on kind of the theme of where it was going with that at the end. The biggest one, 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. Or if your scrum master's there, work with them to set a prior to 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 have people butting heads. Say hey, let's just take a timeout 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 and say, hey, let's table this discussion until tomorrow. However, 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 the talking stick in the meeting. You have to find a way to keep things from getting out of hand, particularly when you're in somebody's 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. A lot of times you'll end up with side conversations. So if you have 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 conversation, 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. Zoom meetings and stuff like that. Feel free to be like one person is talking, everybody goes off mute and then you essentially you could recognize people and say, okay, it's your turn. Okay, it's your turn. Something like that. Well, yes, it will slow stuff down a little bit, but I think it also takes the heat off of some of those things. And then that last suggestion is probably the best is put it down on paper, like tell people as office, 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 we can see it beforehand and we can sit down and have a reasonable discussion about all of it and walk through each of the, you know, everybody's stuff. Everybody gets their turn and then we can take care of it as we need to. Just like you can shoot us an email at info at developanure.com 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 saying, well, what does it think? 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 developanure.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 at developanure. Any of those places or any place that you see that you're getting here, 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 develop an hour 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 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 got of 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 it have us sit down and do a little bit of reorganization so some of that stuff can be found better, particularly if you're doing a search, but for like a specific thing. However, I do want to share that if you go out to the developer nor YouTube channel, there's a lot of stuff there that is grouped and categorized in a way that it's 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 this. 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. We'll talk to you next time. Thank you for listening to building better developers to develop a new podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.