Wife Swapping and the Art of Conflict

The problem with books on management is they rarely address what actually makes teams successful. One of the best books I’ve come across is The First Ninety Days by Michael Watkins, which explores how to guard against common mistakes leaders make when they start new roles. A big theme with Watkins is how not to bring your last job with you, however successful you may have been in it. He points put that many managers, even good ones, will often rush to make decisions too soon because they believe they can see exactly what needs changing on day one. Later, he talks about early wins and how making quick and bold decisions can be effective.

Although seemingly contradictory statements, he is at pains to point out that good decisions are made when appropriate context has developed around them. That is to say, on day one you have little-to-no context so you shouldn’t feel pressurised to make changes (despite the understandable expectations that may have preceded your arrival) but if you allow too much context to develop you risk losing the initiative and being seen as a ditherer.

Anyone disagree with that? No. Of course not. If you took on a new team and discovered widespread humiliation because the last manager made them all do a special dance every day, you’d stop that tradition dead. No context needed for that, right? But if one half of the team start telling you the other half can’t do their job properly, and that half say they can it’s just the first half aren’t doing theirs properly, you would (I hope) feel that further investigation is warranted before making any decisions. And with all due respect to Michael Watkins (if you only ever buy five management books, I’d suggest this be one of them) the notion of needing context to make good decisions feels to me like common sense.

When I wrote Ten Reasons Change is an Antipattern I was thinking about how easy it is to get caught up in a change cycle where causing things to be different than they were becomes the main goal rather than making things better. No organisation is 100% awful, so context is the knowledge that allows you to ignore the 80% that functions OK and see the opportunities for tweaking the remaining 20%. If one of your direct reports hasn’t delivered a thing in years, spends half their time in pointless meetings and disappears everyday at 4pm, you could just replace them (and that might work) or you could show a bit of leadership and try and inspire in them a new drive and ambition. The second option would be the greater achievement (the first is easy) but you couldn’t contemplate it without significant context.

But maybe common sense isn’t very common after all and hence there’s a genuine need to share these ideas. That would be fine, except that there’s also a more significant issue at play here, which is that it tends to be those who already have common sense that seek the knowledge to better themselves. I quite enjoy the Daily WTF blog so when I came across a link to a post on Jeff Atwood’s Coding Horror entitled What’s Wrong With The Daily WTF I was all ready to steam in with a comment aggressively defending it. But frankly I couldn’t disagree with Jeff’s statement that “the kinds of developers who could benefit most from reading WTF simply do not– and never will– read the WTF website”.

It’s pretty depressing to think that the majority of people who seek out knowledge are the ones who will benefit least from it, whereas those that don’t seek at all are suffering from what psychologists call unconscious incompetence - blissfully unaware that regular visits to the Daily WTF would improve their ability while dismissing as laughably impractical anyone who tells them otherwise.

But perhaps it need not be that depressing. Maybe there is a way to address the imbalance via the Art of Conflict.

The Art of Conflict

Not too long ago I read The Five Dysfunctions of a Team by Patrick Lencioni. It’s a .. er .. management book (OK I may be suspicious of them but I do occasionally pick up second-hand paperback copies when they’re dirt cheap, if only to convince myself that I’m in the common sense minority..) but one with a difference. Rather than create a reference manual of what he believes leaders should do, Lencioni regales us with a management parable concerning one Kathryn Petersen’s appointment as the new CEO of the fictional IT company DecisionTech. I confess I was pretty sceptical of this approach but, being something of a student of fiction writing and narratology generally, I was intrigued to see what style of prose Lencioni would adopt to tell an enterprise IT management story. I must say, in the most complimentary sense, Lencioni can write like a woman - on its literary merits alone The Five Dysfunctions of a Team is a decent read: pacey, observant to detail, with only rare moments that highlight the gender mismatch between protagonist and author.

We see Kathryn Petersen appointed to lead a predictably dysfunctional management team responsible for a struggling, but otherwise perfect, software organisation and set about making them effective leaders and co-workers.

Her logic (said backwards) goes like this:

A management team will deliver poor results (dysfunction one) if they don’t each take accountability for their own areas and hold each other accountable for theirs (dysfunction two). Nobody takes accountability for anything without feeling truly able to commit to it (dysfunction three) and nobody ever feels like committing to anything without their point of view being taken into account (dysfunction four) and finally nobody airs and shares views openly without a base level of mutual trust and respect (dysfunction five).

Her team building plan (said forwards) is therefore this:

Building trust allows conflicting views to be aired, which enables commitment to objectives, and thence to mutual accountability and ultimately results.

The part of that which really stuck me was the bit about conflict.

Conflict not Consensus

In software, more than anywhere else I know of, conflict is at the root of all that’s good and bad. Take a wander through any of the major technology sites on the web and you’ll see all-out battles about which Java web-page/logic separation software is best, whether Rails sucks, what Agile is all about, when it’s appropriate to start writing software tests, and of course the age old Microsoft vs. Anything Else fight to the death.

It might seem to the outside observer that, when it comes to certain topics, we are a people at war. And if it’s not war on the web it’s war in the office - between Business Analysts and Developers, Developers and Architects, Project Managers and Testers, Testers and Operations. It’s as if we forget what our real objective is, which I’m sure someone told me once is something to do with business and happy customers.

