Thomas-Kilmann Conflict Mode

The Five Fights You Keep Having

I once watched a team of eight engineers sit through an entire retrospective without a single disagreement. Not one raised eyebrow, not one “actually, I see it differently,” not one moment of productive tension. They smiled. They nodded. They wrote safe action items on sticky notes. And then they walked out and had the real conversation in the hallway.

Afterward, their Scrum Master - a sharp, experienced coach named Dana - turned to me and said, “I know they’re avoiding. I just don’t know how to name it in a way that doesn’t make me sound like the person who starts fights.”

That’s the problem with conflict. We treat it as a single thing - something you’re either “good at” or “bad at.” But conflict isn’t one thing. It’s five things, arranged on two axes, and your default response is probably not the one the situation actually calls for.

Kenneth W. Thomas and Ralph H. Kilmann figured this out in 1974 when they published the Thomas-Kilmann Conflict Mode Instrument - usually just called the TKI. Thomas was at UCLA, Kilmann at the University of Pittsburgh, and together they built on Robert Blake and Jane Mouton’s managerial grid to create something elegantly specific: a model that maps five conflict-handling modes onto two dimensions. Assertiveness - how much you try to satisfy your own concerns. And cooperativeness - how much you try to satisfy the other person’s.

The TKI didn’t claim any mode was inherently good or bad. Most conflict advice boils down to “collaborate more” or “stop being so aggressive.” Thomas and Kilmann said something more nuanced: every mode has situations where it’s the appropriate choice, and every mode has situations where it’s exactly wrong. The skill isn’t learning to always collaborate. It’s reading the situation and choosing the right mode.

For agile coaches, this is gold. Because the conflict patterns on your teams aren’t random - they’re predictable, they’re diagnosable, and with the right vocabulary, they’re coachable.

Two Axes, Five Modes, No Villains

The TKI model sits on a simple grid. The vertical axis is assertiveness - how strongly you pursue your own position. The horizontal axis is cooperativeness - how much effort you put into satisfying the other person’s concerns. Every conflict response lands somewhere on that grid, and the five modes occupy distinct positions.

Here’s the thing: most people have one or two modes they reach for by reflex and one or two they almost never use. That’s not a character flaw - it’s a habit. And habits can be expanded once you see them clearly.

Competing (High Assertiveness, Low Cooperativeness)

Top-left corner of the grid. You pursue your position at the other person’s expense. Win-lose. Power play. My way.

Before you recoil - competing is sometimes exactly right.

When there’s a production outage and someone needs to make a call in thirty seconds, you don’t want collaboration. You want the person with the most context to say “We’re rolling back, right now, no discussion.” When an ethical boundary is being crossed - a stakeholder pushing to ship something that violates user privacy - competing is the appropriate mode. You’re not being difficult. You’re being correct.

Competing gets toxic when it becomes the default. The tech lead who treats every architectural discussion as a battle to be won. The product owner who overrides estimates because “I know what this takes.” These are people who’ve confused assertiveness with leadership, and they create teams that stop bringing ideas to the table.

In my classes, I describe competing as the fire extinguisher behind glass. You want it available. You don’t want someone using it on every candle.

The tell that someone over-uses competing: other people have stopped disagreeing with them. Not because they’ve been convinced - because they’ve been exhausted.

Accommodating (Low Assertiveness, High Cooperativeness)

Bottom-right corner. The mirror image of competing. You set aside your own concerns to satisfy the other person’s. You yield. You smooth things over. You say “That’s fine, let’s go with your approach.”

Accommodating is generous when it’s chosen. When a teammate cares deeply about a decision and you genuinely don’t have a strong preference, accommodating is efficient and kind. When you realize mid-argument that the other person is simply right, switching to accommodation isn’t weakness - it’s intellectual honesty.

Accommodating becomes a problem when it’s compulsive. The team member who always defers, always agrees, always volunteers to take the less interesting story. Over time, compulsive accommodators build up resentment - and one day the accumulated frustration leaks out sideways in passive-aggressive comments or the quiet decision to start looking for another team.

