BrandGhost

Are You Too Blunt? - 2 Communication Tips For Senior Software Engineers

As senior software engineers, it's more important than ever to have solid communication skills. When you're working with more junior developers, you have such a great opportunity to improve their working experience and help them gain confidence in their role. But how can you balance being kind, thoughtful, and verbose in communication with... being blunt? Is it ever acceptable to be blunt? Let's see! Have you subscribed to my weekly newsletter yet? A 5-minute read every weekend, right to your i...
View Transcript
as more senior software Engineers it's really important for us to be thinking about how we're communicating not only with our peers but especially with developers that are more Junior than us if this isn't something that you've thought about before then I'm hopeful that this video will get you thinking about that going forward and when I talk about communication here I don't just mean like if you're answering questions or helping people solve problems by par programming with them or whatever it happens to be but more about the style of your communication I wanted to put this video together because it's been a pretty relevant topic recently with work and some other things going on when it comes to feedback how that's being delivered and how it can be interpreted and I realize that there's this opportunity for us to reflect as more senior software Engineers about how we're doing that so previously I've made a video about this concept of no but and yes and it's not something that I've coined or made up on my own but I wanted to make that video to illustrate how you can change some of your style of communication to be a bit more collaborative in situations where you might not have even realized that you're being dismissive I also put out a video recently related to this topic that we're going to go through today for more junior level Engineers being able to provide feedback to their peers and also receive it so that video was intended for them because if people like you watching this that are more senior haven't actually gone through this exercise that video is supposed to help them kind of be prepared for crappier communication a so how can we avoid the crappier communication that I'm talking about well let's start by going over what I mean by crappy communication I think it's pretty common as more senior level software Engineers are getting more tasks more high level priorities and all sorts of things going on that some things just don't get as much attention and that might mean that how you're communicating and messaging to other people is getting shorter trimming out some context and you're feeling like you're just being more effective with your time and how you're mess messaging things in the video that I created for the more junior level software Engineers the thing that I was trying to call out there was this idea of trust and respect and because you're a more senior level software engineer the idea is probably implicit for you that you should be commanding a little bit more respect just by virtue of being more senior and I think that's partially fair right like given your title your experience there's some amount of respect that should come with that and some amount of trust that should come with that as well now you might agree or disagree with that I'm not saying that everyone should just blindly believe everything you say that's kind of ridiculous but in general more junior level software Engineers are going to trust and respect the things you're saying because they don't have anything else to go by yet but you have this really powerful opportunity as a more senior level software engineer to improve this communication so when I talk about crappier communication the way that I look at this is that the person receiving it doesn't fully understand your intentions and they don't necessarily understand the point that you're trying to drive at now you might feel like you've communicated something say on a Cod r viiew or a design document where you're saying something like this part of the code is bad or this design is not going to work or this part of the design is not going to work and you're probably getting tons of code reviews and tons of design docs to go through and add your thoughts to but one of the challenges that you face by doing that and kind of skimming things and glossing over not adding the context is that the person on the receiving end has a harder time understanding what they're expected to do so you might feel like that being quicker in communication by just calling things out and getting through more volume of the things that you're responding to is helpful but the reality is that until you've actually established a good working relationship with this person they're not fully able to understand the message that you're trying to get across to them and even after you have built this good working relationship it's something that you probably want to keep up and revisit to make sure that when you're being really succinct with your messaging that you're not missing context so to meet crappy communication from a more senior software engineer to someone more junior is missing out on context like why and also how so for example going back to a code review calling out that some code is bad tell them why why is this code bad well it's a design pattern that we stopped using because of whatever or it's not safe because I don't think that you've considered this other scenario that could break this execution okay so offering some context why is super helpful for them to understand why you're bringing it up and the how part is also a great addition because if you're just leaving them there with here's some other information you didn't think about have fun now it's up to them to go figure out what you want to see in some cases that can be a good balance where you're giving them a little bit of a challenge to go do some problem solving and navigate things but if you're going to be very particular about the thing that they're going to deliver it's really helpful for them if you're just explicit give them an idea of what you're expecting explain how you expect them to go solve that so that your concerns are gone so if you're saying hey this code is risky because you didn't consider these scenarios explain how you might go address that you might want to go check these states to make sure it's safe you might want to validate these input variables whatever it happens to be but giving them the why and the how can be tremendously helpful for them to go receive that comment and go do something with it the other thing that I really encourage you to do and this isn't a mandatory thing because everyone has their own communication style but it's trying to layer in something positive in your message and you might be hearing this going okay Nick I don't have time for that kind of stuff software engineering isn't all about pleasantries and just trying to be nice and putting happy faces on everything and I get it like we all have a ton of stuff to do but I think that it can go a really long way especially for really Junior software Engineers that for a lack of better word probably feel terrified about putting code up for review and having you go Grill it give them a little bit of that positive reinforcement something like hey this design was pretty good I really appreciate you putting in the time for it I think you've addressed this part really well I think that this other part over here needs a little bit of attention because I don't think it's considering X Y and Z here's how I might go approach that something like that can really help offer up to them hey look you didn't totally blow it you don't suck some of this was good the positive reinforcement can help them not be defensive and not totally shut down when you go to give them that feedback that they really need to hear so we've touched on a little bit what bad communication might look like trying to use some examples of code reviews or maybe design documents I think those can look very similar and I also talked about a couple of tweaks that you can make really simple in your messaging that are really about just trying to be a little bit more positive adding some of that in to sprinkle it in and then some context like why and how to really help clarify for the more Junior engineer about what you're expecting now the final part that I wanted to talk about in this video is this idea of when you can can be a little bit more blunt in delivering feedback and how that can actually be super helpful in some situations now this isn't something that I've come up with at all and in fact the advice that I was just providing I don't want to suggest like I invented that or anything it's just something I've seen work really well but this part here is radical cander that's the thing that I want to talk about when we have radical cander what we're able to do is actually provide feedback to someone that we have a really high level of trust and respect with both ways and we can be very blunt with the feedback that we're giving without those two things trust and respect the person receiving that blunt feedback might be there like holy crap why would this person ever say something like that to me because it's really hard to hear but when you have radical cander when you are in this position where the person knows that you were just trying to help them you want them to succeed in every possible way high degree of trust and a lot of respect when you're very blunt like that that person should be able to figure out that you just want them to win you're telling them that hard thing because you want them to succeed it's like in friendships if you just have friends that tell you what you want to hear that might feel good in the moment but your best friends are always going to tell you the hard stuff the stuff that you need to hear to be better I feel like this kind of thing is unfortunately rare in software engineering and perhaps in other professional Industries and different careers but I think it's such a powerful thing that if you can establish that that it can really help drive people to higher levels of success so because you are a more senior software engineer I want you to think about these relationships that you're forming at work with your colleagues and your peers and the different levels of trust and respect that you have with them if you have peers that you're working with and it's low trust low respect the idea of radical cander might not fly so well you're going to have to invest more time in into that working relationship to ensure that that person does have a lot of trust with you that they do respect you and your opinions and that they know you just want them to succeed however if you're dealing with more Junior software Engineers perhaps people on your team that you're helping coach and Mentor this is a really great opportunity because that interaction that you're already having is building up the trust and respect with them now jumping into that right away especially with someone junor is probably pretty risky because if you feel like they respect you and they trust you only because of your title that might not fly so well because you actually haven't built up that working relationship where that's kind of come naturally and implicitly because of your interactions together so just something to consider but this is probably something that you can gauge from having one-on ones with them frequent conversations and Reflections about how they're doing and it's not going to be something that happens over a couple of days or just a couple of weeks this could take months in fact this could take years and that's okay because in software engineering and the teams we working in I'm hopeful that you are working with different people even if it's at different companies and things change right the different people that you're working with and engaging with throughout your career those relationships that you're establishing I'm hopeful that you can get to a point with them where you have more people that you can have this radical cander experience with so to bring everything back together together unfortunately as more senior software Engineers we can sometimes really suck at communicating but that doesn't mean that there's nothing you can do about it the first thing that you can look at is trying to be more clear in your communication especially with more Junior people just so that they understand your intentions that you're trying to help them and that you're giving them a little bit of information about how you'd like to see things improve and then the other part we talked about is this situation where you can be more blunt with the feedback and what that really needs to look like in your working relationship for that to be effective without the high degree of trust and the high level of respect something like radical cander and having blunt feedback that can backfire on you and make it feel like the other person really doesn't want to work with you so these are just things to keep in mind especially as you're becoming more and more senior I'm very hopeful that the working relationships you form and the influence you're having can continue to have a positive impact so something like improved communication can really go along way so thanks so much for watching I hope there was a good takeaway from this and I'll see you next time

Frequently Asked Questions

What is the main focus of the video regarding communication for senior software engineers?

In this video, I focus on the importance of how senior software engineers communicate, especially with junior developers. I emphasize the need for clarity, context, and positivity in our feedback to ensure that junior engineers understand our intentions and feel supported.

What does 'radical candor' mean in the context of giving feedback?

Radical candor refers to the ability to provide blunt feedback to someone when there is a high level of trust and respect between both parties. It allows for honest communication that can help someone improve, as long as they know that the feedback comes from a place of wanting them to succeed.

How can senior engineers improve their communication with junior engineers?

Senior engineers can improve communication by providing context and clarity in their feedback, explaining the 'why' and 'how' behind their comments. Additionally, incorporating positive reinforcement can help junior engineers feel more confident and less defensive when receiving feedback.

These FAQs were generated by AI from the video transcript.
An error has occurred. This application may no longer respond until reloaded. Reload