Wherever there’s infighting that distracts us from a common goal, it’s natural to think that the answer is to reach consensus. Consensus (everybody agreeing) even sounds like common sense, but in many cases it’s not. Consensus is generally not good. When a senior manager asks Kathryn Petersen whether they can reach mutual accountability and commitment by achieving consensus she is quick to respond:

Consensus is horrible .. consensus becomes an attempt to please everyone .. which usually turns into displeasing everyone equally.

Consensus is bad for commitment because it’s hard for anyone to commit fully to an equally-pleasing watered-down version of something and, as we so often experience in the non-fictional world, trying to reach consensus can result in endless paralysing debate (which is not conducive to business and happy customers).

Let’s take a common IT example. You are working on a project where’s there’s a difference of opinion about the right design to meet a business requirement. There are pros and cons for each (there always are). One probably requires more work now for a bigger potential pay-off later. One might be based in a different technology stack than the other. The business/happy customer answer is not a bit of each, but one or the other. Some analysis (context) will be required, but however you cut it one side of the argument needs to lose. The key is in enabling both sides of the conflict to be fully exposed, not to reach consensus.

To quote Kathryn Petersen again:

The point here is that most reasonable people don’t have to get their way in a discussion. They just need to be heard, and to know their input was considered and responded to.

Of course many times consensus is natural. Designs come into being, get critiqued, and die away or naturally evolve until agreement is reached. You do this in your head thousands of times a day and it never feels like conflict. A leader’s job is to make the externalised inter-personal version of this feel just the same.

Who’s on First?

A manager has two parts to play. One is as a member of their own team, promoting unity, giving direction and so on. The other is as a member of a peer group enabling the kind of healthy conflict that leads to everyone being heard and commitment reached. What Kathryn Petersen calls the “first team” is where conflict must be exposed - on the battleground we call “meetings”. She even says that if you find meetings boring then it’s a sure sign you aren’t engaging in proper conflict. We don’t find movies boring and yet, compared to a movie, meetings are shorter, more personal, more interactive and more relevant to our real lives. And what does a good movie script have? Conflict. As Peter Reeves in “Defining Conflict in Screen and Play Writing” says “without conflict there is no opportunity for a resolution”.

Isn’t Conflict just Fighting?

Saying that airing views vociferously and openly is a good thing is not without risk. Some people will always take it too far. But enabling conflict means balancing it equally between all sides. And to those who say that, even equally, it’s still just fighting Peterson has an answer that should resonate with anyone who’s ever worked in a corporate environment trying to get the simplest thing done in a sea of leaderless bullshit:

You are fighting. But about issues. That’s your job. Otherwise, you leave it to your people to try to solve problems they can’t solve. They want you to hash this stuff out so they can get clear direction..

Proper constructive conflict ends in resolution, rarely ever consensus. Individual opinions may not change, but that’s a good thing otherwise there will be no opportunity for informed debate next time. However they must be voiced, heard, argued and exhausted.

And the secret to managing resolution lies in the wife swap.

The Wife Swap Pattern

This article sat half-written for months because I never thought it had a satisfactory ending. Total credit for all that follows goes to Richard Bundock who unwittingly, over a pizza and without conflict, provided the resolution it needed. As analogies go, I think this exemplifies productive conflict better than most.

There’s a show on TV called Wife Swap. The format seems to have been picked up by many countries so hopefully most people are familiar with it, but I’ll summarise here lest anyone think I’m promoting the idea that intimate knowledge of your co-worker’s spouse is a good way to resolve a question over enterprise Java deployment.

The program starts by profiling a relaxed, loving, family-orientated woman who’s also a bit untidy, lives in a slightly grubby house with happy kids who lack structure, discipline and good manners. The we get to meet her nemesis - an uptight, controlling, super-neat high-achiever with kids who are well behaved, well presented, polite but really quite lonely. They spend one week living in the other’s house, under the rules it normally operates by, and then have the chance to make some changes for the second week.

The respective husband’s reaction to the new regime ranges from resistance and tantrums to a kind of disbelieving euphoria, depending on whether their marriage is based on opposites attracting or birds of a feather flocking together. Apparently a corporate version called Boss Swap was piloted but didn’t take off. I guess it’s easier to disappear back into anonymity as a spouse than risk your whole career by looking incompetent on TV.

The show culminates in an often-fiery first meeting between the two women on neutral territory, where they defend their lifestyle choices whilst criticising the other. Seemingly it’s just voyeuristic TV but the women do apparently get something from it. The relaxed untidy one recognises that her kids need a bit more structure and the neat-freak sees that she’s not spending enough time with hers.

Why it works I think is that it forces each side to fully explore the other before there’s a chance to make their case, and only then is there an opportunity for any face-to-face confrontation. They don’t reach consensus (it ain’t like they’re ever going to be close friends or go on holiday together) but the visceral exposure to another way of thinking does allow each to achieve a personal resolution.

If only to rush home and beat the crap out of their snivelling dastardly husband for embarrassing them on national TV.