Diplomacy Is a Feature, Not a Bug

I was reviewing some data export files the other day when a colleague flagged a problem. One of the rows in a CSV file was misaligned — columns shifted, extra fields appearing where they shouldn’t. Classic data import headache.

It took about thirty seconds to find the root cause. An address field contained commas: Unit 4, Building 12, Rural Route 3. Our export had correctly wrapped it in double quotes — standard CSV quoting. Their import tool was splitting on every comma regardless of quoting.

Here’s what I actually wrote back:

Looking at the AddressLine1 column in the output, I see that column contains commas for the row you highlighted.

The actual row in the output file has all columns wrapped in quotes, so any decent parser would not confuse those embedded commas with column separators.

Did you catch it? “Any decent parser.” Three words that technically mean “a parser that correctly implements the CSV specification” but emotionally read as “your tool is bad and you should feel bad.”

I didn’t catch it at the time. I was focused on the facts — the data was valid, the quoting was correct, and the bug wasn’t on my side. All true. But truth doesn’t automatically equal tact.

The Reflex to Be Right

We’ve all been there. You’ve done the work, you’ve followed the spec, and someone tells you your output is broken when it isn’t. There’s a very human impulse to fire back with a correction — especially when the evidence is clear and the fix isn’t on your side.

But here’s the thing: being right and being helpful are not the same skill. One is a technical competency. The other is a professional one. The best engineers I’ve worked with are good at both.

What I Wish I’d Written

Looking back, I could have said the same thing without the edge:

The CSV is correctly quoted on our end. The import tool may need to be configured to handle quoted fields containing commas.

Same information. Same technical conclusion. But it frames the problem as a configuration detail rather than a competency gap. It gives the other team room to fix things without feeling like they’ve been called out.

Why This Matters More Than You Think

Early in my career, I thought good engineering was about writing clean code, optimizing queries, and knowing the right answer. And it is — partly. But the longer I’ve worked in this field, the more I’ve realized that how you communicate is as much a part of your craft as the code you write.

Consider what happens when you phrase feedback harshly:

Now consider what happens when you phrase the same feedback with a little care:

The ROI on diplomatic communication is enormous, and the cost is just a few extra seconds of thought before hitting send.

It’s Not About Being Soft

I want to be clear: diplomacy isn’t about avoiding hard truths or sugar-coating real problems. If there’s a bug, say there’s a bug. If a design is flawed, say it’s flawed. The point isn’t to be vague — it’s to be precise without being dismissive.

There’s a world of difference between:

“Any decent parser would not confuse those commas with column separators.”

and

“The import may need to be configured to handle quoted fields containing commas.”

The first one assigns blame. The second one describes a situation. They convey the same technical fact, but only one of them makes the other person want to work with you again.

A Simple Heuristic

Before sending a message to a colleague — especially one about a problem — I try to read it back and ask: If the roles were reversed, how would I feel reading this?

Not “would I be offended?” — most of us like to think we’re thick-skinned. But rather: Would I feel respected? Would I feel like this person is trying to solve the problem with me, or trying to win a point against me?

That small mental exercise has saved me from sending a lot of messages I would have regretted.

The Takeaway

Technical skill gets you in the room. Diplomatic communication keeps you there — and keeps the room functional. The next time you’re tempted to fire off a technically-correct-but-sharp reply, take a breath. Reword it. Keep the substance, soften the delivery.

Your colleagues will appreciate it. Your future self will too.

Because diplomacy isn’t a nice-to-have. It’s a feature — and a critical one at that.

How do you handle the balance between technical precision and professional diplomacy? I’d love to hear your stories especially the ones where you caught yourself just in time. Find me on Bluesky or LinkedIn, or drop a comment below.