Skip to main content

Mediation in Teams

I recently found myself mediating a personal conflict within a team. In this post, I'll share what I quickly had to pick up and learn in order to do so.

Disclaimer: I am not a trained professional in conflict handling. If you find yourself in a similar situation, get professional help from a trained mediator and do not try to do anything without the backing of the supervisor(s) of everyone involved!

Spotting the conflict

I try to keep some tap on the conversations that are happening around the company, and in particular I try sensing conflicts. In this case, I spotted what at first looked like a regular somewhat heated exchange in a distributed team, and then as the discussion continued, the participants started to pull for executives to come in and break the argument in their favor. The topic under discussion was definitely a team-internal thing, so my alarm bell started chiming. This didn't feel like a regular technical discussion. It had an air of threat and desperation to it.

Getting hold of the situation

I first reached out to the team's project manager to point him at the situation. At first, he was hesitant to take any extra-ordinary action, instead preferring to deal with it at their next regular team meeting. I offered to facilitate a retrospective for them, which he accepted, and I figured this would be a good start, and I wasn't sure I should push for anything more urgent.

Next, one of the executive managers who now had spotted the conflict (or had been pulled in by the participants) decided to speed things up, and I got invited to facilitate a meeting for the involved before the end of the week.

Even though the invitation was formulated as a retrospective, I had a feeling it would be something else. So I quickly started reading up on mediation, in case that would be necessary.

Figuring out what to do

There's common sense, and then there's professional help. We do have several coaches around with more experience on this, but as vacations and timelines played out, I couldn't access them, and I figured expediency was the right thing for the situation. Starting at the obvious place, I skimmed through search results and Wikipedia until I came across Party-directed mediation.

From Wikipedia:
Party-directed mediation (PDM) is an approach to mediation that seeks to empower each party in a dispute, enabling each party to have more direct influence upon the resolution of a conflict, by offering both means and processes for enhancing the negotiation skills of contenders. The intended prospect of party-directed mediation is to improve upon the ability and willingness of disputants to deal with subsequent differences.
It was developed by Gregorio Billikopf who was very inspired by Carl Rogers, who again is the psychologist behind the "active listening" technique (and a whole lot of other stuff!). There's also some shared background here with nonviolent communication, and Billikopf references NVC quite a few times in his work.

Now, I don't know my way around too much mediation material and theory, but I think I struck gold by quickly finding and making use of PDM, because:

  • The material is very easy to understand, basic enough for layperson like myself and easily applicable.
  • Billikopf has published a free book about it (I sped through the first 4 chapters), so there's no hurdle for attaining it.
  • He has published a free audio-book about empathic listening (one hour, I listened to this twice).
There are areas where PDM does not apply well. My understanding is that it works well for parties that share a lot of the same goals, like colleagues in the same team, or divorced parents that want the best for their children. Less so when it's about reaching settlement between competitors or parties with little in common.

Inviting each party to a pre-caucus

This is the first part of PDM: The idea is to hear each party out separately in advance of the first meeting. This sounds like pretty much common sense to me (I invited them before I even found out this was a thing in PDM). Interestingly, this is quite frowned upon in other schools of mediation! You can read more about why in the book.

Each of these individual sessions were quite revealing. It turned out that the recently contested issue was the last in a series of events tied to a situation that had been souring for almost a year. The parties would work together "professionally", and have meetings where the underlying issues did not surface. I'm betting this is very common in workplace situations where mediation becomes necessary though.

The intention of the pre-caucus isn't so much to investigate what happened (although an understanding of this is certainly helpful - both parties should realize that you are genuinely trying to understand them and their (re)actions). Rather, this session gives each party an outlet to get out a lot of built-up pressurized frustration.

Initial session

The initial session was more of a inner-team meeting, where my aim was to get a shared understanding in the team of the issue(s) at hand. I started by explaining some rules of moderation and outlining the agenda. Then a more humorous check-in (what's your favorite breakfast?). 

Then we did one larger round (10-20 mins for each of the 4 involved). I asked each of them "What is forming and storming in the team? How do you feel about how the team is working?"

Each of the involved answered in very different ways, but in the end most of the pent-up frustration became evident to everyone in the room. A memorable moment for me was when the third team member (not one of the conflicted parties) described the situation as being the child of a quarreling divorcing couple. This more than anything convinced me that this was a case for mediation rather than escalation.

We ended the session with each of the people present committing to a few action points, one of which being that the two conflicted parties continue with me into a mediation process.

Two rounds of mediation

I'm not sure what else I can say about these sessions than that they were really heavy mental work. I'm extremely glad that I had at least the PDM theory with me at this stage, as keeping the mediation centered was really difficult. These sessions were focused on getting each party to empathize with the other. It was quite the emotional roller-coaster, with making a lot of progress for then falling back again due to an old wound that got discovered again and again. In the end, we agreed that one of the party would put together a proposition on how they could agree to work together. 

Concluding the mediation

At what felt like was the end of these conversations, I was quite certain that we would not be able to reach any compromise on how we could try to move on. The party with the proposition was about to abandon the idea, so we did another caucus to try one last time to build the empathy for the other party that would allow the proposition to come through. It worked, and at the time of writing, the parties are drafting this into agreement form.

At this point, I felt I had done what I could do for them at this stage. So I sent them off with a "good luck" email reminding them of the reasons I had found for believing they could and would work together excellently, if they would try trusting each other again. This part quoted below explained my perspective, and I think that frames well what this kind of mediation is about:

I want to thank you both for being there this week. I commend you both for participating in the mediation willingly, and sharing so much of yourselves.
As you probably have figured out by now, it is not my place to pass any judgement on which of you did the most wrong or right.

As a mediator, it's my place to assume that you both have made mistakes, and that your are both victims of the circumstances. Whether one of you is more right or wrong than the other, I don't know, and I'm not trying to find out. It has been our co-opt mission to get you into a conversation where you can arrive at a strong compromise together. Something good enough to try.
You were both quite caught up in seeing negative patterns in the other's acts over the preceding year. You both wanted solutions that you believed contradicted the wants of the other. You both felt the need to escalate the issue in order to get the other subdued in some way, to be guaranteed that you will not get hurt again.

I understand you both. It is human to feel hurt, and fear future harm. There are enough outside factors here to have caused this situation without either one of you having to be more guilty than the other.

Follow-up

The PDM technique is very time intensive. It could run over a dozen hour long sessions. In our case, we had limited time, especially on my end, and scheduling face time was difficult, being a distributed company. I had to conclude earlier than I felt comfortable with, but at the same time I felt we had given the situation a fair chance. 

If they end up escalating the issues later anyway, the parties will at least now have a much clearer understanding of each other and their issues.

We'll also be looking into how we can instantiate a mediation/escalation processes across other teams in order to lead similar situations into the mediation funnel much earlier. Even if all teams are working well today, we want to have a system in place for handling conflicts before they snowball into dramatic proportions.

Popular posts from this blog

Encrypting and Decrypting with Spring

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities. It "was decided" that we'd be doing AES with a key-length of 256, and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet!

The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE in order to do 256 bits. It's a fascinating story, the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them.

Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password and sa…

Managing dot-files with vcsh and myrepos

Say I want to get my dot-files out on a new computer. Here's what I do:

# install vcsh & myrepos via apt/brew/etc
vcsh clone https://github.com/tfnico/config-mr.git mr
mr update

Done! All dot-files are ready to use and in place. No deploy command, no linking up symlinks to the files. No checking/out in my entire home directory as a Git repository. Yet, all my dot-files are neatly kept in fine-grained repositories, and any changes I make are immediately ready to be committed:

config-atom.git
    -> ~/.atom/*

config-mr.git
    -> ~/.mrconfig
    -> ~/.config/mr/*

config-tmuxinator.git  
    -> ~/.tmuxinator/*

config-vim.git
    -> ~/.vimrc
    -> ~/.vim/*

config-bin.git   
    -> ~/bin/*

config-git.git          
    -> ~/.gitconfig

config-tmux.git  
    -> ~/.tmux.conf    

config-zsh.git
    -> ~/.zshrc

How can this be? The key here is to use vcsh to keep track of your dot-files, and its partner myrepos/mr for operating on many repositories at the same time.

I discovere…

Always use git-svn with --prefix

TLDR: I've recently been forced back into using git-svn, and while I was at it, I noticed that git-svn generally behaves a lot better when it is initialized using the --prefix option.

Frankly, I can't see any reason why you would ever want to use git-svn without --prefix. It even added some major simplifications to my old git-svn mirror setup.

Update: Some of the advantages of this solution will disappear in newer versions of Git.

For example, make a standard-layout svn clone:

$ git svn clone -s https://svn.company.com/repos/project-foo/

You'll get this .git/config:

[svn-remote "svn"]
        url = https://svn.company.com/repos/
        fetch = project-foo/trunk:refs/remotes/trunk
        branches = project-foo/branches/*:refs/remotes/*
        tags = project-foo/tags/*:refs/remotes/tags/*

And the remote branches looks like this (git branch -a):
    remotes/trunk
    remotes/feat-bar

(Compared to regular remote branches, they look very odd because there is no remote name i…

Joining eyeo: A Year in Review

It's been well over a year since I joined eyeo. And 'tis the season for yearly reviews, so...

It's been pretty wild. So many times I thought "this stuff really deserves a bloggin", but then it was too inviting to grab onto the next thing and get that rolling.

Instead of taking a deep dive into some topic already, I want to scan through that year in review and think for myself, what were the big things, the important things, the things I achieved, and the things I learned. And then later on, if I ever get around to it, grab one of these topics and elaborate in a dedicated blog-post. Like a bucket-list of the blog posts that I should have written. Here goes:
How given no other structures, silos will grow by themselves This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies without the…

The End of GitMinutes (my podcast)

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well:

I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there.

It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences.

To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer science a…