Stop Killing Teams with Silent Conflict: Thomas-Kilmann for Engineering Teams
I’ve seen too many promising teams fall apart not because of code quality, but because of silent, unresolved conflict.
In our engineering community, arguments are part of daily life. If you’ve ever seen two developers argue over a variable name, you know what I mean.
But the real danger isn’t the argument — it’s when everyone stays silent and lets the resentment grow.
The Real Problem: Why "Silent" Conflict Kills Teams
In engineering, we obsess over technical debt and outdated services, but rarely talk about what sinks teams: unresolved, mostly unspoken conflict.
It’s not always the dramatic shouting matches; more often, it’s the slow build-up of unspoken tension and half-solved disagreements.
Why does this matter?
- Meetings become rituals, and only safe topics are allowed. The hard questions? Ignored for "next time."
- People stop pushing for better ideas. Sometimes it feels easier to let a questionable solution through than to risk yet another argument over naming conventions.
- Decisions get made in private chats. Suddenly, it’s "I thought you handled this..." and nobody did.
- The strongest contributors get exhausted - trust me, I’ve been there — dragging invisible weight nobody wants to acknowledge.
- What’s left is a team that’s afraid to challenge each other, and the business quietly loses speed and edge.
If you haven't seen this happen in your team yet, it’s only a matter of time.
The Approach: Thomas-Kilmann in Engineering Realities
Let's be real: TKI isn't some magic wand, nor does it replace basic team trust. However, it does provide a framework for understanding how we handle conflict - and, sometimes, how we avoid dealing with it altogether.
Engineering teams are often a perfect storm of priorities:
- Architects want scale.
- Devs want speed and simplicity.
- Tech leads get squeezed between business and technical debt.
- Product wants “faster, sooner, now.”
Sometimes, all it takes for a project to stall is two engineers digging in their heels over — yes, a variable name or a coding style.
TKI isn’t about “fixing people.”
It’s about being conscious: Am I competing because it matters, or just out of ego? Am I giving in because it’s right, or just because I’m tired of pushing?
Understanding the Thomas-Kilmann Strategies
The Thomas-Kilmann model defines five core conflict resolution strategies. Each has its time and place, and knowing how — and when — to use each is what separates a healthy team from a slow-motion train wreck.
1. Competition
What is it?
A direct, assertive approach. One side pushes hard for their solution, sometimes at the expense of others. This isn’t always about ego; sometimes, you need to make a tough call fast.
When to use:
- When time is critical and a decision must be made.
- When the issue is mission-critical for business or technical health.
- If you have the strongest expertise or evidence on the table.
Example:
A tech lead and an architect disagree on an architectural approach right before a big release. With minutes left, someone has to make the call.
Trade-offs:
- Fast decisions, clear direction.
- Can breed resentment or lower trust if used too often.
2. Collaboration
What is it?
Both sides openly work together to find a win-win solution. This is the gold standard — when you have the time and trust to do it right.
When to use:
- When both perspectives matter for long-term success.
- When stakes are high and creativity or alignment is needed.
- When building relationships is as important as solving the problem.
Example:
Developers and product managers can’t agree on feature scope. Instead of forcing a decision, they run a joint workshop to align goals.
Trade-offs:
- High-quality outcomes, stronger relationships.
- Takes time and energy — sometimes too much.
3. Compromise
What is it?
Meeting in the middle. Both sides give up something to reach a quick, workable agreement — not perfect, but better than a stalemate.
When to use:
- When time is short and “perfect” isn’t possible.
- When both sides have equally valid positions.
- To prevent escalation or deadlock.
Example:
Dev and Ops can’t agree on release timing. They split the difference: some changes now, the rest next sprint.
Trade-offs:
- Faster than full consensus.
- Can leave everyone a little dissatisfied.
4. Accommodation
What is it?
One side yields to preserve harmony or because the issue just isn’t worth a fight. Sometimes, letting go is the best move.
When to use:
- When the issue matters more to the other side.
- To build goodwill or trust for the future.
- When you know your counterpart’s solution is genuinely better.
Example:
A developer trusts the senior architect’s call on tech stack—even if they’d do it differently.
Trade-offs:
- Builds relationships, keeps the peace.
- Repeated use can breed frustration or a lack of ownership.
5. Avoidance
What is it?
Kicking the can down the road — delaying or sidestepping the issue. Sometimes, this is wisdom; sometimes, it just buries a time bomb.
When to use:
- When the issue is minor or not worth the friction.
- When emotions run too high and a pause is needed.
- If you need more information to act.
Example:
The team puts off a tooling debate until after a major release, when there’s more headspace.
Trade-offs:
- Can prevent unnecessary drama.
- Unresolved issues may fester and become bigger problems.
Bottom line:
There’s no universal “best” style. Mastery is in knowing when to compete, when to collaborate, and—most importantly—when to shut up and listen.
TKI Matrix: Visualizing Choices
No one size fits all. Some days you fight for the architecture, some days you let it slide for a quick win. Maturity is knowing the difference.
Practical Examples: What Does Each Tactic Look Like?
Competition
- “Technical debt is too risky. I insist we review this decision.”
- “No time for experiments — let’s stick to proven solutions.”
Collaboration
- “Let’s run a short workshop and hear all perspectives. We need to get this right.”
- “There are risks on both sides. Can we map out the pros and cons and choose objectively?”
Compromise
- “Let’s implement the basic version for now, and revisit extra features post-release.”
- “What if we combine parts of your approach and mine, so we meet the deadline?”
Accommodation
- “You have more expertise here — I’ll trust your call.”
- “If this is critical for you, I’m willing to step back. Let’s keep the team moving.”
Avoidance
- “Let’s table this topic for next sprint; right now we need to focus on blockers.”
- “No point arguing until we have more data.”
Retrospective Checklist: Leveraging Conflict, Not Burying It
Honestly, if your retro never gets a little awkward, you’re probably not digging deep enough.
1. Diagnosis
- Did we have any visible or hidden conflicts this sprint?
- Was everyone involved in discussions, or did we slip into passive agreement?
2. Analysis
- Which tactics did we use (competition, compromise, avoidance, etc.)?
- Why did we pick those approaches?
- What was the impact on results and team mood?
3. Effectiveness
- What helped resolve the conflict?
- Where did we lack openness or constructive debate?
- Did anything affect team trust or dynamics?
4. Lessons and Agreements
- Which tactics should we try next time?
- Who can facilitate tough discussions?
- What new rules or rituals do we need for surfacing disagreements early?
Case Study: Rolling Out a New Deployment System
Situation:
DevOps wants a shiny new deployment tool. Backend engineers are skeptical, seeing only risk and churn.
- Competition: DevOps says, “We migrate on Monday. Decision is final.” Risk: Trust collapses, passive sabotage follows.
- Accommodation: Backend says yes but quietly grumbles. Risk: Quality drops, mistakes multiply.
- Compromise: Pilot on one team, feedback loop. Benefit: Less pain, more buy-in.
- Collaboration: Joint PoC and demo. Benefit: Real engagement, shared pride in the result.
- Avoidance: Decision postponed—nobody’s happy, and the mess grows. Risk: Debt piles up, team culture sours.
How to Embed TKI in Your Team Culture
- Host a workshop (use your own war stories—yes, even the ones that still sting).
- Make conflict a regular retro topic—not just a “post-mortem” after disaster.
- Let someone other than the boss facilitate hot debates.
- Normalize open post-mortems—mistakes are for learning, not blaming.
- Regular 1:1s: Sometimes, the real story only comes out in private.
Common Pitfalls and How to Avoid Them
Even with the best intentions, applying TKI can backfire if you ignore the messiness of real teams.
1. False Agreement
Teams “agree” to try TKI, but don’t change anything.
Retros look good on paper, but real problems remain untouched.
How to avoid:
Name the avoidance. Make awkward silence a reason to pause and dig in.
2. Going Through the Motions
Facilitators and checklists everywhere—but nobody’s talking.
It’s easy to “do” TKI and never feel a thing.
How to avoid:
Stay practical. Root every discussion in real, recent events.
3. Change Resistance
“Yet another HR thing? Pass.”
If senior engineers aren’t bought in, nothing moves.
How to avoid:
Start with a pain point that everyone recognizes. Show a quick win.
4. Lack of Psychological Safety
Without trust, feedback feels personal and unsafe.
People go on defense, and nothing improves.
How to avoid:
Build safety intentionally. Separate the person from the problem—every time.
5. Ignoring Context
One tactic for everything? Guaranteed failure.
What works in a startup fails in a legacy enterprise.
How to avoid:
Train judgment, not just process. TKI is a toolkit, not a recipe.
6. No Feedback Loop
No follow-up = no learning.
Teams repeat the same mistakes.
How to avoid:
Retro your retro. Yes, really.
Takeaways
- Conflict isn’t the enemy. Silence is.
- If you want a resilient, high-performing team, normalize tough conversations.
- TKI is a tool, not a cure-all. Use it consciously.
- And if you’ve ever seen two developers argue over a variable name, you know: sometimes, it’s the little things that matter most.
How does your team handle conflict? Have you seen a “hard” stance pay off, or was collaboration the real game changer? Drop your stories below — I’ll share mine if you share yours.
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.