How Do You Measure Soft Skills in Software Engineering Teams?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just going to the comments for a couple of questions today. I'm going to do two videos back toback. So the first one, this is from Carlos Ortiz 8789. So the question is, how do you measure soft skills in your team? So let's say when you have people who deliver tasks but are not good team players. So I think it's a great question. Um the short version of that is like uh it's not tolerated. Um, so I have worked uh either I guess like fortunately I haven't really had much of that with people that I manage, but I've worked in environments where that's the case and it's too it's far too toxic for that to even be like an acceptable thing. Um, so the framing for this is like like in software we're building stuff as teams, right?

And it would be almost like impossible to have one individual that is performing so well that they are better than the entire rest of the team that they're holding back by basically being an So it's it's just simply not worth it. And further like the I think the amount of gain uh that you can get by boosting up those around you will always outperform having some single individual that you know is is kind of the the bottleneck or you know the person that's so good but like such a bad team player. So you know the the very short version of this is that it's just it's simply not the path forward. Um I will always take people um or value people that are better with soft skills working better together than you know a single individual that is uh sort of like a net negative in terms of uh team interactions just because their skills are there.

Technical skills things like that are um in my opinion much easier to invest time and effort into to get better. and the the soft skill side of things is significantly more difficult uh to sort of like course correct. It's not that it's impossible, but the you know if someone were you know if I had a team where people were uh maybe less technical because they had less experience or they hadn't been working in a domain long or or whatever it happens to be but they were like um energized to learn. They were good team players. They could collaborate. They could work effectively together. those individuals I can spend time coaching with. We can find skill opportunities like things to build up experience, build momentum. It is so much more difficult to try and take someone who is you know highly technical or has you know some proficiency that's uh that's technical and and try to sort of correct their ways or uh coach them through like soft skill challenges and it's doable.

I have worked with people who have had some soft skill challenges and it takes a lot of time and effort but it's kind of like depends right like when it's things where people don't have awareness of what they're doing like coaching them through that is um I don't want to say it's easy is not the word uh it's easier it's a um it's better it's more realistic than trying to coach someone where you're like look I have to change your personality because you're an And uh a lot of the time it's that people are not It's it's just that they um they don't have awareness that the actions that they're taking are having a negative consequence. But but sometimes it takes a lot of work to to kind of sift through that. So um yeah, like I will they're asking how I measure.

So, I guess I I'll talk about that, but you know, to to be transparent, like I will I will never value someone who's just highly technical and they're not a good team player over the inverse. I would much rather have a team of uh people that can collaborate versus, you know, um one individual that's like toxic to the whole team just because they're good. Would never take that option. Um for context I have seen in multiple times in my career where when a person like that is removed from the team you literally watch the entire team transform after that and uh like productivity across the entire team like engagement across the entire team everything goes up it's nuts. So uh from my experience I would never prioritize the other over that. Now, how do I measure this? Um, kind of interesting question. I don't think it's like a this isn't something that I would have a like a direct measure on like a a quantitative thing.

I think um I think this is observed through different experiences where people are working on projects together. So there's there's a balance between like and this is kind of the case with like all sorts of engineering work where there's things that you do on your own. There's things where you need to collaborate. So for example, if you're putting a design document together, um there's different parts to that design document phase where you're going to be doing parts of it on your own. Like you don't need a partner or the rest of the team to do all the writing with you necessarily. You might be collaborating on some of the writing and doing a joint effort, but there's going to be parts of that you're just writing on your own at least to get down um you know in the document. There might be data collection and you're putting some of that together on your own.

Some of your initial analysis you are doing on your own. There's problem solving, investigation that's there's aspects that you will do on your own, but there's going to be parts because it's a design document where we need to come together. We need to review the analysis. That's going to be collaborative. You're going to walk us through what that looks like. How did you get to these conclusions? Where did this data come from? Let's talk about that. Let's make sure that the data that you're showing us is representative. The analysis is sound. Like those are things that we will collaborate on. Right? So, there's different parts where you do things sort of on your own or in isolation. And I'm saying that um not to suggest that like all of those pieces are in isolation. It's just that you can do uh like a varying degree of it in isolation.

So because you have different components of this, I would say if I notice that someone for example, they're doing a design document. If they never collaborate with anyone and then they get a design document together and then they're like, "Well, I just need people to sign off on this." I'm like, "Well, hold on." on like when you say just sign off on it, like did you have a conversation with them? Did you walk through it with them? Did you uh did they have an opportunity to put comments on the document that you responded to? Uh like was there any collaboration that went into it or did you just say like I did it now like basically give me your blessing and like sign it. Um because if that's a common pattern like that's not actually collaborating that's just like you working truly in isolation and generally not good.

