There are organizations which are managed by conflict. You can actually feel cortisol in the air once there, with people actually yelling, staggering amount of sick leaves and industry record high rotation. Rumor has it, it doesn’t happen very often in IT companies, which, as we all know, are relaxed, cool and fun to work at. Though we can have it very wrong – the other way around.

There are four generally known and accepted phases of team development. First, there is forming, when we learn to know each other and quietly hope that nobody around is a psychopath. Storming follows, when we drop our masks and decide to stand our ground, stating clearly what we mean – a lot of yelling might be involved, as almost everybody does that. Once the dust falls, team goes into norming – just doing what’s expected, with some responsibility showing up. Finally, there’s the mythical performing phase, where team raises its own bar and when, supposedly, actual leader or Scrum Master is no longer needed (which is a lie, but we’ll talk it over another time). I call this stage ‘mythical’ as, at most organizations, the way of working and way of leading actually prohibits team from getting there, with people being shuffled between teams and managers ruining everything by exercising their organizational power.

But there’s a caveat regarding the four phases. Going back to first paragraph – we don’t want our work environments to be stressful, right? It should all be calm and relaxed, with (dreadfully noncompetitive) sustainable peace around, right? So, we should avoid conflicts, right? It’s small wonder then, that quite a lot of teams don’t have their storming phase. Once their members start to wage little wars within in order to make proper internal borderlines, the furious calmness of relaxed culture converges on them. Thou shalt not be conflicted, never! This attitude can be heavily biased by national tendency to collectiveness, as described by Geert Hofstede. People influenced by culture of some countries (mostly, though not limited to, Asian and Nordic) are even more leaned towards conflict avoidance.

What happens to the team once they’re in such environment? There’s another, optional phase. It’s called false normalization. So, seemingly we’ve been through the storming, seemingly we’re all OK with each other and seemingly we’re up to speed as a team. However, all the conflicts are still there, unresolved, buried right below the ground. And where they are, there’s no way to build trust, without which there can be no responsibility – which means the team will be of, at best, wildly mediocre performance.

How would one avoid this? First, realize that it’s natural for people to conflict, to disagree, to keep (subconsciously) estimating “Where am I in the hierarchy?” at any given moment. Second, tell that to the team. Explain them the four phases, help them understand that you actually expect the few following weeks to be a bit nervous. Learn them the assertive “win-win” conflict resolution approach – nobody is born with this skill, so you can easily assume they don’t have it. Third, make sure you have a proper leaders around. There’s this concept of “leaderless” Agile teams, which is all cool and nice, but, through history, it never made sense. It didn’t work with the French revolution, didn’t work with the Communist revolution and it just doesn’t work with the Agile revolution. A good primer on how to create fantastic leaders is “Leaders Eat Last” by Simon Sinek.

What to do if the damage is already done? Send the team back into abyss of forming. It’s surprisingly easy and most organizations, accidentally, do it all the time. Just swap out one or two team members for another ones. It’s that easy. Now, they’ll have to learn of each other again. They’ll have to set up a new borders. They’ll have an opportunity to become the team that rocks.

(Post originally published at my blog: