Conservation of Conflict
You can make conflict more pleasant, but only if you stop trying to get rid of it.
Good morning! The world is terrifying and hilarious. Today, you're reading Simpler Machines, a newsletter about making sense of it all while building awful metal demons– I mean– making software.
I'm Nat Bennett, and this month I'm also writing about walking around, which is more fun than it sounds.
This week I want to talk about a pattern that I've seen destroy engineering organizations and what to do about it. This isn't a pattern that's unique to engineering, but that's the kind of large human group that I'm most familiar with, so that's where most of my examples come from.
A few months ago, while dispensing dubious wisdom about Pivotal Tracker, I mentioned that if a team is arguing about features vs. chores, there's a hard conversation they're not having. They're having the little fight ("what label should we...") instead of the big fight ("who gets to decide what we...").
This pattern goes beyond features vs. chores, and into all kinds of tedious little arguments that teams get into. Call it the law of conservation of conflict.
In a given group, there will be a certain number of conflicts. Conflicts cannot be created or destroyed, except by changing the composition of the group.
Ever had a fight with a partner or friend about something stupid, that wasn't really about the something-stupid? That's this law in action. You don't want to have the big fight, so you have the little fight instead.
Real conflict is hard. Tabs vs. spaces is easy.
There are two underlying mechanics here.
People have conflicting interests. Some important resources are always limited, or perceived as limited. So a given arrangement of interests-in-tension produces a particular throughput of conflict. Resolve one of these conflicts peacefully, and the next one pops up a few days later.
Groups also have a "carrying capacity" for conflict. People tend to only be able to have so many fights at a time. When conflicts pop up and don't get resolved, the conflicts next week tend to get suppressed or attached to the previous conflict.
Now, it's not literally true that conflict in a given human system is fixed the way that energy in a physical system is fixed. For one thing, no human system is truly closed. A team's members have home lives, spouses, friends, all kinds of joys and frustrations that might make them more or less conflict-prone at work.
It's also possible for the basic parameters of conflict to change. Resources can be reallocated. The systems that allocate resources can be re-jiggered. People can leave or join the team. Enemies can appear, or be vanquished. Needs can be met, or threatened. Any of these can start, end, escalate, or deescalate an ongoing conflict.
So this model is wrong, but it's also useful. The factors that increase or decrease total conflict in a system tend to be several orders of magnitude harder to move than the factors that move conflict around. Interventions that intend to change the amount of conflict in a system (generally by reducing it) tend to just move the conflict instead (generally by submerging it and therefore making it harder to see and resolve.)
It's much higher leverage to move conflict out into the open, where the problem can be understood and addressed. You can resolve disagreements between people, but you have to be willing to have the fight. And because disagreements are going to continue to arise, you have to be willing to keep having the fight.
Thus, the first corollary: The law of better fights.
You can't eliminate conflict, but you can make it a heck of a lot more pleasant.
And the second: The law of predictable consequences
You can make conflict more pleasant, but only if you stop trying to get rid of it.
What I mean by "more pleasant" deserves some explication, because for most people, the approach I recommend is uncomfortable. People and groups shy away from directly addressing conflict for a reason. "More pleasant," then, is a long term state. Conflicts get resolved. The group makes progress, and doesn't have the same arguments over and over again. They don't weaponize kindness. You don't have to constantly "watch your back," or carefully weigh every statement you make for its effect on the ongoing tangle of unresolved squabbles.
Conflict in a given system has three basic properties: visible/hidden, clear/obscure, and reflective/non-reflective. (NB: I've gotten some feedback that the names for these categories don't seem quite right. I've done my best to explain what I mean but if you have trouble with the names or if you can think of better ones, let me know.)
Visible conflict takes place primarily in public channels. Everyone can see that it's happening. It's clear who's involved.
Hidden conflict takes place primarily in private. It's not clear that it's happening, maybe even to the people who are involved. It's hard to completely hide conflict, so often hidden conflict will open up in strange places, far from the originating team or pair. Two Product Directors won't admit that they disagree about a major product decision, so they spend months or years giving their teams conflicting directions instead, all the while claiming that they're "on the same page" when called on it.
Clear conflict has a relatively small gap between "what we're fighting about" and "what we're really fighting about." The participants are honest about the emotional or identity needs driving the surface-level conflict. It's clear to participants and to observers who wants what, and why.
Obscure conflict is about something entirely different than it appears to be on the surface. The surface-level conflict is a proxy for some more serious, harder-to-resolve problem. The conflict may be intentionally indirect on the part of one or more of the participants. "I'm mad at you about that thing you said about my father last Christmas, so I'm going to yell at you about the the thirty cents of electricity you used at my apartment last month." (True story!)
Non-reflective conflict is conflict that stays contained within its original bounds. It doesn't trip any additional triggers in its participants or spectators. It doesn't trigger sub-conflicts about how participants are engaging in it. There's no tone policing, and there's no tone to be policed.
Reflective conflict is conflict where the fight itself threatens someone's needs. The fight, or the way that it's being fought, becomes something to fight about. I'm not yelling, you're yelling!
It's better for conflicts to be visible, clear, and non-reflective. Conflicts with these properties start and stay smaller. They get resolved faster.
Most attempts to stop conflict instead hide it, obscure it, or reflect it.
The participants will hide that they're having the fight (including from themselves!) which makes them harder to detect by other agents who might be able to help. The participants will hide what underlying needs aren't getting met, which makes it harder to find creative or unexpected solutions that depend on information that the participants don't have or aren't seeing. The participants, or observers, will get stressed or scared by the conflict itself (because they've been told, explicitly or implicitly, that the conflict shouldn't be happening, or that there will be some kind of consequence to the conflict being detected) and start fighting about the fact that they're fighting.
The participants may start fighting with themselves, or various imprinted patterns that they carry around about conflict from childhood or past experience, and start reacting really strongly to otherwise innocuous incidents.
I've never seen conflict, per se, destroy a team, or an organization. I'm sure it happens, but I haven't personally witnessed it.
What I have seen is a refusal to resolve conflict – and habits that made conflicts unresolvable – destroy an organization's ability to solve its own problems. I've seen groups cycle – quietly, politely – through the same set of unworkable solutions, months or years, while a problem grew steadily worse, because they weren't willing to make the stakes amongst themselves clear, state their positions, and accept victory or defeat.
I've seen entire software projects molder, driving engineer after engineer to quit, because a group wasn't able to make a decision like, "Who should be responsible for the hard but necessary work of making it easy for our customers to install this thing?" Or even, "Who, exactly, is this product for?"
No conflict is totally visible, totally clear, or totally non-reflective. There are always loops clinging to themselves, twisting up into nervous knots. But no conflict is totally hidden, totally obscure, or totally reflective, either. There are always threads to pull and loops to untangle.
People who are skilled at handling conflict, and who create environments that appear low-conflict, are actually good at moving conflicts from the more pathological, more stressful, harder-to-address end of these binaries, over to the more productive, less charged end of the spectrum. They're comfortable confronting people directly– but kindly. They're capable of being vulnerable about their own needs. They're sensitive to the effects they're having on other people, and willing to modify their conflict "style" to avoid other people's triggers and sore spots.
Relatively speaking, anyway. No one has this mastered. The people who are best at handling conflict are also the ones who are the most aware of their personal failings.
Braintree practices pairing and test-driven development. I should have a post going up soon about what it's like to work on one particular team, but if you're interested in a very Pivotal Cloud Foundry-like experience, send me an e-mail and I can put you in touch with that team.
Had a very interesting conversation this week with the folks at Ignition Works that I hope to be able to share here soon. They're running a large Cloud Foundry and working on a product to help large organizations implement "continuous governance." UK only but if you want to work with folks who are very serious about continuous improvement I highly recommend getting in touch.
Productable is hiring engineers and a senior product manager. Their advisory board includes Janice Fraser, and if that's not a name that makes you sit up and take notice it should be.
The main bit of news everyone should read this week is this spectacular feature by Bloomberg about where, exactly, the $69 billion dollars supposedly backing Tether have wandered off to, and what that means for the broader crypto (and traditional!) economy.
A fun fact: Tether's current assurance that they are "100% backed by reserves" includes, and I am not making this up, an "attestation" by a small financial services firm that's based in the Cayman Islands that I won't link to because they don't have a valid SSL certificate. ("Doesn't have a valid SSL certificate" is tech jargon for "any idiot could replace the contents of that web page before it got to me and I wouldn't be able to tell.") Google "Moore Cayman" to see what I mean.
I am profoundly dubious about "crypto." I own a little bit, but I'm hesitant to do anything with it because the ecosystem is so clearly overrun with viral, decentralized pyramid schemes right now. It seems to me to be more of a factory for generating scams than any kind of realistic alternative to the traditional financial system, given system's transaction resolution times and the current technology's power requirements.
Likewise, I've seen some NFT projects that are kind of neat, and it's great that it's helping some artists get paid, but there's so much false-scarcity-hucksterism in that space that I don't currently feel comfortable exploring it myself.
A lot of this, I'll admit, is that I'm salty that I still can't get a PS5.