But um you know there might be you could take a flavor of that example and say look like someone did they went off and they did a lot of analysis on their own and it was really good. They collected a lot of really good data and then they brought it to an audience like they they basically engaged in the collaborative part at the right point in time where it's effective for everyone and then got feedback on it, made the adjustments um had to hold a meeting because there was disagreements and they wanted to clear the air. Um, so like when I there's varying degrees of all this stuff. So if I see that kind of stuff happening over time where people are actually working with their colleagues like that's how I start to to recognize like that kind of stuff's happening.

But we observe this kind of thing in all aspects of software engineering right like it's um could be you know standup or sync meetings standup meetings like you're never present for them like okay and then if you're always behind okay so you're always missing targets for things but you're never attending sync meetings or sharing status like okay that's a you know challenge with collaboration I would dig into that I'm not just going to blame someone for it but like okay well what's up like is the meeting at a bad time do you not feel like you and represent yourself there like let's talk about it. Then you have code reviews. So like you know if if I'm basically getting feedback from other people that on poll requests and code reviews that like that you are constantly blocking in unhelpful ways where people are like I don't understand like I don't want to put this person on the code review because all they do is nitpick about things.

They don't explain things. They make me feel stupid. like those again that probably isn't adding up in a positive way to the um the soft skill part. But in all of these cases for what it's worth and you could keep going down, you know, all these different types of interactions we have in software engineering, my go-to will always be to try and understand that person first. So, for example, I mentioned like you're not attending the sync meetings and then you're falling behind on stuff. I'm not just gonna label someone like, oh, they must be a shitty developer and have terrible soft skills. Like, no, let me go understand like what's going on, right? I have individuals um who are in different time zones and if we have a sync meeting that's late in the day, like it's at 6:00 p.m. and they're 3 hours off and it's 9:00 p.m., like they might not be able to make that and like that's okay.

So, cool. Like, do I understand their status? Are they getting the updates they need? like do they have a way to make that work? If so, great. But I would want to understand that before just going, wait a second, like this person's never here, so therefore they're bad. Same thing with code reviews, right? So if someone if I'm getting feedback uh about someone on the team where it's like, you know, they're causing a lot of friction, I can't seem to like have them on code reviews effectively. The comments are unhelpful or they're making me feel dumb kind of thing. I'm not just going to assume therefore other person must be bad. Let let me go see let me see the examples like oh like let me see how they're leaving comments. Let me see how they're engaging back and forth. Let me have a conversation with them.

Right? I've worked with people where um com absolutely totally genuinely were trying to help and what they like how they were phrasing questions or why they were asking questions is they're seeking to understand at what point someone was getting stuck. Okay? So, they're asking questions being like, "So, their goal is to be like, I see that you went down this path and like I want to know like like where you got stuck along the way so I know when to kind of like how to start framing up how I'm going to help you." But what they end up doing is they ask someone like, "Why did you do it this way?" Now, what happens is like the receiver of that question goes, "Well, what the hell do you mean, man? Like, like why are you challenging me on this? Isn't this the way to do it?" And then they start to feel like they're being made out to be stupid.

But the whole goal of the person asking the question was just like, "Look, man. I saw you went down a path. I want to know where and how you got stuck. So, I'm asking you this just so I know how to start helping." So, I've literally worked with people like this where and then if you layer in things like uh written communication or uh English not being a first language, different cultural backgrounds, all these things can stack up to make communication more challenging or less clear and you take something that's supposed to be very helpful and all of a sudden is coming across like it's condescending uh or patronizing and people are like, "I don't like this person. They make me feel stupid. Right? And so if you don't dig into these situations to try and understand them and you just start labeling people as bad with soft skills, then there's no opportunity to improve them.

So overall, just to kind of wrap this question up, I don't have like a direct measure, but there's a lot of things in different interactions that I'm trying to observe, getting feedback from people, and making sure that I seek to understand why those types of things happen with individuals so I can coach them and work with them on that before just saying like this person's bad, right? Um, so hopefully that makes sense. uh this is in my opinion we talk about like engineering manager responsibilities and that kind of stuff like I feel that that is one of the most important parts of my job and other people can completely disagree with that because there's so many other things that we have to do as EM but um like I can't understate how often this kind of thing happens and and how negative of an impact it can have on teams when you have like weird friction like that that that's avoidable, right?

Um, and it's I I think exacerbated by being remote a lot of the time because you're not having like the body language or the tone of voice. It's not just remote, could be written like communication, but you stack all these things up and suddenly like, you know, if your soft skills were like maybe on par or a little below, it's almost like they multiply in a negative way um when you you stack up all those things. So, just something to think about. But hope that helps. I think it's a great question. If you have questions you want answered, leave them below in the comments. You can go to codemute.com and submit questions anonymously. So, check that out. And then I have a few other YouTube channels. So, if you want programming tutorials, head over to Devleer. If you want resume reviews and to check out other people's resumes and how they structure them, devle path to tech.

And then there's the Devleer podcast where I interview other software engineers. and I host a live stream every Monday, 700 p.m. Pacific. Would love to see you there. It's topics just like this one. Take care. See you next time.