Is Your Communication Style is Holding You Back as a Software Engineer?

Transcript is auto-generated and may contain errors.

Hey folks, leaving CrossFit Saturday. I uh recorded the video on the way to CrossFit, but the funny part about recording the video on the way to CrossFit is I didn't press record. So, I talked I talked into a microphone and a camera that wasn't recording like an idiot. Um, no, I got a topic for today. Uh, I think it's an interesting one. I already lost it on experienced devs. Like, I was just at CrossFit. It's already I can't find it. Um, but I think it's an interesting one. I like topics like this because to me they highlight some of the other stuff that goes on in our software development jobs. It it's not just coding, right? Um this is some of the stuff I hammer on non-stop is like there's so much room to grow as a software engineer that has literally nothing to do with the code you write.

So um again I lost it so I'm not going to read it out. I'm also driving a car. So the uh post was essentially like hey anyone else experience this where you have sort of um in meetings and stuff like that you find it more difficult in terms of verbal communication um but in terms of written communication like you feel like you excel at it right so you've been praised for documentation that kind of stuff but uh going into a meeting it can be like sometimes overwhelming or feel slower I think was the the word that was used feel slower than your peers So I said, "Hey, that seems like an interesting topic. Definitely something I've observed in my career. Uh especially as an engineering manager, I think that this is a really important topic." So, um before I dive into it, just a reminder if you're new to the channel, um this is a channel where I take questions, so leave them in the comments.

I'm happy to answer software engineering and career related questions. If you're not, pardon me, almost died. If uh if you're not comfortable with that and you want to send them in uh and be kept anonymous, you can message dev leader on social media. It's also my main YouTube channel and uh you can find me basically on any platform. If you can't let me know so I can go make an account there. Uh otherwise LinkedIn it's just Nick Cosantino. Happy to help. And uh I will mention because I have it scheduled that um I'll be changing sort of this intro format in a little bit. So, I plan to do a live coding stream on Monday, May 12th. It'll be recorded, so if you miss it, you want to check it out, that's fine. It's going to be on my main channel, though. And we're going to basically vibe code with agents.

We're going to build the landing page for Code Commute, and that will be the new spot to send in uh anonymous questions, and that way people can still comment, but we'll have a landing page because I own code.com. should put it to use, right? I think code.com redirects to YouTube right now. So, we'll make it happen. Okay. So, why is this so important? And I think the the reason that I think this is a good topic is that this is just highlighting that um there are so many different personality types and different things that make us unique, different things that make us good at certain things have weaknesses in other areas. And if we're uh sort of ignorant to those differences, um there's so much missed opportunity. There's so much opportunity for friction instead. So um I think it's a really good topic to kind of narrow in on.

So um this person was explaining that they feel that they are they feel slower than their peers. They feel like they need uh like written communications way more effective. And if you think about meetings that you've been in or that you've organized, right? Have you been in situations where it's like, "Hey, we're going to talk about this topic and then you go into the meeting and you know like the topic of the meeting because of the invite, but like you don't know the data that's going to be discussed. You don't know some of the like the you haven't reviewed like the evidence or anything ahead of time. So, it's just like you get into this conversation and it's like, "Okay, let's start going." If if you're thinking about a scenario like this and you're like, "Yeah, what's the big deal?" You're probably the kind of

person, and again, there's uh I don't know all of the different personality type systems that exist, but if you do some homework on this kind of stuff, there's a bunch of them and they highlight things like this, but you might be a personality type that is totally okay with this. Um, I wish off the top of my head I could list off a couple of different personality types from these frameworks, but I simply cannot recall. Um, I have gone through some training on this stuff before, uh, which is kind of rare because I feel like as managers, we don't get anything. But, um, there are certain personality types that really need data. So, if you're thinking about a scenario like that and you're like, man, that sounds like those meetings are the worst. Like, I get frustrated. I don't know how I'm supposed to be effective in those.

you're probably this kind of person and that's okay, right? So, my key point that I'm going to be rambling and stuff because that's what I do in these videos, but the key point I want people to take away from this video is like have awareness that there are different personality types and that there's some pretty simple steps you can take to accommodate those types of things and they just make meeting and collaboration so much more effective for such a little investment into them. Okay, that's you can end the video right there. That's my takeaway. Okay, so in situations like this, I think if you're thinking about trying to schedule a meeting or trying to get some collaborative type of thing going on, I want you to keep in mind that um you know, if you're scheduling a meeting, first of all, you should have the goal of that meeting in the invite.

It should be very clear. Um this is a bit of a tangent, right? If you are schedule a meeting and you're like, I can't articulate what the goal of the meeting actually is. You're not ready to schedule a meeting, plain and simple, right? You might actually have one, but you should know how to articulate it so that other people understand the goal of the meeting. I very much advocate if someone invites you to a meeting and it's not clear what the goal is. One, you should be able to reply and just say like like I can't go or I'm not going to this or can you clarify because if you don't know, it's not a good use of your time. And the other thing is if you do know the goal, then you can make an informed decision about whether or not it's a good use of your time.

Right? You might know the goal and you're like, I don't know why I'm invited to this. This doesn't make any sense why it need to be there. Go clarify that. Right. Hey, are you just trying to include me so that I'm aware of it? If so, great. Thank you so much. We had to get through that light. Um the uh you know, the other thing might be that you clarify with someone and they're like, "Hey, we actually wanted you to share something about some scenario or you seem to have some insight into X. Might not have been obvious from the invite, but that's why you should be here." Okay. Anyway, that all aside, when you're scheduling meetings, goal must be clear. Next part is that if you know that you're going to be discussing a topic, if there is data or some type of document or some type of evidence or whatever that needs to be reviewed, send it out ahead of time because it gives these types of individuals what they need.

