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.


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

Open source CMS evaluations

I have now seen three more or less serious open source CMS reviews. First guy to hit the field was Matt Raible ( 1 2 3 4 ), ending up with Drupal , Joomla , Magnolia , OpenCms and MeshCMS being runner-ups. Then there is OpenAdvantage that tries out a handful ( Drupal , Exponent CMS , Lenya , Mambo , and Silva ), including Plone which they use for their own site (funny/annoying that the entire site has no RSS-feeds, nor is it possible to comment on the articles), following Matt's approach by exluding many CMS that seem not to fit the criteria. It is somewhat strange that OpenAdvantage cuts away Magnolia because it "Requires J2EE server; difficult to install and configure; more of a framework than CMS", and proceed to include Apache Lenya in the full evaluation. Magnolia does not require a J2EE server. It runs on Tomcat just like Lenya does (maybe it's an idea to bundle Magnolia with Jetty to make it seem more lightweight). I'm still sure that OpenAdvant

Considerations for JavaScript in Modern (2013) Java/Maven Projects

Disclaimer: I'm a Java developer, not a JavaScript developer. This is just what I've picked up the last years plus a little research the last days. It's just a snapshot of my current knowledge and opinions on the day of writing, apt to change over the next weeks/months. We've gone all modern in our web applications, doing MVC on the client side with AngularJS or Ember , building single-page webapps with REST backends. But how are we managing the growing amount of JavaScript in our application? Yeoman 's logo (not necessarily the conclusion of this blog post) You ain't in Kansas anymore So far we've just been doing half-random stuff. We download some version of a library and throw it into our src/main/webapp/js/lib , or we use it from a CDN , which may be down or unreachable when we want to use the application.. Some times the JS is minified, other times it's not. Some times we name the file with version number, other times without. Some

Git Stash Blooper (Could not restore untracked files from stash)

The other day I accidentally did a git stash -a , which means it stashes *everything*, including ignored output files (target, build, classes, etc). Ooooops.. What I meant to do was git stash -u , meaning stash modifications plus untracked new files. Anyhows, I ended up with a big fat stash I couldn't get back out. Each time I tried, I got something like this: .../target/temp/dozer.jar already exists, no checkout .../target/temp/core.jar already exists, no checkout .../target/temp/joda-time.jar already exists, no checkout .../target/foo.war already exists, no checkout Could not restore untracked files from stash No matter how I tried checking out different revisions (like the one where I actually made the stash), or using --force, I got the same error. Now these were one of those "keep cool for a second, there's a git way to fix this"situation. I figured: A stash is basically a commit. If we look at my recent commits using   git log --graph --

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 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 o

Leaving eyeo

Thirteen blog posts later, this one notes my departure from eyeo after 4 years and 3 months. I joined eyeo around the headcount of 80 employees, and now I think there's just over 250 people there. My role coming in was as operations manager, doing a mix of infrastructure engineering and technical project management. I later on took on organizational development to help the company deal with its growing pains . We introduced cross-functional teams, departments (kind of like guilds), new leadership structures, goal-setting frameworks, onboarding processes and career frameworks.  And all of this in a rapidly growing distributed company. I'm proud and happy that for a long time I knew every employee by name and got to meet every single new-hire through training them on company structure and processes.  At some point, we had enough experienced leaders and organizational developers that I could zoom back in on working in one team, consulting them on  Git and continuous integration