When I studied algorithms and data structures in school, one of the first things I learned was that different types of problems were best suited to be solved by different types of approaches. It might sound obvious, but a huge part of being an effective programmer is developing an intuition for which types of problems are solved best by which types of solutions.

Take sorting a list of numbers, for example. A “brute force” approach, like Bubble Sort, might work but is really inefficient. Instead, a ”divide and conquer” approach like Merge Sort gives way better performance.

This is actually an illustrative example. Lots of software problems are actually quite similar to sorting numbers, and the result is that programmers reach for a “divide and conquer” solution a lot. Think about how teams often take a complex task and break it into smaller pieces, so that they can be worked on efficiently; this is divide and conquer. I think that how common this approach is might say something about programmers, but that’s beside the point. We’re not here to talk about divide and conquer as a problem solving technique, we’re here to talk about communication as a problem solving technique.

Communicating as a way to solve problems is one of the most effective and rewarding techniques I’ve found so far in my career. I don’t think I would have believed this five years ago, but I was solving different problems back then. I was interested in the best way to code things. Nowadays, I’m interested in building the best team to build things.

Let’s walk through a recent example of using communication-as-problem-solving from my job, and then I’ll go into more detail about my technique.

So the example. My team is developing a new feature. We were about halfway done when the marketing team asked the Product Manager for a change, who then asked me to plan for it. I didn’t think the change was a good idea. So there’s our problem: we disagreed about the feature we should be building. My solution: communicate. I didn’t even schedule a meeting, we just jumped on a quick 5-minute call with the PM and designer (right after I took a deep breath).

First I started the discussion by restating what this feature was for: its purpose and its goals. Then I asked the PM for context until I understood both the their perspective and the marketing team’s goals. Next, I asked the designer for their thoughts. I repeated back what I had heard to make sure I really did understand the context, and then I offered my own thoughts. Finally, I recentred the discussion on the feature’s goals. What would be best for the user? I wasn’t sure what the answer would be, but by asking thoughtful questions and keeping an open mind, we all arrived at our solution: we would keep the original design.

So what happened here? Well the problem was that we had to make a decision. I could have pushed back against the proposed change because I thought it was a bad idea, or because work on this feature was already in-progress, or some other reason. But instead, I took a deep breath.

The problem was that we disagreed about the best path forward. The solution was open-minded, non-judgemental communication. It’s really important that you understand that I might not have “gotten my way” here, and that had to be okay. Getting my way wasn’t my goal; my goal was making the best decision, as a team.

Here is my approach to communication-as-problem-solving:

• Keep an open mind. Truly open, staying non-judgemental. People with different perspectives will disagree. That’s okay. In the example above, I accepted upfront that I might not get what I wanted.
• Start from a shared perspective. Whatever the disagreement is, find a place where everyone can agree. In the example above, I started the discussion by stating the goal of the feature we were building, and moved the conversation forward from there.
• Do inquiry work. Actively listen, and verify your understanding. In the example above, I played back my understanding of the other perspectives. This not only makes sure I understand, but it demonstrates to everyone else that I care about what they’re thinking.
• Prioritize your relationships. Your goal has to include maintaining your relationships with the other people in the conversation. In the example above, I could have pushed hard for what I wanted at the expense of damaging my relationship with my team’s Product Manager. In the long term, that’s counterproductive; building up my relationships with colleagues is always a priority for me.
• Maintain self-respect. This is the counterpoint of prioritizing your relationships. You need to respect yourself and respectfully assert your own perspective, too. In the example above, I maintained self-respect by offering my own perspective and proposing the decision that I thought would result in the best user experience.

Communicating as a way to solve problems works well for solving “disagreement” problems. It doesn’t work for every problem. Just like “divide and conquer” approaches are sometimes a bad solution, communication as a problem solving technique won’t always work (or work the most efficiently).

This technique also requires that you start from a place of shared understanding, which is sometimes the hardest part of using it. If you don’t share common ground, or you can’t find it, it will be difficult to communicate through your disagreement to find a solution.

I’ve been thinking more and more about communication as a way to solve problems. Maybe I’m getting older, or that it’s the time I’ve spent as a tech lead, or maybe it’s because I’m writing less code and more emails. But I really think there is something to thinking of communication as a way to solve a problem. It doesn’t always work, but it often works for me.