Dealing with Conflict

[00:00:00]
>> Ryan Burgess: All right, another thing that I don't think always happens, or hopefully doesn't happen a lot, but it does. As a manager, you have to deal with conflict. I talked about interpersonal, dealing with people, it's hard. That is definitely a challenge, everyone deals with problems differently, and sometimes there's friction.

[00:00:21]
And guess what? You as a manager get to deal with that. So how do managers deal with conflict? This is a tough one to teach or just kinda speak to. So this is where I'm going to be leaning on a bit of a scenario, where I'm gonna lean on Jem Young again.

[00:00:38]
And he and I are gonna go through a couple scenarios and talk through how we might approach it. And definitely, audience, chime in if you have approaches that you would take. I think this is a really helpful way to do, is cuz dealing with scenarios, getting advice from other managers on how they might do it is very, very helpful.

[00:00:57]
So Jem, let's dive into some scenarios here. There's an interpersonal conflict in the team. The engineer one brings up an issue in a one-on-one with you as a manager and says, engineer two on your team, they're being really aggressive in code reviews. How do you approach that?
>> Jem Young: This one's easy.

[00:01:20]
You fire them, and-
>> Ryan Burgess: [LAUGH] Well, that's easy, right? That's all we do as managers. Okay, yeah.
>> Jem Young: This one is a little bit easier because that's something I can actually look at myself. What are some examples of being aggressive, cuz that's a little ambiguous? So I had to go look at what they're actually being aggressive about.

[00:01:42]
In this case, aggressive, pedantic, you can say they're the same thing. So I dive in and see, yeah, maybe this is right, or maybe, hmm, why do you feel this way? So always be curious. Never take any person's side immediately, because the other person probably has a valid opinion too.

[00:02:01]
If I feel maybe it's a little aggressive, then I'll have a talk with engineer number two and say, hey, what's your philosophy on code reviews? What's your stance? What's your policies? Do you think the team agrees with you on that, yes or no? And then depending on how that conversation goes, we can say, hey, why don't we implement team-wide policies on disagreement across everybody on how we do code reviews, what the language we should use are?

[00:02:30]
Let's implement tooling so we don't actually have to address, I don't know, you're missing semicolons or something like that. Let's automate this to a tool that we all agree to use, and we'll see how it goes from there. I'm not saying that that will solve the problem immediately, but it's a good place.

[00:02:47]
And usually, with something like this, it's a sign there's a process that's not working. And a process, immediately is, that's my job, is to figure these things out.
>> Ryan Burgess: Yeah, I like that too. I love even just, if it's something on a code review, it could just be linting rules that you're like, yeah, let's just not have a person have to harp on something like that.

[00:03:07]
I think in this scenario, too, I might even before going to some of that, I mean, reading it is awesome, but I think understanding. Absolutely agree with you, I would take that curiosity approach, understand, and maybe try and see, what do you feel? What's aggressive about it? Well, how does that make you feel?

[00:03:24]
And kinda understand that. But then my first inkling is, have you given that person the feedback on that? Because I think oftentimes it can feel escalated, and you don't want it to feel escalated where a manager's like, all right, I gotta go talk to engineer number two. It might get to that point if there is still a lot of conflict.

[00:03:45]
But oftentimes I wanna try and help encourage the engineer number one to have that conversation with the other person. Especially in something like a code review, or Slack threads, messages, tone is really hard to read, like my goodness, that is a tough one. Something even Jem said in Engineering Management 101 Is that reactions in Slack, you might give the wrong reaction and not have that intent.

[00:04:13]
And so this other person might have had positive intent and had no idea that this other person was interpreting that that way. So I think to me, it's like, all right, go have that conversation with them. And then if that doesn't work, maybe it is more of like, okay, I probably need to approach this engineer.

[00:04:28]
And I think the processes one, absolutely, being able to implement some of those things. Like, let's just agree on some standards as a team and let a computer decide that. That really helps, too.
>> Jem Young: Yeah, it's pretty good, Ryan. And I think this is a good scenario that shows the difference in experience between you and I.

