Dealing with Conflict: Audience Discussion

[00:00:00]
>> All right, so audience, Scenario 1, you're dealing with some interpersonal conflict within your team. Engineer 1 and Engineer 2 are having some aggressive behavior in code reviews. How would you have approached this? You heard what Jem and I both said. What are some suggestions you have? Yes?

[00:00:19]
>> Well, I think it's kinda been a theme over this last two days anyway, is the approaching things with curiosity and good intent.
>> Yep.
>> And maybe giving that feedback to Engineer2 when they're doing code reviews. I know me, personally, when I'm doing code reviews, I look at it initially and go, I wouldn't do it that way.

[00:00:40]
And I'm like, wait, but there's a bunch of different ways to do it. Might be in a different way, maybe it's not adhering to the coding standards or whatever, but just kind of having that engineer kinda have that mindset might help for better, less combative code reviews.
>> Absolutely, yeah, cuz positive intent going both ways is so good.

[00:01:05]
Yes, go ahead.
>> I think one thing jumps out is, well, in this scenario, you could go look at the code reviews and see the actual comments. I think the other thing I would be curious about, too, is this just a problem with Engineer 1 or the entire team?

[00:01:20]
To understand if the entire team is kind of feeling this way or these comments do appear somewhat aggressive on other code reviews as well. But then also, too, if it's something I need to work with Engineer 2 on, kind of going through and coaching that, maybe they don't have ill intent.

[00:01:37]
Maybe it is a cultural way in which they are speaking, different things like that. Everyone comes from different backgrounds, so maybe it's just the way that their messages come off in a digital world that's misconstrued all the time. So kind of coaching them how to maybe add a little bit of fluff in there when you wanna give feedback.

[00:01:56]
Or use ChatGPT to kind of learn some better ways to soften some ways to give constructive feedback. And kind of giving them those tools, so that they can be successful within the team as well.
>> I love that too. And I think just touching on that too is in a remote world, we're relying a lot more on Slack, and text-based, and it's really hard to know the tone, right?

[00:02:17]
And so even just getting those two people to have a conversation outside of a chat is huge. But I love what you said there, too, is there's also tools to kind of, can you make this sound less harsh? And ChatGPT will help you there.
>> Jump off what you said about ill intent.

[00:02:34]
You don't know what's going on fully, you may, but you may not, know what's going on fully in other people's lives. And so some things could be bleeding through, maybe unintentional. And so, yeah, starting with the assumption that people aren't coming into the conversations with ill intent. Kind of that curiosity, but maybe a different coin of that, side of the coin.

[00:02:58]
>> Yeah, I mean even for, going back to the remote world, I will say that for me, if I'm bouncing between meetings, I do get Slack messages to people. And I'm quick to respond, and my tone might have been off. And that sucks if someone reads that or misinterprets that.

[00:03:13]
And so I was just quick to respond, that person might have just been quick giving feedback because they're behind on something. They still wanna give feedback on a pull request, but it wasn't their intent to necessarily come across in that tone. So I think it is really good, I guess curiosity we've called out, but understanding someone's intent can go a long way.

[00:03:34]
There's one more comment.
>> For this one specific example, I wanted to remind people that you can actually leave positive comments in code review.
>> Yes, yes.
>> [LAUGH]
>> I joined a team once and I actually had somebody give feedback, and they were like, I never even thought to give positive feedback, on something that they liked.

[00:03:55]
And I was like, yeah, that's an option.
>> Positive feedback goes a long way. Yes, it really, truly does. And it's so easy to forget. All right, we'll jump to Scenario 2, where you've had the partner disagreement. Curious of your thoughts. Or I guess it wasn't partners disagreement, but necessarily a two team, one person on your team and one on another team.

[00:04:19]
Yeah?
>> Actually literally had this happen last week. We had a contractor working on some things that didn't follow the process of having two approvals on their PR. And also added some NPM dependencies that didn't have a clear explanation for why. And it seemed hadn't addressed feedback or didn't get feedback on why that would be happening.

[00:04:49]
And so I had two separate people from two different teams come to me saying, hey, I'm concerned about this. There's some knowledge gaps in terms of how to use git. There was a lack of understanding on how reverts work and how to rework the original work into a better state.

[00:05:08]
And I got a message just today talking about how, after I let them know, here, I'll work with my partner manager, we'll bring this to his attention. I'll look through what's going on and find out, and then let's find a way to give that feedback in a constructive way to the other person.

[00:05:30]
And I had one of the two engineers who was complaining reach out to me today, say, hey, this engineer reached out to me asking for help with this. I worked with him on it, and then I found out it's more complicated than I thought it was originally. So I'll work with him on how to solve it.

[00:05:46]
>> That's awesome. Yeah, these are real world scenarios, too. And I love how you've approached that, too. And just even something like git, maybe there's just someone didn't fully understand that, and you need to up-level that knowledge on the team and just make people feel more comfortable in that space too.

[00:06:07]
Yeah?
>> I think with this one, too, it's kind of sitting with that engineer and saying, all right, let's check the facts of what everything is and then let's also check our biases. So what on the team, say you've got a front end team and a back end team.

[00:06:19]
So these engineers on the front end team, they think it should work in a certain way because they're consuming the back end in a certain way. Vice versa, the back end team might think they have to do something that way. So trying to figure out the biases between how those teams work and how maybe those things could work together and kind of coaching them through.

[00:06:38]
Being able to ask those questions and recognize, this makes your team's life easier, but it makes them ten times harder there. So having those kind of conversations with the engineer as well to really understand what this scenario is, but also then help them think about it in different ways and put themselves in their shoes.

[00:06:55]
>> I love that. And I'm smiling because I feel like I recently have dealt with this. Even just in my team, I do have front end and back end, and full-stack engineers on the product they're working on. And that has happened, where it's like, well, why can't the back end do this?

[00:07:09]
And it's kinda back and forth, and you have to try and understand, going back to some of those trade-offs of, well, yeah, you think that it should, but it's so much harder on there, and maybe it is actually better for the UI to do this. Just kind of approaching it that way too is like, what's the best for the business, and getting us there?

[00:07:25]
That's awesome. All right, what about customers? You've gotten feedback on the product that you work on. This one was really specific probably, too, an internal customer being able to bring this attention, but you have products out in the world too that, I mean, I see feedback on Twitter on what Netflix should do.

[00:07:46]
It happens, and how do you maybe address it? I think it's easier to address with internal, but I'm curious your thoughts on this one? Yeah?
>> One of the things that Jem mentioned, I recall, was just taking that perspective of having empathy for your customer. Seeing things from their perspective goes a long way to really understanding in what way the product isn't meeting their expectations or their needs or solving their use case.

[00:08:15]
One thing I'm always sure to do in those situations is thank them for providing the feedback.
>> Yes.
>> Because a lot of times, especially with internal customers. I think you had mentioned this, too, is you'll hear about it when things go wrong most of the time, but you don't always hear when you're doing things right.

[00:08:36]
So just thanking them and making sure that they know the feedback is appreciated, whether it's positive or constructive, keeps that line of communication open and bidirectional. So yeah, I think it's really important to have a shared empathy for what is it that we're trying to solve, and how are we going about solving it?

[00:09:02]
>> I love the thanknyou part. Thank you for the feedback. It's a gift. Thank you. You don't have to accept it all, and you don't have to act on it all, but you're hearing it, and you want people to bring that to your attention. If they're not giving you that feedback, you're flying blind on a lot of it.

[00:09:18]
So that is a good callout. All right, we'll jump. Sorry, I'll go back.
>> Yeah, the customers, as Jem and Evan said, it's a good part to have the conversation around it. Cuz I think a lot of in software, and I love feedback that I get from my family and stuff, cuz they know I can understand how the software is built or architected.

[00:09:41]
It's like, well, what are the steps you took to get there? Cuz I think you put analytics in software to understand how users are using it. And if you have the opportunity to talk to a customer and say, I know exactly how you're using it, is so key to then probably unlocking so many more doors.

[00:09:57]
>> Yeah, even being able to sit down with them and have them walk you through is like, I didn't intend that you do that. And it's like you can see how someone uses it, I love that. All right, last one, leadership. Someone's adding scope to your plate, coming down from higher above, how would you approach this scenario?

[00:10:26]
Yeah?
>> I think the big thing is presenting all of the information typically on your JIRA board, whatever, of hey, this is all the work we have in the pipeline, showing that, giving that visual of if we bring this in, where does it fall into? If we haven't started these three other things yet, does this get started before that?

