Communication styles - Working effectively as a team

This idea for this article came from a twitter thread by @ErynnBrook.

The thread explained the concept of man-splaining (which was eye-opening as I am a chronic explainer), but it also delved into communication styles, which is where things got really interesting.

Styles of communication

In short, there are two styles of communication:

  1. Competition Style
  2. Connection Style

Competition style is about coming out on top. Every statement is viewed as a move in a game, the goal is to say something that "beats" whatever the other players are saying, leading to a constant back of forth until there is a "winner".

Connection style is about connecting to the other person. Every statement is viewed as an attempt to empathise and an opportunity to explore a topic with them, creating a shared understanding of the issue and deepening the social connection between parties.

What's fascinating is that neither style is inherently better than the other, competition is good in certain contexts whereas connection is better in others. Most of the time we're not even aware that we're using a certain style, it's just how we communicate. This can lead to tension, as two people communicating using different styles are not going to reach consensus.

With the above understanding under my belt, I realised I'd seen both styles used everywhere, in software development and every other aspect of business. Great teams used each style effectively, creating team consensus and better solutions, whereas poor teams used them incorrectly, creating tension and poor results. Let's go through some styles of collaboration and explore when each style works best.

Exploring solutions

Say your team needs to come up with a solution to a problem (be it implementing a new feature or fixing a broken one), what's a good way to do this?

  1. First off, you should start with a connective style, as you need everyone to be on the same page about the problem at hand. Your goal is to reach consensus, if you can't do that then there's no point in moving forward.

  2. Once you've agreed on what you're there to do, it's time to brainstorm, which means a switch to competitive style. The goal here is to compete with each other to come up with the "best" solution, creating as many as you can. Ego will play a roll here and that's fine. It's also ok to point out flaws in someone else's solution, but don't focus on that, the goal is to come up with solutions, not filter them.

  3. Now that you've brain stormed, it's time to reach consensus, that's where connective style comes into play again. Go through each of the ideas and make sure that each one of you has a shared understanding of the pros and cons of each. This isn't about being right, it's about a shared understanding.

  4. Now that everyone is on the same page, we can switch back to competitive and try to figure out which is best. At this point, ego should not be in play. Winning here isn't about choosing an idea you created, it's about figuring out which idea is best overall. This might involve choosing one solution, or combining solutions (which I find is often the case). It's a competition between solutions, not people.

  5. Once you've done this and you think you've reached the best solution, don't end the conversation, instead be sure to switch back to connective style and make sure everyone is on the same page and is in agreement. This ensures that there's no unresolved tension and everyone is agreed on next steps. At the end, everyone should be happy and even feel comfortable saying "Go team!".

Looking at the above, it's clear there's a pattern, which at it's simplest is the following.

Connective -> Competitive -> Connective -> Competitive -> Connective

It turns out this is a recurring pattern.

The feedback loop

At it's core it's all about the feedback loop. The above can be distilled down to the following, a constant loop where you switch between styles when appropriate, starting and ending at connective.

Feedback Loop

If you need to come up with lots of ideas, go competitive, when you need consensus, switch to connective. It really is that simple.

It's everywhere

What's funny is the same process works in so many other contexts.

Say you're trying to figure out the fix to a bug, it will follow the same process.

  • First you reach agreement on the bug (connective)
  • Then you compete on figuring out potential causes (competitive)
  • Then you reach agreement on which is most likely (connective)
  • Then compete on ways to prove it's actually the bug (competitive)
  • Then agree on who will do the work and how it will be verified (connective)

What about pair programming? Same thing, it's a constant switch between the two styles. If you need to explore solutions, compete to come up with ideas. When you need to reach consensus on the next step, connect.

Using the wrong style

A little word of warning, I mentioned above that I've seen styles misused. Let's quickly go into that.

Say you're trying to create ideas, if you're in a connective communication style, the team will settle on the first solution presented, even if it has glaring flaws that healthy competition would unearth.

The same is true with competing at the wrong time. If you're trying to reach consensus and instead of agreeing you're competing, then you'll get nowhere, you'll just end up frustrated and tired.

Finally you could have team members using different styles at the same time, so it always feels like you're never on the same page and that your discussions have no momentum, they're always stopping and starting jarringly.

A quick guide to spotting the above:

  • Are you always agreeing with each other but your solutions fall apart as soon as you implement them? Then you're not competing enough.
  • Is your team tense and you always feel like you're never getting your say, you're always doing what someone else says? Then you're not connecting enough.
  • Are you uncomfortable when communicating with certain members of the team? You might be connecting when they are competing, so you may need to switch styles (temporarily).

Conclusion

So that's that. When you're working with others, figure out what is the best style to apply for the given situation. Are you exploring ideas? Then compete. Are you trying to reach consensus so you can move forward? Then connect.

In my mind, everyone is a leader, so if you notice that the team is stuck in an ineffective mode, attempt to switch them out of it. (The twitter thread linked above has some great advice on how to switch from competitive to connective, have a read through so you're better prepared).

For myself, I'm going to pay more attention to how I communicate and I'm going to encourage those on my team to do the same. Ultimately, it's about working together to be effective.

Tweet

Expert help

Have a codebase where change is expensive and risky?