[00:04:44]
My bias is always towards I need to do something, let me step in, where yours is, no, the better, maybe more efficient solution is to have people solve it themselves and you just stay out of it.
>> Ryan Burgess: I don't know if it's better or worse either, it's just to me, it's hard, too.

[00:04:57]
You're like, I gotta fix the problem, right? And that might be it, it's encouraging that, or maybe you can help the person deliver that feedback, right? I've said it earlier today. I'm gonna say it again. Giving feedback is hard. And sometimes it's something that if you're not practicing it a lot, I'm nervous to go give that engineer feedback, what should I say to them?

[00:05:19]
That they're mean, or that they're aggressive? And you can kinda help coach them. Well, here's how I would approach it, does that work for you? Is that gonna help the relationship? Or maybe it's just jumping in a room to have that conversation. Well, let's jump to another scenario.

[00:05:36]
You have a partner disagreement. So an engineer on your team is having troubles working with another individual contributor on another team. So now, you have someone who reports to you directly, but someone who also reports to another manager. Maybe it's just a conflict that they're disagreeing on an approach.

[00:05:56]
Let's say it's a technical approach and they're just not getting alignment and they're butting heads on that. How do you approach that?
>> Jem Young: Another easy one. You go to the manager of the partner team, you take them out to a nice dinner, you sit them down and you be like, hey, I think you should fire this other person cuz they're causing me a lot of trouble.

[00:06:14]
No, you definitely don't.
>> Ryan Burgess: [LAUGH]
>> Jem Young: Again, you start with curiosity and say, what is the the problem here? And hopefully, by now, you're aware of all the interpersonal relationships between a lot of the people. And say, is this a broader problem? Let me better understand what exactly you're talking about.

[00:06:31]
And then, following on what you said in the last scenario, ask the engineer on your team to give feedback to the other person and say, hey, here's how I'm feeling. And depending on how that went, then sometimes you do have to escalate and you have to mention it to the other manager, and say, hey, so and so is having problems, they gave this feedback.

[00:06:52]
Maybe you can help me resolve this, what's going on with this person on your team? Because this is just what I've observed or we're hearing. One thing I don't do is I don't go directly to the person on the other team, because from a parent metaphor, that's kinda your kid misbehaving and someone else at the park going up to your kid and being like, blah, blah, blah, blah, blah, blah, blah.

[00:07:11]
And as a manager, if someone did that to me, I'm gonna be like, what are you doing? That's my job. I don't have to that trust and relationship built up, so it just comes across poorly. You let the other manager kind of handle it. But again, you have to be really delicate with you handle that situation, cuz you don't wanna come in finger pointing, cuz that manager is gonna get defensive for their team, as they should.

[00:07:31]
>> Ryan Burgess: Yeah, they wanna protect their people, and that's a good quality to have, too. It's like, you don't wanna be defensive, but you also wanna be like, well, I wanna hear both sides of it, too.
>> Jem Young: Yeah, that's why I always like phrases like, I've observed this, or someone from my team observed this.

[00:07:48]
And really it's a neutral stance on, hey, I'm not saying this is how I felt or this is what I see. It's just, this is kind of what I've observed. What do you think about? Have you noticed that as well? And then being curious and showing you are being curious about, I'm concerned about this other person too.

[00:08:05]
It's not just like I want you to do something about it, it's like, we're all together.
>> Ryan Burgess: Yeah.
>> Jem Young: Let's fix something if it's not working.
>> Ryan Burgess: No, I love that. I think that's very similar to how I'd approach it. Maybe one other thing that I would, depending on the situation, I might even encourage the engineer on my team, if they feel comfortable, gave that feedback, it's not working.

[00:08:24]
Sometimes they feel comfortable enough to go to the person's manager and going, hey, I gave this person the feedback, I'm not sure it's fully resonating with them. I'm still concerned that this behavior is still showing up. And so maybe it's okay and not, but it just really depends on situation.

[00:08:40]
But absolutely, I would have approached it in the sense that I'll talk to the other manager. I might still do that as, hey, I know there's been a bit of a rift or conflict happening with our team, how are you feeling about it? I might even just do that behind the scenes a bit, and have that conversation so that we're both on the same page of it.