[00:10:43]
Of yes, all three of these things say must have, but in the worst-case scenario, what slips? And if that can't slip, is the timeline negotiable? Different things like that, just trying to really understand that, and kind of having that visual too of that work, I think sometimes can help with that conversation.

[00:11:00]
It's hard to say we're already at bandwidth. So being able to have that in there. And sometimes even putting those placeholders in place for those things that are keeping the lights on. So that that's represented, because sometimes your leaders are gonna be much higher up, and they're very far from the code.

[00:11:17]
And so being able to have that as, this is a big chunk of our time of having to fulfill these different requests for things and stuff, this is tangible work the engineering is doing, that we can't stop doing that. So I think that's kind of how you approach it.

[00:11:30]
>> Yeah, you wanna kinda help me educate upward, too. As much as you as a manager might be that much closer to your team's work, I still rely on my team to educate me in the depth of where they're at. So it's kind of like you're pushing that information up.

[00:11:43]
I love that call out. Something I didn't touch on, too, that is really helpful, is maybe that your team is right now, this quarter, has all the D priorities, the top one priorities. And so maybe you have to do it, everything's the P0. You should never have all P0s, but, hey, maybe that's the case, and this one thing is so truly, nothing else can slip, this has to come in.

[00:12:08]
I look to my leader to go, well, they have vantage points into other areas that I'm not the only team that they're seen over. Can we build a virtual team? Can we pull in some other engineers? Could another priority in our org get dropped so that we can do this?

[00:12:23]
And I think that kind of dovetailed off what you were saying, is it's educating them a bit and having those conversations
>> This was asked a little bit earlier related to metrics, but kinda fitting for this scenario. What happens when the decisions about metrics, or tracking, are made at the senior leadership level?

[00:12:45]
At that kind of level where even your manager isn't helpful at changing the situation?
>> Yeah, that happens. I mean,, there again, I would probably take Emily's approach there too, is educating as much as possible. Make sure that you're giving as much information as possible. But also curiosity, what information are you possibly missing for your team?

[00:13:11]
As a manager, I wanna make sure that my team has the full picture, but there's often gaps too. So I wanna understand, what am I missing, right? You're pushing this metric down. What am I missing? Why is this so important? How's that gonna work? And it takes a lot of back and forth.

[00:13:27]
I think the wrong thing to do in that scenario is just, well, my manager told me to do it, right? I don't want engineers on my team saying that. I don't wanna take orders like that, either. And I don't think my manager above me or above them wants that to happen either.

[00:13:43]
We're all in this together, and we see it from different vantage points. And so I think there's no simple answer to that, but I think it's really understanding both sides and trying to come to a common ground and sharing all the trade-offs that may possibly happen. And then you kind of get a little bit closer to a picture of what should go forward.

[00:14:05]
All right, now, we've talked a lot about giving and receiving feedback throughout this whole session. I think it is so critical as a manager to be able to give feedback, but also to receive feedback. So we've also talked about creating psychological safety. I think this is absolutely an area where, as a manager, I'm thinking about how do I foster psychological safety for my team?

[00:14:35]
How do I make sure that there's trust and that we're able and comfortable enough to make mistakes, to give each other feedback? Feel that we're having the best intent. And there are ways that you can try and help build this overtime. You can't force it. You can't say, hey, we all just gonna give each other feedback, it's gonna be all easy and everything.

[00:14:56]
You have to kinda set the example. Maybe it's being vulnerable about, you know what, I got feedback from my manager the other day that I'm not communicating enough about what my team's doing. And so that's feedback I got. I'm gonna share that with all of you. And maybe you can help me make sure that I'm highlighting the things that my leaders should know about.

[00:15:14]
And so we can work on that together, but it also was vulnerable that I shared something that I'm getting feedback on. So you wanna help create that environment of trust, share mistakes, and build trust with your direct reports. And that's really for the receiving feedback. And something that was called out earlier is, even just saying thanks for feedback.

[00:15:32]
I celebrate when people give me feedback. And sometimes it might even be in Slack, David on my team shared that I should do better at this. And he's not wrong, and just celebrating and kind of calling attention to that and encouraging others to do the same.