They need to have data ahead of time so that they can review it so that they can bring more value into the conversation. Okay, I am probably more this type of person, so I I get where they're coming from. Um, when I did the first take of this video, one of the things I was mentioning is that I find as an engineering manager, I get pulled into all sorts of all the time. Most of the time, you know, people aren't sending out stuff ahead of time. And there's no prep. It's just like get into a call. We're trying to figure stuff out. And like I I basically I have a lot of experience having done this. It's kind of built up the skill of dealing with ambiguity, but like I don't recommend that that's your your first course of action. It's not it's just not something I would recommend to people because you have tools to try and avoid it.

So, if we think through an example, if I needed to like get called into a design review, if someone hadn't sent the design out ahead of time, I know some people do this like pre-eread thing in meetings where it's like an hour meeting and you spend the first 20 minutes reading together. I think like Amazon's pretty big on this. Like, doesn't do it for me. Yes, thank you for the 20 minutes of dedicated time where I can read it. I need time to like think about stuff. So, it's still not sufficient. So, send it out ahead of time. Let me read it. Let me sleep on it. Let me, you know, come up with conclusions like come up with questions. But I I am not the type of person that is effective at reading something and immediately being like, "Okay, let's dive in." Can I do it?

Yes. Have I done it a million times? Yes, maybe not a million, but a bunch. It's not an effective way for me to operate though. Compared to something like send it out ahead of time, let me read it. So, um, another example of this is, uh, the big project that I just wrapped up that was like 5 months long. We would do both. We would send out the document over 24 hours in advance, right? um or the earlier the better, but like big project we're we're coming out of the wire a lot of the time with uh getting documents ready. So get it out ahead of time, let people review for the people that need to be able to review it that way. And then we still carve out time in the beginning of the meeting for a pre-eread. Okay?

And I can tell you that over the course of those 5 months, even the same stakeholders, this is I'm not saying who, I'm not saying what, but the same stakeholders used those different mechanisms differently each time. So one like if we pick one stakeholder, they would uh in some cases pre-eread like ahead of time, have comments in the document and stuff that we could dive into in the meeting together. Uh other times they needed the pre-eread time at the beginning of the meeting. Totally fine. That's why we have it. And other times um basically like did a quick check before and we spent the time like kind of highlevel reviewing it instead of diving into some uh specific. So like with even with one stakeholder doing like all sorts of flavors of this right. So giving more opportunity for people to be prepared is huge. Okay, it's it's such a little thing, right?

You're scheduling a meeting like just attach the information that's necessary, right? Um do it if you have it. Um and I I think that some people will, you know, will greatly benefit from that. The other thing that I wanted to encourage uh as part of this conversation is like is just the awareness of it. So, little challenge for anyone listening to this, right? Is like if you haven't really thought about this kind of thing before, because it sounds kind of like it's kind of Like, it's not code. I don't really care. Like, thanks, Nick. Whatever. Um, I get it. I hear you. I know it doesn't sound that exciting, but like you work with people as a software engineer, right? So, um, you can practice coding all you want and it's awesome that you can write better software, but you're not going to be a better collaborator if you're not thinking about how people operate.

So, I do challenge you if this seems like kind of a new thing for you, try to think about when the next time you're scheduling a meeting or some type of collaboration, try to think about how people are um reacting or behaving with with data for meetings, right? Do you notice that some people are asking like, "Hey, can you send out whatever or can you clarify this?" You might notice that some people in particular more often than not are the kinds of people that are like, "Hi, I need more information." Right? They've experienced it enough, it's a big enough pain point for them where they're like, "I'm going to be proactive. I don't see what I need. I'm speaking up." Or can you maybe be observant and see if there's other people that they're quiet in meetings? Okay. You know, lots of really smart people that you probably work with.

You might be one of these people, but quiet meetings because like it's not that they're scared, it's not that they're not intelligent, but they don't have like the facility to get their thoughts together and get them out in time in the meeting. It might be stuff that you're learning for the first time in that conversation and as a result you're like I'm not I haven't fully formed my thought like I need to I need time to think about this and then you don't get it out in time in the meeting. So be observant. See if if you notice anyone that's like that, right? Because if you do, what you could be doing to try and build on this skill is follow up with that person after. Say, "Hey, I'm just trying to, you know, check in with people after that call, after that discussion.

Uh, you know, I wanted to make sure if you had any other thoughts or something did you want to anything you wanted to share that you didn't get a chance to in the meeting." Like trying to be inclusive to make sure that uh their voice is being heard. Right now, next time you might be reminded from a conversation like that that hey, you know what? I should have taken the time to to get some extra details out ahead of time. There's always going to be stuff in situations where things come up in meetings and people are like, "Oh, I haven't thought about that kind of thing yet. I'm not prepared to dive in." That's fine. So, it's not like it's totally one-sided, right? The people that uh have, you know, kind of struggle with getting their thoughts out in meetings, it's not that we should just say, "Oh, they don't have to work on that." And of course they should try working on that and improving.

But while they're doing that, you should also see if you can try to accommodate enabling them to be effective. Okay? It takes very little investment. So I'm just pulling up uh to the house here. So just to recap, right, different personality types uh will be able to thrive in different ways. It's not good or bad. They're just different. There's different strengths and weaknesses to that. So keep that in mind. I challenge you to try being observant about the people you're working with. Challenge you to try being inclusive to different ways that people operate. Get your meeting goals written down. provide data ahead of time and work on being a better collaborator. See you next time.