[00:08:57]
But yeah, I'm very aligned with your approach, too.
>> Jem Young: Hopefully, it's been resolved. But even after that, I still talk to the other manager and say, hey, so and so having this, they had a conversation that solved. But it's important for you to know about it, just in case there's actually a theme going on that you're not aware of.

[00:09:17]
And it's just a courtesy, I would wanna know that. I wouldn't want it to happen four or five times and then suddenly, yeah, this has been happening for months and I'm like, no one's told me. So it's a courtesy after it's all been resolved.
>> Ryan Burgess: Yeah, you're like, I'm not asking you to do anything, just more awareness and you're like, wow, that's actually been the fifth time this has happened.

[00:09:35]
And you're like, this is a broad theme that I may need to fix or address, and so it is really helpful to know that.
>> Mark: I think running this company for over a decade, what's helped me is kinda similar to the team alignment. You talked about having a team, I forget what the term you guys use, team charter.

[00:09:57]
>> Ryan Burgess: Yeah.
>> Mark: I think having that team charter somehow reminding them of that seems to resolve a lot of conflict, cuz you're shifting it from he said this, she said that, whatever, to how do we align on our goal as a team?
>> Ryan Burgess: Yes.
>> Mark: And whenever you shift the conversation from the individual to the team, it seems like a lot of problems go away.

[00:10:27]
Just in my life, my family life, everything, it's like if you can find the common denominator. If two parties want the same thing, there's nothing that they can't get over. And that's my guiding philosophy, running this company, dealing with my family. It's like, what do we all want here?

[00:10:52]
And how do I remind everyone first? This is what we're all after first, and just keep bringing the intention back to or shared, I think you used the term shared goals.
>> Ryan Burgess: Shared goals, common goals, Mark, I love that. Because, I mean, maybe you disagree on the goal, so you have to kinda start there.

[00:11:09]
But once you have the alignment on the goal, the other problems kinda start to work themselves out. Maybe not, you kinda keep tying it back to the goal and the trade-offs to get there.
>> Mark: Well, and like you said, if the goals are different, that's when maybe this person isn't the right fit for the team.

[00:11:29]
>> Ryan Burgess: Right.
>> Mark: Or whatever, but that ultimately, if two people want the same thing, they'll get over anything, because they both want the same goal. And yeah, dealing with now 70 people, [LAUGH] we all want the same thing, which is educate more people more deeply and just bringing people back to that focus first and then, okay, what's going on?

[00:11:53]
>> Ryan Burgess: Yeah.
>> Mark: And it's just like it level sets everything.
>> Ryan Burgess: Yeah, and so that sounds more like your individual team, but even when you have a partner team and those conflicts are happening too, it's like what's your team's goal, what's my team's goal, where's the common goals that are together?

[00:12:10]
It's like it is baseline just getting alignment on that absolutely can help some of those things. Depends on the problem of nature, it could just be literally, I don't like that person. And the goal may not change that, but I think that is a great approach.
>> Mark: But you could hate, I should say, not hate, but have a completely different style, working style.

[00:12:31]
>> Ryan Burgess: Yep.
>> Mark: Communication style, your styles should be polar opposites. But if you want the same thing, it seems like you always can figure out how to work with that person.
>> Ryan Burgess: Yeah, and then even just kinda understand where the person is coming from or how they approach it can, yeah, help.

[00:12:45]
>> Mark: That they sharpen you and you always get better as a result, so act.
>> Ryan Burgess: Great points, no, thank you. That was great call out, and ties it back to that team charter, I love that.
>> Ryan Burgess: All right, scenario three, customers. So your team has internal customers that use the product that your team works on.

[00:13:08]
Maybe you build a platform that people are building on top of. A customer comes to you and shares how unhappy they are with the product. Not the people in your team, but the product. And they have a lot of feedback that it's not working for them, how do you approach that?

[00:13:24]
>> Jem Young: Again, one of my favorite values is curiosity. So okay, tell me about that, and empathy. Recognize that they're trying to solve some problem. So it's good to uncover, what exactly are they trying to solve? And then I definitely wanna start with visibly documenting what they're saying, just to show I'm taking action on this.