Watch for the accommodation trap in junior team members. A new developer who accommodates every senior engineer’s opinion isn’t learning collaboration - they’re learning silence. If your team’s juniors never push back, you don’t have a healthy team. You have a hierarchy wearing a flat-org costume.

Avoiding (Low Assertiveness, Low Cooperativeness)

Bottom-left corner. Neither assertive nor cooperative. You sidestep the conflict entirely. Change the subject. Miss the meeting. Say “Let’s take this offline” and then never take it offline.

Here’s where it gets interesting for agile coaches: avoiding is the dominant conflict mode in most tech teams I’ve worked with. Not all - but most. (Because of course it is.)

Engineers are often selected for analytical thinking, not interpersonal confrontation. Many team cultures reward “keeping the peace” and punish visible disagreement. Remote work makes it even easier - just respond with a thumbs-up emoji and move on.

Avoiding has legitimate uses. When the issue is trivial. When emotions are so hot that engaging now would be destructive. When you need time to gather information before responding.

But chronic avoidance is the silent killer of team performance. Retros with surface-level observations. Sprint planning where nobody challenges the overstuffed backlog. One-on-ones where the hard feedback never lands. The conflict doesn’t go away - it goes underground, where it ferments into something worse.

If you’re an agile coach and you can only remember one thing about the TKI model, remember this: when a team looks peaceful but performs poorly, check for avoidance. The absence of visible conflict is not the same as the presence of alignment.

Compromising (Moderate Assertiveness, Moderate Cooperativeness)

Dead center of the grid. Both parties give up something, both parties get something. Split the difference. Meet in the middle. You want to release on Thursday, I want to release on Tuesday - we’ll release on Wednesday.

Compromise is the mode that sounds the most reasonable, which is exactly why it’s overused. It feels fair. It feels mature. It feels like something adults do.

And sometimes it’s the worst possible outcome.

When two engineers disagree about architecture - one wants microservices, the other wants a modular monolith - compromising gives you a hybrid with the downsides of both and the advantages of neither. Some problems don’t have a middle. They have a right answer that requires the courage to argue it out.

Compromise works when the stakes are moderate and time pressure is real. Splitting a meeting timeslot. Dividing scope between two teams. Deciding how many story points to pull into a sprint.

Compromise is a fine tactic and a terrible strategy. Teams that compromise habitually produce mediocre outcomes - not because the people are mediocre, but because they keep splitting differences instead of finding better solutions.

Collaborating (High Assertiveness, High Cooperativeness)

Top-right corner. The unicorn mode. Both parties fully assert their concerns AND fully try to satisfy the other’s. The goal is to find a solution that makes everyone genuinely happy - not a watered-down compromise, but a creative outcome that satisfies both sets of concerns.

Collaboration sounds wonderful. And when it works, it is wonderful. Two developers who disagree about implementation dig into each other’s reasoning, discover their concerns aren’t actually in conflict, and design a solution that addresses both. Better outcomes than either original position.

Here’s why it’s not always the right mode: collaboration is expensive. It takes time, energy, emotional bandwidth, and genuine skill. Collaborating on which conference room to use for the demo is a waste of everyone’s attention.

