My coworker gave a short tech talk today not about Kotlin or CI pipelines, but about Nonviolent Communication. And it hit me. Hard.
Because conflict in teams is one of those things we all quietly struggle with. No matter how good the tech stack is, no matter how clean the architecture once communication breaks down, everything else starts to rot.
You’ve seen it before: a small disagreement turns into a cold silence. A code review starts feeling personal. A team that used to brainstorm freely suddenly just plays it safe.
That talk made me realize something uncomfortable but true:
“We spend our days debugging systems, yet we rarely stop to debug how we talk to each other.”
The Real Cost of Conflict
Conflict doesn’t start loud it starts quiet. It starts with a sigh on workspace chats. A “fine, I’ll do it myself.” A meeting where someone clearly wants to say something but doesn’t.
In engineering teams, these tiny moments stack up like unhandled exceptions. One unspoken frustration becomes two, then five, and before you know it, your high-performing team starts feeling like a collection of isolated freelancers.
“When engineers stop talking honestly, teams don’t just lose velocity, they lose safety.”
And the scary thing? You can still ship features while your team is quietly falling apart. That’s what makes communication breakdowns so dangerous they don’t show up in metrics. You’ll still hit sprint goals, still merge PRs, still deliver builds. But underneath, trust is decaying.
Soon, feedback feels like an attack. Architecture discussions turn into turf wars. The best people stop speaking up because it’s easier to stay quiet than to be misunderstood.
And once that happens, even the cleanest codebase can’t save the culture.
Discovering Nonviolent Communication
At its core, NVC is simple: it’s a way of talking that separates what happened from how we feel about it, and what we need from what we demand.
It’s built on four small but surprisingly powerful steps:
- Observation: describe what you see without judgment.
- Feeling: name how it makes you feel.
- Need: express the value or need behind that feeling.
- Request: ask for a concrete action, not a threat or demand.
Sounds easy, right? It’s not. Because our brains are wired to judge before we understand.
“We’re quick to debug code, but slow to debug assumptions.”
Imagine a typical code review comment:
“You didn’t follow the architecture guidelines.”
Now, apply a bit of NVC thinking:
“I noticed the implementation doesn’t follow our shared architecture guideline. I feel concerned because consistency helps us maintain long-term readability. Could we revisit this approach together?”
The difference isn’t just tone it’s intent. One message points a finger; the other opens a door.
NVC doesn’t mean avoiding hard feedback or sugarcoating problems. It’s about removing unnecessary violence, the subtle edge in our words that turns collaboration into conflict.
And just like writing clean code, clarity here takes effort. The cleaner you express what you observe and need, the easier it is for others to understand your intent without defensiveness.
Don’t Debug People in Public
One of the hardest lessons I’ve learned in engineering teams is that how you deliver feedback matters as much as what you’re saying.
When feedback turns into a group event a thread, a meeting callout, or a “let’s all discuss this one person’s decision” moment it stops being about learning. It starts feeling like exposure.
Public criticism, even if technically correct, lands like a personal attack.
The person on the receiving end doesn’t hear your logic they hear the message beneath it: “You don’t belong here.”
“Once feedback feels like comparison, the goal shifts from improvement to survival.”
Nonviolent Communication teaches the opposite approach: empathy scales best one-on-one.
Pull someone aside. Ask questions instead of assigning blame. Listen for intent before judging execution.
Private space turns feedback from humiliation into dialogue. That’s where understanding lives and understanding is what keeps teams together.
The Consequences of Ignoring This
The thing about communication bugs is that they don’t crash immediately. They degrade slowly, like memory leaks in culture.
Teams that don’t talk stop trusting.
Teams that don’t trust stop collaborating.
And teams that stop collaborating start quietly dying, even while the sprint board looks perfectly healthy.
You start hearing phrases like, “Let’s just do it this way,” instead of, “What if we tried this?” Decisions become political. Feedback becomes personal. And brilliant engineers start looking for new jobs, not because of the tech, but because of the tone.
“You can fix bad code. You can’t fix a team that’s stopped talking.”
Debugging Ourselves
The more I think about it, the more it’s clear: most “technical” problems aren’t about code, they’re about people.
Nonviolent Communication is basically clean code for conversations. When words get messy, intent gets lost.
Small rewrites go a long way:
- “You should’ve known” → “I wish we’d talked earlier.”
- “That’s wrong” → “Can you walk me through your thinking?”
Same message, totally different vibe.
Conflict isn’t bad. Avoiding it is.
Good teams argue they just do it safely.
So next time things get tense, pause and ask yourself:
“What do I really feel, and how can I say it without blame?”
That little pause? It’s like linting your words before pushing them to prod.
References
Marshall Rosenberg’s Nonviolent Communication book
📚 Originally published on Medium.
💬 I also share free mentoring sessions on ADPList.
🚀 Let’s connect and talk about Android, Kotlin, and building great systems together!
Top comments (0)