[00:13:43]
So like, hey, tell me about that, tell me specifics so we can address them, and then kind of walk through that and then reiterate or repeat. Kind of like, so here's what I'm saying, here's what I heard. Is that accurate? And they say, yeah, or no, something like that.

[00:13:58]
They you say, okay, let me come back to you on this. I don't promise anything, I won't say we're gonna fix it. I think the mistake I've made it before is, my team's so busy and I hear you, we got all these bugs, and trying to play for pity, I guess, when I think about it.

[00:14:14]
But the truth is people don't care how busy you are, everybody's busy. Sympathy does not work well, and you learn that really early as a manager, people don't care. So it's like, okay, what's going on? And then maybe, depending on the level of feedback, maybe I'll take it to some people on my team and I'm like, here's what I heard.

[00:14:34]
What do you all think? Are these bigger problems? Have you heard similar? And then maybe we work out a plan to address, maybe we don't. But whatever happens in between, I definitely follow up with that person who brought it to me and say, hey, I took the so and so, or I've looked at this, some of this we've got in the roadmap, some of this is not a high priority right now.

[00:14:52]
But just to show you are taking them seriously and you value that feedback, regardless of whether you do anything about it. You definitely wanna close the loop for that person who brought you that, if they're unhappy about something.
>> Ryan Burgess: Yeah, all the things I love about. I love the reframing too to make sure that you're understanding the problem too and just making sure that you are both aligned on what the problem is, bringing it back to your team.

[00:15:16]
Maybe it's like, actually that's a really quick fix, let's just do that and you're like great, but not promising something either. I've seen the mistakes made too, and actually, it causes even probably more problems and erodes trust with partners. Is where you're like, yeah, we'll put that on our backlog.

[00:15:34]
Okay, I mean, that's one approach. But I've also picked up a backlog that's two years old and I'm like, have we told customers, our partners that we're doing this? And they're like, well, yeah, but we just put in our backlog. I'm like this is two years old, no would have been a better answer, we're not doing it.

[00:15:54]
Because then it could also spark a conversation where you're like, but my team is dependent on this, and it's like, okay. Is it higher priority than these ten other things that my team's doing? I don't think we can do that. Maybe another team can do it, but it starts to have those conversations, or maybe we need to go hire someone, or it just starts those conversations.

[00:16:16]
No is a strong answer, and it's a good answer, versus, yeah, we'll just put on the backlog. So I echo all the things you said, Jem, I think are really great ones. All right, well, thank you, Jem, for your insights. I'll bring it back, we'll go through the scenarios just briefly.

[00:16:31]
For the audience, I would love to hear some insights or thoughts that you may have.
>> Speaker 4: The fourth one.
>> Ryan Burgess: Crap, there is, there's four, thanks, Jem. All right, fourth scenario, Jem, leadership. You have a manager, your direct manager is asking your team to add additional scope that your team doesn't have bandwidth to successfully deliver without impacting the current work on their plates.

[00:16:59]
How do you approach that?
>> Jem Young: This has happened to me many times.
>> Ryan Burgess: Yeah, I'm sure it has [LAUGH].
>> Jem Young: Something I talked about yesterday in terms of, or we talked about today in terms of charter and the things we don't do, and why it's really important to have that, and that applies to everybody.

[00:17:15]
It applies to your manager as well. So I say, interesting, okay, so my understanding was the scope of the team was this. Where does this fall in terms of prioritization? Who's asking for it? If we don't do it, what happens? Are we the best team successfully equipped for that?

[00:17:31]
Having a really strong charter helps these conversations, because it gives your manager a baseline on what you're supposed to be doing. If they're like, you need to add more scope, you say, okay, so here's our current priorities, again, so this is where you have a roadmap that you've already shared out, too, which is, again, it's agreed upon contract of what your team is gonna do.

[00:17:52]
And you say, hey, here's our current roadmap, here's the prioritization based on the business needs and things like that. We're gonna have to drop this, or what should we drop here, because we just can't do more. And then you force your manager, in this case, to say, you drop this, and you say, okay, well, I'll send out some communication to our partners and whoever's depending on it, and both our names are gonna be on this.

