The Starship Was Fine. The Crew Was on Fire.

A few weeks ago, two players in my Star Trek game got into an argument. Not an in-character argument, not Klingons threatening the Federation, and not somebody objecting to the captain violating the Prime Directive for the fourteenth time. Two actual human beings got pissed off at each other.

It went from zero to yelling and back to silence in less than a minute. I probably could have shut it down a few seconds earlier. That’s the mistake, and I’m not particularly interested in spending 2,000 words defending or dissecting it. I was running the table, the temperature suddenly went vertical, and in retrospect I could have reacted a little faster. Fine. Lesson learned.

What happened afterward is much more interesting, because everybody came back.

The argument wasn’t really the problem

Any group of people who spend enough time together will eventually have conflict. That’s true around a gaming table, it’s true in a family, and it is absolutely true inside a company. People have bad days. People misunderstand each other. Someone makes a comment that lands completely differently than intended. Existing frustration gets attached to whatever happens to be happening at that particular moment. Sometimes two perfectly reasonable people temporarily become unreasonable at exactly the same time.

Congratulations. You now have an incident.

The important question isn’t whether your team can avoid every incident forever. I don’t think that’s even a realistic objective. The more useful question is what the group does after one happens.

In our case, I talked to people individually. I listened to what each person thought had happened and tried to understand what was underneath the immediate argument. I also owned the portion that belonged to me: I was running the table, and when things suddenly escalated, I could have stepped in a little faster.

What I wasn’t particularly interested in doing was holding a tribunal to determine which player had accumulated the greatest number of Wrong Points. I didn’t need a winner. I wanted my table back.

Now replace the players with executives

At some point while working through all of this, I realized how familiar the situation actually was.

Forget Star Trek for a minute. Imagine these aren’t two people sitting around a gaming table. One is your VP of Engineering and the other is your VP of Product.

Product says, “You keep changing the implementation and telling us what we’re allowed to build.”

Engineering responds, “Because you keep changing requirements after we’ve already committed engineering resources.”

Product fires back, “Engineering doesn’t get to decide the product.”

Engineering says, “And Product doesn’t get to promise things that can’t actually be delivered.”

Anyone who has spent enough time in technology leadership probably just felt their blood pressure increase slightly.

Here’s the important part: they might both be right.

Product should push Engineering, and Engineering should push Product. Product should care about what customers need, what the market needs and where the company is going. Engineering should care about feasibility, architecture, technical debt, security, reliability and the consequences of turning every Tuesday-afternoon idea into a production requirement.

Those responsibilities naturally create tension. That isn’t necessarily dysfunction. In fact, sometimes it’s exactly what you want.

I deliberately manufacture this kind of conflict

One of my favorite leadership techniques is something I call oppositional planning. I’ll give several people the same problem and the same requirements, but instead of immediately putting everybody in a meeting and allowing the loudest idea to become the group’s idea, I have them develop their approaches independently.

Then we put the proposals on the table and politely tear them to shreds.

What’s going to break? Which assumption is wrong? What happens at ten times the expected load? What did this proposal forget? Why are we building this ourselves? What security boundary did we just accidentally eliminate? What happens when the network disappears? What happens when the customer does something completely ridiculous that nobody put in the requirements because surely nobody would ever do that?

Somewhere inside that argument, a much better design usually emerges.

I don’t want engineering teams that agree with each other all the time. That would actually worry me. I want people who are willing to look at something I designed—or something their boss designed—and say, “I think you’re wrong, and here’s why.”

But that only works if everybody in the room understands one fundamental rule: we are attacking the proposal. We are not attacking the person proposing it.

That’s the boundary. Once that boundary disappears, productive conflict becomes interpersonal conflict, and once that happens, the technical problem isn’t the most important problem in the room anymore.

You don’t always have to decide who won

When two people have an argument, there’s enormous pressure on whoever is in charge to determine who was right. Sometimes that’s absolutely necessary. If someone behaved abusively, violated a policy, discriminated against somebody or crossed a serious boundary, you don’t solve that by putting everyone in a circle and talking about friendship.

Ordinary human conflict isn’t always that clean, though. Sometimes one person says something shitty. The other person responds badly. The first person gets defensive. The second person gets louder. Thirty seconds later, everybody is standing around wondering what the hell just happened.

You can spend the next week reconstructing the argument like the NTSB investigating an aircraft accident, or you can ask a different question: What has to happen for these people to work together again?

That was the question I cared about.

People needed some room to cool down. They needed to feel heard. They needed an opportunity to understand what the other person thought had happened, even if they didn’t completely agree with that interpretation. And nobody needed to be publicly humiliated as the price of reconciliation.

There’s a version of conflict resolution that’s really just conflict continuation with management participating. Gather everyone together immediately, force an apology, establish who was right, establish who was wrong, demand closure, and congratulations: you’ve now turned a sixty-second argument into a three-hour meeting and given everyone several exciting new things to resent.

Sometimes the better leadership move is simply creating enough space for reasonable people to become reasonable again. Then you deal with whatever actually needs dealing with.

The outcome is the part I’m proud of

Everybody came back.

That’s the part of this story I actually want to celebrate. Nobody had to leave the game. Nobody had to be declared the winner. Nobody had to pretend nothing happened. The campaign continued, and more importantly, the relationships around the table survived the incident.

That tells me considerably more about the health of a group than whether the group can maintain a perfect record of never arguing.

I don’t think psychological safety means nobody gets angry. I don’t think a healthy engineering organization is one where Product and Engineering never fight. And I definitely don’t think good leadership means constructing an environment where everyone agrees with the person in charge.

I want disagreement. I want somebody willing to tell me my architecture is wrong. I want Product willing to tell Engineering that the technically elegant solution doesn’t solve the customer’s problem. I want Engineering willing to tell Product that the thing they just promised would require violating several laws of physics and at least one RFC.

I want smart people arguing passionately about important things.

What I want underneath that is enough trust that the argument doesn’t destroy the relationships.

Resilience is different from harmony

There’s a subtle distinction here that I think matters enormously in leadership. Harmony describes what things look like when everything is going well. Resilience describes what happens after something goes wrong.

Can two people disagree again without immediately reopening the previous fight? Can someone say, “I was pissed off,” and somebody else say, “Yeah, I shouldn’t have said that,” without requiring a Supreme Court ruling about who was objectively correct? Can the group absorb one shitty minute without allowing that minute to define the next six months?

That’s resilience, and I’ll take a resilient team over a superficially harmonious one every time.

A few weeks later, we’re still playing Star Trek. They’re both still at the table. The campaign survived, and so did the relationships around it. We dealt with what happened, learned from it, and went back to exploring the galaxy.

That’s the outcome I care about.

Captain Picard could end an argument by ordering everyone back to their stations. Unfortunately, actual leadership doesn’t come with four pips and a scriptwriter. People are messy. Teams are messy. Occasionally somebody loses their temper.

The objective isn’t to build a crew that never has a warp-core breach.

It’s to build a crew that knows how to repair the ship afterward.