Collaboration requires trust. You can’t dig into underlying interests with someone you don’t feel safe around. This is why the TKI pairs so well with Lencioni’s Five Dysfunctions - fear of conflict (Dysfunction #2) makes genuine collaboration nearly impossible, and without vulnerability-based trust (Dysfunction #1), teams default to avoiding or compromising long before they reach collaborating.

The teams I’ve seen do collaboration well have something in common: they know when NOT to collaborate. They can say “This is a competing situation, make the call” or “This is a compromise situation, split the difference and move on.” Knowing when collaboration is worth the investment is half the skill.

What This Changes About Your Coaching

Reading the Room in Real Time

Once you internalize the five modes, retrospectives look completely different. You start seeing the conflict patterns instead of just the content.

The developer who always says “Whatever the team decides” in planning? Accommodating. The architect who defends every technical decision as if their identity depends on it? Competing. The product owner who tables every controversial topic for “further discussion”? Avoiding. The Scrum Master who proposes splitting every disagreement down the middle? Compromising.

None of these people are doing anything wrong, per se. But if the team’s dominant mode is avoiding - and it usually is - you’ll get complaints about the build pipeline and silence about the fact that the PO changes priorities every other day.

Your job as a coach isn’t to force collaboration. It’s to help the team recognize which mode they’re in and ask whether it’s the right one for this situation.

A question I use constantly: “Are we avoiding this, or have we genuinely decided it’s not worth discussing?” The distinction matters. One is a conscious choice. The other is a reflex.

Running the TKI as a Team Activity

The TKI is an actual assessment - a thirty-question forced-choice questionnaire that identifies your dominant and backup conflict modes. Published by Kilmann Diagnostics, it takes about fifteen minutes.

I’ve run it with dozens of teams. Here’s the pattern I see most often in software teams: the dominant mode is Avoiding, with Compromising a close second. Competing and Collaborating are least-used. Accommodating varies wildly by individual.

When a team sees their collective profile, light bulbs go on. “Oh. We’re ALL avoiding the hard conversations.” That awareness alone is worth the exercise.

The debrief matters more than the scores. I ask three questions:

1. “What conflicts have we been avoiding that we should engage with?”
2. “Where have we been compromising when we should have been collaborating?”
3. “What’s one situation where competing - someone just making the call - would actually help us move faster?”

That third question usually gets nervous laughter. But it opens up an important conversation about when directive behavior is actually a gift to the team.

Expanding the Repertoire

The real coaching goal with the TKI isn’t to get everyone collaborating all the time. It’s to help individuals and teams expand their range.

A developer who only competes needs to learn when accommodation builds goodwill. A product owner who only avoids needs to practice competing when a stakeholder pushes scope that will break the sprint. A Scrum Master who only compromises needs to learn that some conflicts deserve full collaboration.

I frame it like this in coaching sessions: you want a full toolbox, not a favorite hammer. Every mode is a tool. The problem is never the tool itself - it’s reaching for the same one every time regardless of the situation.

Cross-Soniaking to Fear of Conflict

If you’ve worked with Lencioni’s Five Dysfunctions model, you already know that fear of conflict is the second dysfunction - built on the absence of trust. The TKI gives you a more granular lens on that dysfunction.

A team stuck in Dysfunction #2 isn’t just “afraid of conflict.” They’re stuck in a specific mode. Some are chronic avoiders - they don’t engage. Others are chronic accommodators - they engage but immediately defer. Others are chronic compromisers - they engage but refuse to advocate fully for any position.

Knowing which pattern your team uses tells you which intervention to try. Chronic avoiders need structured conflict baked into ceremonies. Chronic accommodators need explicit permission (and modeling) that pushback is valued. Chronic compromisers need to experience genuine collaboration at least once so they can feel the difference between “split the difference” and “found something better than either original idea.”

What It Looks Like in the Room

Maya had been a Scrum Master at a mid-size SaaS company for two years when her content platform team started showing symptoms she couldn’t quite name. Seven engineers, a designer, and a product owner named Andre - responsible for the CMS powering the company’s customer-facing help center.

The team shipped reliably. Velocity was stable. On paper, everything looked fine.

But the retros had gone flat. Every two weeks, the team surfaced the same category of issue: tooling friction, minor process tweaks, “we should document X better.” Safe topics. Useful, sure, but nothing that explained the growing tension Maya could feel in refinement sessions.

The tension lived between two senior engineers - Tomás and Sonia. Tomás had been on the team since day one and had strong opinions about the content rendering pipeline he’d built. Sonia had joined six months ago from a startup where she’d built a similar system at twice the scale, and she had strong opinions about where the architecture was going to break.

Neither said any of this out loud.

In refinement, when a story touched the rendering pipeline, Tomás would explain his design rationale at length. Sonia would nod, ask a technical question or two, and then quietly write the code however she thought it should be written. Tomás would catch this in code review and leave pointed comments. Sonia would change most of it back without discussion. After three sprints of this, Andre said to Maya, “Something’s off and I can’t tell if it’s a tech problem or a people problem.”

It was a conflict problem. And nobody was having it.

Maya recognized the TKI pattern immediately. Tomás was competing - defending his architecture as if questioning it was questioning him personally. Sonia was avoiding - routing around the disagreement through code. The rest of the team was accommodating - letting the unspoken tension set the tone for every technical discussion.

She decided to name the pattern.

At the next retro, she put the TKI grid on the screen. Five minutes explaining the five modes - no jargon, just descriptions and examples. Then she asked each person to privately write down which mode they thought the team used most in technical disagreements.

Seven of nine people wrote “Avoiding.”

(Tomás wrote “Collaborating.” Sonia wrote “Competing.” Both were describing the other person, not themselves. Classic.)

That cracked it open. Andre asked the question nobody had asked: “Tomás, Sonia - you clearly see the rendering pipeline differently. Can we actually have that conversation right now?”

What followed was forty minutes of genuine technical debate. Tomás explained the tradeoff decisions he’d made when the system was smaller. Sonia explained the scaling problems she’d seen at her previous company. They argued. They drew diagrams. At one point Tomás said, “I hadn’t thought about it that way,” and the room visibly exhaled.

They didn’t resolve it that day. But they designed a two-sprint experiment - implement Sonia’s proposed caching layer alongside the existing one, run both in shadow mode, let the data decide. That was collaboration - not splitting the difference, but finding a path that let evidence settle the debate.

Three weeks later, the data showed Sonia’s approach handled the load patterns better. Tomás reviewed the results, said “Well, the numbers don’t lie,” and they migrated the pipeline over the next sprint. No drama. No resentment. Just two experts who finally had the argument they should have had six months earlier.

At the retro after the migration shipped, Maya asked the team to revisit the TKI grid. “What mode did we use for this decision?”

Sonia smiled. “We finally collaborated.”

Tomás shrugged. “Took us long enough.”

The team laughed - the real kind, not the polite kind. And for the first time in months, the retro board had items on it that weren’t about tooling. The pattern was spreading.

That’s what happens when a team learns to name their conflict modes. The naming doesn’t fix anything by itself - but it makes the invisible visible. And once it’s visible, the team can choose a different one.

The Mode That’s Missing From Your Team

Most of the teams I coach don’t need less conflict. They need better conflict - the courage to compete when stakes are high, the patience to collaborate when the problem deserves it, the wisdom to accommodate when someone else has the better idea, and the honesty to notice when they’re avoiding something that needs to be said.

Thomas and Kilmann gave us a model that makes conflict legible. Not comfortable - legible. You can look at your team’s patterns and say, with specificity, “We over-index on avoiding and under-index on collaborating, and that’s why our retros feel stale.” That’s a coaching intervention you can actually work with.

The TKI takes fifteen minutes. The debrief takes an hour. The shift in how a team handles disagreement? That takes practice, patience, and a coach willing to name the pattern when nobody else will.

Your teams are already in conflict. The question is whether they’re handling it well - or just handling it quietly.

Go Deeper

• Thomas, K.W. & Kilmann, R.H. (1974). Thomas-Kilmann Conflict Mode Instrument. Xicom (now published by Kilmann Diagnostics). The original assessment. Thirty forced-choice items, fifteen minutes, remarkably durable after fifty years. Available at kilmanndiagnostics.com.

• Kilmann, R.H. (2021). Creating a Quantum Organization: The Whys and Hows of Implementing Eight Tracks for Long-Term Success. Kilmann Diagnostics. Kilmann’s later work integrating conflict management into broader organizational change - useful context for coaches working at the systems level.

• Thomas, K.W. (1992). “Conflict and Conflict Management: Reflections and Update.” Journal of Organizational Behavior, 13(3), 265-274. Thomas revisits the model eighteen years later with additional research on when each mode is most effective. The situational tables in this paper are worth the read alone.

• Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass. Fear of conflict is Dysfunction #2. Read alongside TKI for a complete picture of why teams avoid productive disagreement and what to do about it.

• Kilmann Diagnostics. kilmanndiagnostics.com. Ralph Kilmann’s site with the current TKI instrument, interpretive guides, and research updates.

The Thomas-Kilmann Conflict Mode Instrument is a registered trademark of Kilmann Diagnostics. Use of the model in this article is for educational purposes. This article is not affiliated with or endorsed by Kenneth W. Thomas, Ralph H. Kilmann, or Kilmann Diagnostics.