[00:18:14]
Because if it's coming from above, it's not my choice, then you have to own part of that decision, too. That's just part of leadership, if you ask people to do things like that.
>> Ryan Burgess: Yeah.
>> Jem Young: This one's tricky, what about you, Ryan?
>> Ryan Burgess: I mean, I liked all the things you had said, but one thing in particular I really liked, and I think it's a question that I often use, not even just leaders, but just in general, is what happens if we don't do it, right?

[00:18:39]
So sometimes something comes up and maybe that team in that other scenario where they're asking for something or saying something's not working in the product, I might ask, what if we don't do that? What does that mean for you? Well, just I wish it was done. Okay, well, that tells you a lot there.

[00:18:56]
Or it's like, I can't deliver on one of the most important business priorities and this is why. And so it really kind of starts that conversation with curiosity as well. But that you did, too, of circling back on here's the priority list, here's where my thinking is on priorities, could we drop this one, is that okay?

[00:19:17]
I think is really powerful and it starts that conversation. Maybe it's like, well, Jem, we need more resources on your team so that we can pick that up, but you have to force those conversations. Not, all right, yeah, my team will do it, which means you might not deliver on anything cuz you're trying to do too many things, or you're overworking your team, burning them out.

[00:19:38]
They're trying to stay up on evenings and weekends to pick up work that you've now agreed upon. And so I really liked your tactics of going back and forth. And approaching with curiosity, I think, is a really good suggestion.
>> Jem Young: You can definitely document any changes to your roadmap, any incoming requests.

[00:19:54]
I've been burned by that before, taking on more and more and more, but I didn't reflect it in the roadmap or things we were supposed to be doing. So at the end of the quarter, it just looked like we hadn't done anything that we said we were gonna do.

[00:20:04]
But it turns out we did, we just had a lot of other higher priority requests. So I found documenting any sort of changes, any sort of income request, changes priority, and then communicating that out is a safe way of covering yourself as a manager to be like, they are delivering, they just start shifting because they're in a position that the priorities change.

[00:20:24]
And that happens for a lot of teams, depending on your role of the business.
>> Ryan Burgess: Yeah, communication, too, is always a good one. And maybe the team catches that and goes whoa, whoa, whoa, now that's screwing me over, and so you have a bigger conversation too. I think that's why it's important to communicate.

[00:20:41]
Another aspect, too, that I was thinking about when you're saying that, too, is, yes, the communication, but also on roadmaps, they should be flexible, right? Priorities change, and that's okay, and so that's why even having that stack ranking or priority list is that you at least can maybe drop something fairly quickly.

[00:20:59]
Or you have to go back to the drawing board and re-evaluate, and you and your team should be okay with that. It's gonna to slow something down for a bit, and that's okay.
>> Jem Young: Yeah, the P0, P1, P2, P3, super helpful when stuff like this happens, which it does all the time.

[00:21:15]
And P0s are the, we absolutely have to get this done. P1s are, yeah, we should get this done. P2, P3 is like-
>> Ryan Burgess: Probably not even getting into those.
>> Jem Young: We're probably not getting to it, but if we have extra capacity, yeah. And then I really love your point on, don't oversubscribe your team, don't put 100% capacity.

[00:21:32]
People get sick, people go on vacation, stuff happens, we have fly-ins, and if you're just overdoing your team, you can't account for that.
>> Ryan Burgess: Yeah, and there should also be time for keeping the lights on, whether it be paying down tech debt or just investing in certain things.

[00:21:48]
You wanna afford your team that, or your team's a platform team, so there are things that might happen or change that it's like, you have to fix or address cuz it affects another team. And so, yeah, you wanna make sure that you're setting aside that time and not oversubscribing.

[00:22:05]
Right, well, thank you, Jem. Those are good insights, thank you. So now, what we'll do, too, is I'd love to hear some quick suggestions from the audience, to just hear your perspectives on how maybe you would approach scenario one, two, three, and four.