Fostering Effective Communication- Building Better Conversations for Developers

Welcome to Building Better Developers, the Develop-a-Nor 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 of Building Better Habits. We are Building Better Developers. We're Develop-a-Nor Podcast. Funny enough, I noted the other day that now if you search for Develop-a-Nor, there's actually Dentalpreneur shows up more often than Develop-a-Nor, but Building Better Developers has apparently become our primary name. That's an SEO issue that we're going to work with. At some point, we'll come back and talk about such things, but not today. Today, we're going to talk about fostering discussions. Before we do all that though, we got to introduce ourselves, or at least I'll introduce myself and let Michael introduce himself. Myself is Rob Broaddow. I happen to be one of the founders of Develop-a-Nor, Building Better Developers. Also, a founder of RB Consulting, where we are what is known as boutique consulting. We help people wrangle technology. When you have that technology sprawl, when you have the Wild West and your cattle are all over your four billion acres of land, we help get all that stuff together through simplification, automation, integration. We find ways to, and even innovation, we find ways for you guys to go out there, take the technology that you have or the technology that's out there that may be best suited for your unique situation. We help you craft that recipes for success that's specific to your company, to your organization, whether it is through software and tools or even building your team and your roadmap, things of that nature. Since we're in the Building Better habits, the habit that has been, I think, like in feedback that has been the most for me recently is it's a new year. We're solidly into the new year now. The one that is really stuck and I've really been happy that I went to is the find your joy, find your happiness kind of thing. My 15 minutes a day basically of doing something fun and I combine it with doing something productive. It actually sort of combines back when we talked about the one that was about building your skills from 15 minutes a day throughout the days, just do something that improves your skills. It is great that I have these, I guess it's also a little bit of a weakness. I have a lot of projects out there that I've started over the years and they're in varying states of completeness or just barely startedness. In doing that, I've got a lot of different areas. They're like playgrounds that I can play with technology. I can work on a certain skills that I can go back. Actually, I'm doing refactoring on some of these and some of these, these are all these little like pet projects and toys effectively of projects that I've got that, yes, they have value, but they are near and dear to me because they solve problems for me. This is me in some cases automating or creating a solution for a problem that I had. I really recommend that is like find something like that that you can do. how much that will recharge your day basically as you step into it. Good thing, bad thing. Very bad. Natalie got the flu this last week, so she was down for like a solid four or five days and that's just miserable. It was like, now I guess there's a good, one of the good things is allow me to like baby her a little bit because it was like I could go make tea for her and all that kind of good stuff that you have to do when somebody's sick. The other good thing that came out of it is that there was a night that otherwise we probably would have gone out on like a date night and done a bunch of stuff, but she was sick in bed and I basically just got to sit around and I caught up on work, which you guys may say like that doesn't sound like fun, but if you're like me and you're like, I sometimes need to catch up on work, that actually is a very good thing. Somebody who does not need to catch up on work, but does need to catch up on his introductions is Michael. So go right ahead. Hey everyone. My name is Michael Mellos. I'm one of the co-founders of building better developers, also known as developer Nur. I'm also the founder of InVision QA where we help businesses, clinicians analyze their software, look at what their tools are and help them improve their processes through technology. We can build you applications. We can help you find better applications and we can help you even integrate what you have in a more productive, more automated way. Let's see habits. So I'm actually going to start with the good and bad. So the good for me was the fact that my wife went to see her sister for about 10 days. So I was able to really get caught up on a lot of stuff. So I actually was able to do a lot of fun stuff that I like to do, but in the same token, I was able to really catch up on a lot of work, which kind of leads to the habits. But the bad thing was for 10 days, I had to deal with all the animals we had in the house and the fact that we dropped to below 10 degrees, which here that, you know, for some of you, that may not be a problem, but when you have exposed pipes, that can be a problem. So I've been dripping water for almost 10 days straight and I have, it looks like one of those, you know, hole in the roof places. I've got buckets of water everywhere. Thankfully, we're warming up and those can go away. So let me get to the habits. So like Rob mentioned, you know, it's a new year. We're kind of getting in further into the year and kind of getting into the things that I like to do. So, but what I've been focusing on is kind of the anti habits, eliminating the things that just were eating up my time mindlessly. So while my wife has gone for 10 days, I literally watched two football games and turned the TV off for the entire 10 days. I take that back. I did watch one episode of fallout. I've almost cut up on the series. I got so busy I couldn't watch it. With that being said though, I was able to double down and focus on all my projects, really get caught up, really move things forward and made a lot of progress. So I moved my dial on what I wanted to accomplish further and I feel more productive, more energized where things are going. And I did that through things like working on automating my tasks. I worked on that through lists. Like I listed out all the things I do in a day and then I looked and was like, wait, I can automate that finally because we have built enough functionality into some of these systems that we can automate it. We don't have to be the one pushing the button. So that's been my week and I'm very excited about the conversation we're about to have today. And the conversation we're about to have today is about difficult, actually it's about fostering conversations. And this is something I think we struggle with a lot in the developer world. I've been in a lot and I may be overstating this, but I have been in a lot of standups and design and architecture meetings and stuff like that over the years. And one of the things that I've seen on a regular basis and that I have had people complain about various people, including myself, is that as developers, we have a tendency sometimes to just state stuff. And sometimes that scene is, I don't know, obstinate or arrogant or something like that. And people are like, hey, who are they to state that? And that's one issue. But I think the bigger issue, and this is as we become developers, as we become better developers, is not so much that we are seen as a jerk or something like that or arrogant in doing it, but it's that it shuts down conversation. Because when we're in a design meeting of some sort, when we are pitching ideas, the whole idea is that we, if we're pitching ideas, is that we need feedback. Just like, for example, every episode that we do, one of the things you will realize is that we ask for feedback. We ask for you to send us an email. And that is because we know that we are better when we have other people feeding what it is that we want to do. They're feeding these ideas into us so that now our ideas can blend with these other ideas. And eventually you get something that is a community effort in some extent. It is the idea of, if you go back to, you can look at like the Bazaar and stuff like that, and that's not, that's B-A-Z, not B-I-Z, but the idea of the wisdom of crowds and some of those kinds of things. And it's not necessarily that that stuff, I'm not going to go into those things as much, but it's the idea that like another set of eyes, another perspective is almost always going to help us out. Even if it's a completely distorted perspective, the fact that it's out there is something for us to know, particularly as developers. Because we have a tendency to get into like that developer focus, particularly with our applications where it's like, we're building it to do this and this is how it's got to be done. But that sometimes shuts out the idea of a customer that does something completely different from how we do it. Their process is not the same process that we have as we are building the software. That's why it's very valuable to talk to your customers, to, if you can, ride shotgun with them. They want to understand what a day in their life is like when they're using either the application you're going to build or that you've built or the applications that you're recommending to them. And so what we want to do is we want to find ways when we're in these discussions, whether it's with a customer or it's with our team or whoever it's with, that we foster feedback, that we foster a way to actually have a conversation as opposed to just stating something and moving on. And now if you feel like, if you feel convicted in all this, join the club. This is something that's like, it is something that I think that we do that people in our positions do. And so it's just something we need to be intentional about and cognizant of how we state things and how we do things. And it is a habit that we need to build to foster that discussion. Now if you go to any of the lots and lots of people that are out there that will tell you how to build better conversations, basically, they will tell you how to have difficult conversations, how to negotiate and things like that. There are, and there are excellent books out there. So I'm going to summarize some of this stuff. But one of the things I think, and this is going to get into our challenge, but it's One of the things we can do is we can try to be more observant about our language, about things like saying, this is how we need to do this, whatever that is, tends to sort of shut down conversation because you're basically, especially if you are the lead developer or an architect or something like that. Now, hopefully you're in an environment where people will question you and say, well, why do you have to do that? But a lot of times that's not the case. Particularly when you deal with entry level junior developers and stuff like that on your team. That is one of the struggles that I've had quite a bit is making sure when I'm bringing in and training up developers. So I have a very junior developer, one that understands, that feels like there's a mentor relationship, but also like having them question things and bring their ideas in and discuss their ideas because even if their idea is wild, crazy, out there on the left field kind of thing, it's still important for us to have that discussion and talk about why is that out in left field? Why is that not a mainstream idea? And also in doing so is not to say that it's bad to have something that's way out there because some of the best ideas, some of the best innovation comes from out there, nowhere close to where we're thinking about completely outside of the box kinds of ideas and discussions. So before I give you like some little magic things to do, I'm going to throw this over to Michael, let him give his his start on it and we'll get going on this. Sure. Thanks, Rob. So the funny thing about this one, we can go many different ways within this discussion alone. The one I'd kind of like to focus on a little bit is opening up the conversation. So like you said, you have this kind of mentoring relationship going with a younger developer or an earlier developer in their career. I've seen this many times over the years, many different companies, many different teams. And regardless of the situation, regardless of the dynamics of the team, almost every single situation has very similar kind of dynamics when it comes to speaking, when it comes to conversations, meetings and the relationships within the team. Some are really good, but over time these can erode because of deadlines, because you're under pressure to get things done. And what typically happens is you're because you're under the deadlines, because your head's down coding, because you've got to get things done. A lot of times we try to shrink that conversation. We try to shrink our meeting times, how much we interact with people. We almost become anti-social because it's like, here, here's my pitch. I got to go back to work. It's like we try to get out of these conversations as fast as we can. So we get into a lot of yes or no type conversations or statements we make. And that really doesn't get the conversation going. It's like, here, I said this, like, how was your day? That's an opener. It's like, you know, how's the weather? Well, okay, it could be raining, it could be hot, it could be cold. It's kind of an opener, but not really that open ended. It's like you kind of get an answer. And sometimes that kind of kills the conversation. Where I'm going with this is there are times when I'm in meetings, and I do this as well. In fact, I got myself doing this the other day where we're discussing a new project we're starting on. And we're, as a team, walking through our conversations of our concerns about deadlines, about how we want to tackle this and kind of break down the project into something that we can consume, but at the same time, the business can understand what we're doing and that we have kind of solid guidelines and deliverables and timelines and things like that. The problem with those types of discussions is when you kind of get that in your mind, if the person talking talks for a while, you might have a list of bullet points. Or in your mind, you're building this list, but you didn't write it down. So when they open up the conversation, you rapid fire all these comments out. And not only did you just kill the conversation, but the other person that you just flooded is like, crap, okay, what all did you say? And then you got a piecemeal. So the first suggestion or first point I would like to make is when you are speaking or when you're in a meeting and you have multiple talking points or comments on someone's talking points, write them down, make a list. But when they stop and open up the conversation for discussion, don't hit them with every single bullet point at once. Ask the first one, pause, wait for them to respond, then ask the next one. Or if you get other responses or comments, just kind of make a list. If you don't get through it all within your meeting, that's okay. That's what email Slack communications are for. Shoot them all aside and say, hey, I still had some questions on this. If you have time, can we talk about them or can you answer them here? So that's just one way to foster more communication and better communication. So you're not making those statements and kind of shutting things down. The second thing is to kind of keep the conversation going or keep the momentum going of enthusiasm. So like with those young developers, you sometimes can get into a situation where as a manager or as a senior lead, you're busy, you're putting out fires, you're in lots of meetings all day and you can get overwhelmed. You can get kind of burned out. It's like my time is very valuable. I've got a lot to do. What do you need? And so sometimes you can come across a little brusk and you kind of shut them down or you don't pay enough attention. So this can give us back to our focus habit. A little bit here is when someone asks you a question or they're like, hey, I have an idea. I know we're under a deadline or they may just be like, hey, can we try to do this or hey, I'm trying to figure this out and going this direction. Do you think that's a good idea? Now a little bit from the developer's perspective, that's not a good opener because that's a yes or no question. So you could immediately turn around and say, no, you need to be focused on this. And you essentially shut them down. But in a way that comment right there not only shuts them down, but could potentially stop their enthusiasm. It could basically mean, oh, I'm going to climb up. I'm not going to communicate. I'm not going to contribute anymore because either a, my manager doesn't think that my opinion matters or B, I'm wasting people's time or people think I'm wasting time. You don't want that as a leader or as a manager. What you want to do is you want to foster that. So yes, if you're under a deadline, say, hey, that actually sounds interesting, but right now, can you focus on this and let's circle back around to that maybe on the next team collab or maybe we can schedule a meeting. You can do a little presentation on this, work it out to where you can kind of get more information at a different time. If now is not the best. So I know I've talked a little bit about a lot, but I've given two solid points. Let me pass that back over to you, Rob. Well, first off, I want to, I guess I'll start with the opening conversation. I think that is the first part you talked about is very key is I think we get into stuff and I was laughing because Michael has, and I've worked together for years and he has seen me get into get it done mode where it's just like bam, bam, bam, like do this, do this bullet point, bullet point, bullet point. I don't have time to do anything, but get this stuff done. And he, he does the same thing. So he can relate to that. But that also shuts down conversation. And it's an interesting challenge for us because that's actually part of our goal is to shut down conversations in those situations where like, it's basically I got crap to do, I don't have time to have a discussion. We need to like, we do know we have a task to do, so let's get the task done and move on and there probably is value. There is value in that, but let's not do that in conversations. If you're in a situation like that, then push that from a meeting to an email or something like that. If that is literally where you're at, then the best way to do it is email. And so try not to, you know, try to avoid the meeting where we're going to quote, discuss this, if you're not going to discuss it, say, here's what my thoughts are, or here's what I think I need to do. Correct me if I'm wrong. Now there's a good example right there. The opening up this question of the discussion. If you say, and I did a slide, I'll say, does that make any sense? Or correct me if I'm wrong or is everybody okay? All of those are yes, no, essentially yes, no answers. They do not draw people out. And particularly if you've got a room full of people, if you've got even three or four people in there and you say, okay, does anybody have anything to add or anything like that? It doesn't really, it leaves it open for them to essentially just be quiet, to not step forward. Now, if it's a one-on-one conversation, then those things work a little bit better because you're like, okay, well, what do you think? Or something along those lines. But with a crowd, you want to say, like, call somebody out, maybe be like, hey, Michael, what do you think about this? Or is that the approach that you would take? Things like that, that draws them out. And while it's still a yes or a no, sometimes you want to like, and this is where we get into the challenge, but it seems like maybe change that from that yes, no to things like, how would you improve this? Or what would you do to make that better? Or call out a piece that's questionable, which is always, I think, a challenge that we have. I know I do it. I'll talk about a solution and there'll be a piece in there that I'm proposing, but I'm not as comfortable with. Those kinds of things where you're like, okay, and we do this a lot. We have portions of a solution that are just, they're basically set in stone. We know what we're going to, it's done at a thousand times. It's really not up for discussion. But then there's other pieces that are up for discussion. And then those are the kinds of things where maybe you'll say, like with a customer, say, okay, this is a solution I'm proposing. Let's walk through what that would look like for your daily work or something like that is turn it into something that is a conversation. The easiest way is always to have somebody say, Hey, can you state back to me what I just saw? How do you see that? Can you tell me what I just told you? Sometimes that's a little bit ponderous to do, but if you can walk through the solution with them or something along those lines, then it doesn't feel like it's putting so much on that other person. It's something where it's like, okay, let's as a team walk through this, this challenge or this problem. Now I do want to like sidestep just a little bit from that, that mentor kind of relationship and stuff like that. And this is, if you're maybe on the other side, if you're a, you know, you're a junior developer and you have a mentor, or if you're a, if you've got a manager that you doesn't, that you're not comfortable having conversation with, cause you feel like they state too much what's going on. And this is also for something, if you are that mentor manager that too often, you just like state your opinion and there's no discussion. I want to talk about my, just briefly, my relationship with, with what is probably my primary mentor over the last 10 years or so we have, whenever we have talked about software development and he's got 20 more years of experience than I do basically, and in very different environments. One of the things that we agree to disagree basically is that he loves waterfall. He thinks that waterfall is the only way to do software because of the way he does it. And I am a firm believer in agile because of the way I do it. But, and we've had a lot of discussions. We've had a lot of, you would even say arguments and disagreements about this over the years. And we have butted heads and stuff like that. But to me, and I think probably to him, but definitely to me, there is a ton that I have learned in having those conversations, those difficult conversations that those arguments and those debates basically, and they sometimes get a little bit heated, I guess, not too much, but I mean, they're like, we very much have strong opinions where we're at, but they've been very educational because even though I will hear, listen to him, you know, talk for 15 minutes about like a project and how it worked and how it all went through, and I will right away come back with that laundry list like Michael has of like bullet point, bullet point, bullet point, and we'll go back and forth on those. That story that he gives me, those examples he gives me are all things for me to like put in the back of my mind of like, okay, this is where that works. This is where maybe my approach is not the best approach. And those are the things that are going to make us better developers is when we're hearing that there, and this is like that outside of the box or a different perspective is looking at it and saying, you know what, I have always done this kind of a project or had this kind of approach, but there are other approaches out there. There are things that are very, very different that are still a hundred percent valid, and that is going to be very helpful to me when I get pushed into something or I accept a project and suddenly it's not the standard project I'm used to, for example, then I can lean on the experience of other people and some of their input in those kinds of situations. So don't be afraid of some debate. Don't be afraid of pushing back, regardless of where you are in the situation, because questioning those things, even if it is the things that are the unquestionable stuff. Yes, sometimes it is frustrating to us that somebody's questioning something that we're like, that's a given. It's like the sky's blue. Let's not discuss. Let's not debate the sky as blue, but it is worth us to find the time to have those debates occasionally to say, is the sky actually blue? Let's go out and look. Let's make sure the sky is still blue because particularly in our world, we will get into stuff, we will get into technology, we'll get into approaches and all this stuff and it will change. And that is part of like, that's part of what I talk to customers about all the time and they will say, this is the way we've always done it. And even I will say, this is the way I've always done it. But when I say that, I'm usually going to go back and say, okay, well, is there a better way? Is there a different way? Is this still the best way? And when you do those kinds of things, when you ask those open ended questions that are like, and think about it, it's, and that's going to be, as we get into the challenge, it's like, try to avoid binary questions, whether it's a yes, no, or a okay, or not okay, or something like that, or even worse, a very simple answer and a very complex answer. It's like, don't make people choose because they're almost always going to say this simple answer. Uh, thoughts before we throw to the, we jumped to the challenge. The only other thing I'll throw out within, uh, the podcast itself is kind of read the room. Don't force your openness. If everyone's kind of shut down, everyone's quiet. You can maybe try to go with an icebreaker to get things going. But if, for instance, you're dealing with a very tough conversation and people start showing them because their feelings are getting hurt or people are getting upset, that's okay in some situations to let those conversations, it kind of. Slow down, maybe end that conversation. Take a pause, come back, maybe one-on-one with individuals or do it at another time when people are fresh and have time to calm down. I have been in discussions before over this, uh, you know, this technology versus this technology is like, why is it, you know, like you said, with the waterfall. And at a certain point you have to check yourself and say, Oh, wait, I'm dry. You know, basically we're, we're button heads to the point that the conversation is becoming an argument. So avoid that. Take a pause, take a break and just again, kind of read the room and keep fostering those open conversations. Don't shut things down. One of the ways we don't shut things down is we ask for feedback. And yes, I haven't given you the challenge yet, but I will. But after this, make sure you have any suggestions, recommendations, comments in general, shoot us an email at info at developernord.com or check us out on developernord.com, put a, you know, fill something out in the contact form. Uh, we're also on Facebook. We're on X we're out there in various places. Leave us a comment or feedback on YouTube, the developer channel. We would love to hear from you. We would love to find ways to further this discussion and the ways to build better developers. Now your challenge, probably sort of figure out where we're going to go with this. What I want you to do for the next seven days is at the end of the day, or even better yet, probably at the end of a meeting, preferably each meeting is spend a little time, just like a couple of minutes reviewing where you made statements or where you tried to foster discussion. Now, first, if you didn't foster discussion at any point, I challenge you the next conversation you have, the next meeting you have to foster discussion. Try to just try it. Now, assuming that you do at some point that you went into a meeting, hoping to get something out of the other people that were in that meeting. Review some of the statements you made and just, you know, now stepping back a little bit, honestly ask yourself, was the statement I made or was the question, we'll call it the end quotes, the question that I asked, actually a question that fosters discussion, or was it something that was basically, it was either a yes-no question, which didn't really, doesn't really foster discussion, or was it something where it was bad choices because it's either very, very simple or very, very complex and nobody, if somebody can spend two seconds versus spending 10 minutes, they're almost always going to choose the two seconds. So do that this next week is every time, every next seven days, try that out. And then let's see how that works as far as fostering discussion. Now we may have to have a future one. If discussion gets too far, how do we rein it back in? But let's start with fostering discussion first, and then we'll figure out how to herd the cats of the discussions gone bad, as we say. That being said, we're going to continue this discussion in the next episode. We're going to continue moving on through all of these things. Get close to the end of this season. We sort of thought of, we're not really sure what the next season is going to be. So we are more than happy to get feedback from you. That being said, go out there and have yourself a great day, a great week, and we'll talk to you next time. Thank you for listening to building better developers, the developer 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.