Anytime we’re at work, we’re with other people. That automatically creates opportunities for conflict: we all have different opinions, different priorities, and different perspectives, and when those don’t mesh, conflict can arise. Conflict can actually be healthy at times, provided you know how to work your way through it with grace and professionalism.
Before we dive in, let’s acknowledge some of the different types of conflict that can arise, since we’ll need to take slightly different approaches to each:
Businesses often create deliberate, intentional tension that’s designed to help weigh competing interests and priorities within the business. When used properly, these create “healthy conflict” that helps businesses navigate tradeoffs and compromises.
Businesses can also have unintentional conflicts around business decisions, which are often the result of unforeseen circumstances.
As humans, we can create or be subject to personal conflicts. These may arise from business situations, such as two people disagreeing on a particular decision, but they’re almost always unhealthy and almost always need to be resolved.
Finally, we humans can also have interpersonal conflicts. These can happen for all kinds of reasons, which we’ll explore in this chapter. Interpersonal conflicts are the ones that tend to affect us most personally, and we may not even want to raise them at work, but they’re the conflicts that can create the most damage to a team, and to our professional brands.
We often think of conflict as a bad thing that has to be dealt with, but sometimes leaders encourage very deliberate, intentional conflict that can be healthy for the business.
For example, I once wanted to open a new position on my team for an experienced technologist. We’d been relying on contractors for months, and I could see that the contractor was costing us more than even a fully loaded salary would cost us. Having a permanent employee would save us money, bring more stability to the team, and—with the right hire—bring more passion and perspective than a contractor might. Our Finance team, on the other hand, flat-out refused to approve the new hire. Boom! Conflict!
Many businesses refer to that kind of situation as deliberate tension. Businesses have a lot of factors they have to consider in making decisions, and they often choose different departments, teams, or people to represent those sometimes-conflicting factors. Finance’s job was to protect the company’s purse, ensure the company maintained an appropriate profit margin—a key metric that the market used to determine the company’s health—and monitor the company’s cash flow. My team was responsible for creating customer-facing outcomes, such as products and services, in an efficient and effective way. In the instance I’m describing, those two perspectives were in conflict, and that was very much on purpose. The company’s executives trusted that, between us, Finance and I would sort through the appropriate motivations, drivers, concerns, and outcomes to find the most well-balanced answer possible. There was no objectively correct answer in this situation, which meant Finance and I would need to work together to find the best balance we could, making the best set of tradeoffs we could agree to. We’ll come back to this story throughout this chapter, to illustrate several key points about conflict, and how to handle it.
Conflicts can also be unintentional, such as when two co-workers disagree over a decision that needs to be made. The disagreement might be over something as seemingly simple as how close everyone’s desks should be, or something serious, like choosing a programming language for an upcoming project.
Whatever the situation, the conflict resolution process actually works out to be really similar. In fact, when you find yourself in a personal conflict with a co-worker, one way to take the stress out of the situation is to treat it like one of those deliberate “business tension” conflicts like the one I was having with Finance.
I touched on this exercise in chapter 10, but I want to revisit it here with a different intent and outcome in mind. So after reading this paragraph, I’d like you to close your eyes. Sit back, relax, and for 5 minutes or so, just think. Don’t even try to think about anything in particular; just see what floats through your mind. Go.
What came into your mind? Probably some work-related stuff, maybe around a project you’re working on. Maybe something inspired by this book. Likely something to do with your personal life. Perhaps a snippet of song lyrics you heard earlier.
All of those things are your context. They’re the things going on in your life right now, the concerns in the forefront of your mind. Your context also includes longer-term concerns: you might be worried about paying your bills this month, or thinking about the doctor’s appointment you have coming up. Everything going on in your head, right now, is your context. Our context can play an enormous role in creating conflict, and in how we deal with that conflict.
Imagine for a moment that you walk into work one morning. You’re in a decent mood: the commute went reasonably well, the podcast you were listening to was interesting, and you’re looking forward to the project you’re working on. Things are going well at home, too: there are no major financial or life problems facing you, the kids seem to be doing well in school, and your spouse is happy at work. You’re especially looking forward to talking to Lisa, one of your co-workers. You and she have been working through a functional specification for a technology pilot, and today you were both planning on nailing down some of the final success criteria for the pilot.
As you walk into the office, you stop in the break room to grab a cup of water. Lisa’s already there, waiting for the Keurig machine to pour out a cup of coffee.
“Hey, Lisa!” you say in a friendly voice. “I was thinking about the success criteria all night, and I think the user satisfaction score is really going to be the ultimate measure of success on this one. What do you—”
“That’s stupid,” Lisa snaps, turning around to glare at you. “Users have no idea if they’re happy or not. We can discuss it later.”
You realize that Lisa’s jeans are torn, and she’s covered in mud. Her glasses look like they might be broken, as they’re hanging askew on her face.
In this instance, it’s pretty easy to understand why Lisa might be in a bad mood: her commute obviously didn’t go as well as yours. In other words, some of her context is publicly visible. You immediately mumble an apology and back off, wisely realizing that Lisa’s not snapping at you, she’s snapping at life. Today might not be the day to nail down the pilot’s success criteria.
The problem is that ordinarily our contexts aren’t on public display like that. What’s going on in our world is all in our head, and to everybody else we look like we always do.
I once got into a fairly explosive argument with a co-worker about the programming language we were going to use for a new project. We didn’t have a lot of internal software development going on, and most of what we did have was on a midrange computer; the project in front of us was a PC-based application, meaning we could go in whatever direction we wanted. He and I were both arguing for different languages, and it started getting pretty ugly. The language I wanted was stupid and for babies, he told me. Your language is hard to maintain and takes longer to code in, I argued.
Finally, exhausted by it all, he asked, “Look, what’s your problem here? What’s actually driving you to push for this language? Just tell me. If you can help me understand it, I’ll back you up.”
That made me pause. It took the wind completely out of my sails. I thought about it. “OK,” I told him, “I’ve never actually done software development at this level before. I know scripting language, and the language I’m pushing for resembles the scripting I’ve done. What you’re suggesting looks like C++ to me. I just don’t understand it, and if we go with it, I’m afraid I won’t have a place on the team.”
I want to pause the story for a moment and point out that I worked on a team that had made it safe to be vulnerable. It was okay to admit weakness. And this co-worker in particular had always made it safe to “look weaker,” by never taking the opportunity to poke fun, make jokes, or otherwise create a less-safe environment. Safer environments always make it easier to resolve conflicts, which is why it’s so important to invest in creating and maintaining a safe environment. But if you work in a company or on a team that does not make it safe to share your vulnerabilities, you need to be be cautious about revealing what may be perceived as your weaknesses.
Okay, back to the story: I’d just shared part of my context. My co-worker now had more of an idea why I was pushing the way I was. “My concern,” he said in a much calmer voice than we’d both been using, “is that there are way more professional programmers out there who use the language I’m pushing for. If we need to grow the team, it’s going to be a lot harder if we go your direction. And frankly, I don’t want to learn your language. It’s not going to do anything to further my career. But you’d be doing your career a favor by going my way, and I’m completely willing to help you through it.”
Now he shared some of his context, and also offered the beginning of a solution. We just needed to get inside each others’ head for a minute.
Let’s take this lesson about using context to help resolve conflict and go back to the story about my problem with the Finance department. “Okay,” I asked my colleague in Finance. “Help me understand the parameters you guys have put up around adding new headcount.” In other words, I asked for context.
“It’s a lot of things,” she said. “We’re running really close to our target gross margin right now, and adding new people might put us below that target, since headcount is considered a cost. In this case, your hire might actually reduce expenses, which is good, but we’re also looking at long-term cash flow. Frankly, we can let your contractor go with a month’s notice. If we hire someone though, we morally can’t just fire them if cash flow goes down. We’re stuck with them, and the investors are really pushing us to maintain our margin and cash flow numbers. If we don’t, it’s going to hurt the next round of investment, and that could sink us.”
“We’re really that close to the edge?” I asked.
“We are,” she said. “And we’ll be fine, but we have to look really hard at adding to payroll. Why is this coming up? Is the contractor not working out?” Now she was asking for context.
“They mostly are,” I said. “But they’re several time zones off, and it’s making collaboration harder than we anticipated. They’re not able to be on all of our stand-ups, and they’re working on projects for a couple of other customers at the same time. They’re getting the work done, but it’s just very mechanical. They’re not invested in the project, and so we’re not getting the benefit of someone’s mind being all-in on it. I just worry that we’re not creating an outcome that’s going to serve the customer like we want, which means we’re going to spend more cycles going back and fixing, rather than moving forward.”
She nodded. “I get it. And how long do you anticipate this project to take?”
“At least two years,” I said. “We’ve already got ten releases mapped out, and we’re working in eight-week sprints.”
“Okay,” she said. “It feels like we’re balanced on the fence between the competing priorities. Let me take it to my boss. I feel like the hire is the right thing to do, if we can make sure it’ll fit the financial model. Let’s go talk to HR and confirm what the fully-loaded salary would be.”
By seeking context from each other, we learned more about the situation, priorities, and pressures that each was dealing with. It was easier in that case than my more personal-conflict story, because we didn’t especially need a “safe space” to share our context. But the process and intention was the same.
I find that one of the best ways to start resolving a personal conflict is to try and take the personal out of it. Start the process by going back to first principles, meaning: Why are we doing this thing in the first place? Whatever we’re arguing about, whatever we both believe should be done or not done, we need to go back to this: What’s the point of it all?
I helped found a nonprofit called The DevOps Collective, and one of its activities was to put on the PowerShell + DevOps Global Summit conference. Several years in, I and my co-founders were in the process of stepping away from the organization, handing it over to a new generation of volunteers. It was important to us that the organization be able to outlive our involvement, and so we felt it was time to start bringing in new people.
We—the founders—almost immediately got into a conflict with the new folks over the topic of exhibitors at the conference. We old-timers had always shunned a formal expo hall like those at so many conferences; we felt that our event was about community, about learning, and about networking—we didn’t want it to turn into a commercial event like the giant vendor conferences.
The argument went on for quite a while, with both sides tossing “facts” back and forth. “Vendors are every bit as part of the community as individuals,” one person argued. “As soon as we accept vendors, we’re beholden to them, and we’ll start changing the schedule to force people to wander through the expo hall,” someone else argued.
“Stop,” someone finally said. “Why are we hosting this conference?”
We all thought about it for a minute, and came up with several reasons. “So we can educate. So we can all have a place to come together in person. Because it strengthens our community.”
The person who’d asked us to stop nodded and said, “Those are good things, but they’re not why we started this in the first place. Don,” they said, turning to me, “why did we start this conference?”
“To make money,” I said, after a bit of thinking. “The goal of the nonprofit is to help make tech skills accessible to young people living in situations where they can’t access tech skills. We need money to do that. We need money to pay for the PowerShell.org website. We want money to help bootstrap regional one-day events, for the people who can’t make it to the annual conference. The conference is valuable, and it needs to be valuable for people to pay for it, but the reason we did it is because it’s about the only kind of activity we could think of that we could make a profit on. We use the profit to pay for the other things. The education and networking are why people pay to come, but registration is touch and go every year. Sponsorship funds would help give us a bit of padding.”
“I get it,” I continued. “I don’t want the expo hall either. But the new people are right: it’s a way to help secure the financial future of the organization, and that was the point. Maybe we should accept that and start thinking of ways to include vendors in a healthy way.”
And we did. Well, not at first—to be clear, we made several missteps along the way. But we learned each time, and got better each time. Going back to first principles—why we started doing the thing in the first place—let us all align our contexts to that, let us move past the conflict, and helped us move forward in a healthy way.
Another way to remove the personal from personal conflicts is to step away from subjective opinions and instead rely on objective data. When I was working as an independent contractor, I had an opportunity to work with a company that was developing a mobile point-of-sale system. I showed up at a design meeting one day to find a knock-down, drag-out argument already in progress, over the design of one of the system’s main screens. “Whoa,” I said when there was a break in the yelling. “Can someone fill me in?”
“David,” Erin said (these are not their real names), “seems to believe that this is the best layout for the item selection screen.” Erin threw a mocked-up screen design on the room’s big screen. “I keep telling him that this clustered layout will not work. This,” she continued, switching to another mockup, “makes far more sense.”
“Okay,” I said, settling into a chair. “David, tell me why yours works better.”
“It’s more elegant,” he said simply. “We’ve already been told that each category has a different color button, and this clusters everything by color. It’s easier for your eye to go to whichever color you need.”
“If you memorize which color means what,” Erin snorted. “My layout uses a grid. Each column is a color, so your eye can still be drawn. But it moves the most common items to the middle, which is where your finger already is when you’re coming from the previous screen. So it’s more efficient in terms of movement. Daniel’s would have you—”
“Hang on,” I said. “What is it you’re both stating, here? Belief, opinion, theory?”
“Fact,” Erin said confidently.
“Awesome,” I said. “Show me the data.” She blinked. “If you don’t have data as proof, then it’s not a fact,” I reminded her. “You’re stating a theory. But the good news is that we can prove this out.”
Both of them had stopped breathing so heavily and were looking at me.
“Let’s spend a day on a functional mockup. You can each have a software engineer, and all we need it to do is register which buttons were pressed and how long it took. The rest of the team and I will take the day to come up with several orders, based on the customer ordering patterns we already have. Whichever design lets an operator punch in those orders fastest, wins.”
Everyone was happy with that. We’d managed to do a couple of things. One, without explicitly saying so, we’d come back to first principles: our job was to make order-entry as fast as possible, not to produce something that was “elegant” or “logical.” We’d also found a way to set our opinions aside, and focus on objective data. We’d stated a couple of theories and set out to prove or disprove them, using data. Data doesn’t have opinions. In the end, we found that neither Daniel nor Erin’s screen layouts were especially efficient. Erin’s was faster, but it was still slower than the older system we were meant to be replacing. So we continued iterating, and relied more on data to move forward.
Another way to help resolve conflicts, particularly around business decisions (as opposed to personal, non-business-related conflicts), is to fall back on a decision-making framework. In chapter 15, I outline one decision-making framework called RAPID.
The goal of RAPID, and frameworks like it, is to make business decision-making faster, but it also helps mitigate conflict by clearly identifying everyone’s roles. You and I may disagree with what should be done, but if the two of us are an Input in the framework, then the ultimate decision isn’t ours anyway. As Inputs, our job is to provide information and potentially make a case for having the decision go a particular way. Ideally, we’d do so in as data-driven a way as possible, remembering the first principles of why we were all doing whatever it was in the first place. The person who owns the Decision would take that and make the ultimate call on what to do. You and I might be in conflict, but they’d resolve that with their decision.
I’ve found that using RAPID helps prevent aggressive conflict almost entirely. When I’m an Input, the other people acting as Inputs know that nothing’s personal. Nobody’s going to “win.” We’re all playing a role, in a specific situation, and the “owner of the D” tries to get as much data-based information as possible from us. We’re not arguing, we’re assisting. It’s one reason I’m such a big fan of having these decision-making frameworks, even if it’s just at the team and department levels.
In business, it’s important to remember that everyone’s there to achieve the same basic goal: serve the customer. In the details of the day-to-day activities, it can be easy to sometimes let our personal passions and perspectives carry us away. Once we get into a conflict, there’s a very natural human urge to win: losing makes us look like failures, and makes us look weak. The weak get eaten! Only the strong survive! But we have to face that tendency and set it aside. Winning isn’t as important as achieving the best outcome for the customer.
I sometimes will remind myself of that fact out loud, so that my colleagues can hear it, and remind themselves as well. “You know what, we’re on opposite sides here, but none of us really care about winning. I know we all care about the best outcome. So: back to first principles. Why are we doing this thing? What is the outcome? What data do we have to guide us? What contexts aren’t we considering?”
That, I’ve found, is the beginning of a great path toward professional conflict resolution.
For this chapter, I obviously can’t put you into a conflict. Even offering a story for you to “solve” misses the whole point of conflict resolution, because you’d have no way to get into the context of the characters. So instead, I’d like you to spend every day over the next week simply examining your own context. What’s happening in your mind? What’s influencing how you feel, and how you react to the potential conflicts that pop up at work? Are you reminding yourself to seek out first principles, and to look for objective data points—even if they don’t support the position you started with?
44.211.24.175