Dealing with Condescension & Public Over-Explaining¶

Most engineers have worked with someone who answers a simple question with a lecture, explains things nobody asked about, corrects small mistakes in a public channel instead of a DM, or opens with "Well, actually…". Often it's a style problem: tiring but harmless. Sometimes it's targeted. It's aimed at specific people, it gets worse when challenged, and over time it builds a story about the target that management starts to believe.

This guide covers both. It explains why people behave this way, how to tell an annoying habit from a campaign, and how to protect yourself before the story about you becomes the official one.

Part 1: What the behaviour looks like¶

The pattern usually shows up as some mix of:

• Explaining past the question. Asked "which port does the service listen on?", they explain TCP, the service's history, and why the old port was wrong.
• Explaining things the audience already knows. Walking a senior SRE through what kubectl get pods does.
• Correcting in public what could be fixed in private. A typo, a naming nit, or a minor inaccuracy called out in a team channel or PR thread with a large audience.
• Tone markers. "Obviously…", "As I've said before…", "It's actually pretty simple…", "Just do X."
• Re-explaining someone else's correct answer. Someone answers correctly, and they repeat it at greater length as if it hadn't been answered.
• Answering questions that weren't directed at them, especially in front of leadership or a wide audience.

Two separate things are often tangled together:

Someone can over-explain without being condescending, because they explain everything to everyone. And someone can be condescending in very few words.

Part 2: Why people do it¶

Several of these can apply to the same person at once, and none of them can be confirmed from the outside. They are useful for deciding how to respond, not for labelling anyone.

1. Insecurity and status anxiety¶

• Competence as identity. If someone's sense of worth is tied to being "the one who knows," every question is a chance to prove it, and every gap in someone else's knowledge is a chance to rank above them.
• Performing for an audience. Over-explaining in front of managers or senior engineers can be an attempt to be seen as the expert, not just to help.
• Impostor feelings. People who privately fear they aren't good enough sometimes over-compensate with exhaustive, unassailable answers.
• Insecure workplaces amplify it. Layoff fears, stack ranking, and cultures that reward "visibility" all push people toward performing knowledge in public. They also push people toward making someone else look worse.

A tell for this driver: it gets noticeably worse when someone senior is watching.

2. The curse of knowledge¶

Once you understand something deeply, it's hard to imagine not knowing it. Economists Colin Camerer, George Loewenstein, and Martin Weber named this the curse of knowledge in 1989. Some experts under-explain because of it. Others, having been burned, over-correct and explain everything from first principles to everyone. The condescending feel comes from mis-calibrating the audience, not from contempt.

3. Habits learned in previous roles¶

Support, teaching, and audit-heavy jobs train people to assume zero context and write everything down completely. Roles where people were blamed for failures teach "put every caveat in writing, in public, so it's on record." Some public over-explaining is defensive documentation: the thread is a paper trail, not an answer.

4. Anxiety about being misunderstood¶

Some people over-explain because being misunderstood has gone badly for them before. They pile on caveats to pre-empt every misreading. It tends to come across as anxious rather than superior.

5. Cultural and linguistic communication styles¶

Low-context communicators, who spell everything out, can seem patronising to high-context listeners, who expect much to be implied. People working in a second language sometimes over-explain to be sure they're understood. Gendered patterns are well documented too: "mansplaining" grew out of Rebecca Solnit's 2008 essay Men Explain Things to Me. If the behaviour is consistently aimed at one group of people, see Addressing Double Standards.

6. Overconfidence¶

Some people overestimate their competence relative to others, and act like the most knowledgeable person in the room. The popular version of the Dunning–Kruger effect overstates the research. The narrower point holds: people are often poor judges of their own relative competence.

7. Contempt, rivalry, or a need to dominate¶

Sometimes it is exactly what it looks like. Some people use condescension deliberately to establish hierarchy, undermine a rival, or push someone out. This is the case that does real career damage, and it gets its own section below.

Part 3: Style problem or targeting?¶

The single most important question is whether this person treats everyone this way or you (or a small group) this way.

If the right-hand column looks familiar, stop treating it as a communication quirk. Treat it as a risk to your job.

Part 4: How targeting turns into a firing¶

Targeted condescension is effective because it doesn't look like an attack. Each incident is small and defensible: "I was just correcting an error." "I was just explaining." The damage comes from accumulation:

1. Public corrections create a visible record. Management sees you being corrected, repeatedly, in public. They don't see the context, the triviality, or that others make the same mistakes without comment.
2. Repetition turns perception into "fact." After enough threads, "their work needs a lot of correcting" stops being an impression and starts being something people know.
3. Confidence reads as competence. The person doing it is usually articulate, visible, and sure of themselves. Managers often default to trusting the confident voice, especially in areas they can't evaluate technically.
4. The back-channel fills in the gaps. Public condescension is often paired with private conversations with your manager ("I'm worried about X's work"). You never see these, so you can't rebut them.
5. Pushing back gets reframed. When the target finally objects, it looks like defensiveness, "communication issues," or "not taking feedback well." The target becomes the conflict.
6. Management picks the low-friction option. Defending the target means confronting the confident, well-connected person. Agreeing with them is easier. Vague feedback appears ("concerns about collaboration"), then a performance plan or a "restructuring."

The common thread: the target loses because the other side's story was told first, often, and to the right people, not because it was true. Most of the protection below comes down to making sure your story is also told, early, in writing, to those same people.

Case study: a reasonable question reframed as incompetence¶

An illustrative example of how this plays out:

An engineer notices that a production setting doesn't match the team's runbook: the runbook says one value, the live config says another. The system's owner is out of office, and the engineer hasn't worked on that part of the platform recently. Rather than change something they don't own, they post in the team channel asking whether the value was changed on purpose.

A colleague replies with a long, impatient walkthrough of how the configuration system works, in a tone that implies anyone on the team should already know all of it. The actual question, whether the value is intentional, goes unanswered.

Later, in a performance review, that thread is cited as evidence the engineer doesn't understand the platform. Some time after that, someone else quietly corrects the setting to match the runbook.

What this shows:

• The question was correct. The mismatch was real, as the later fix confirms. Checking before changing something you don't own is good practice, not a skills gap.
• The over-explanation dodged the actual question. A one-line answer ("no, that's wrong, it should be X") would have resolved it. The lecture changed the subject from the problem to the engineer's knowledge.
• The record kept the lecture, not the outcome. The review captured the condescending exchange as a performance concern. It didn't capture that the underlying issue was real and later fixed.
• Context disappeared. The owner's absence, the engineer's distance from that area, and the fact that asking was the cautious choice were all missing by the time it reached the review.

The lesson isn't "don't ask questions." It's to ask them in a way that leaves your reasoning on the record, and to note it when the issue you raised turns out to be real (see Part 6).

Part 5: Early warning signs¶

Watch for these. One is noise; several together are a pattern.

• Your mistakes are discussed in public channels while equivalent ones from others aren't.
• Your manager starts repeating their framing, sometimes their exact words.
• Good-faith questions you asked show up later as evidence that you don't know your job.
• 1:1s shift tone. They become shorter, more formal, or focused on "concerns" without examples.
• Feedback becomes vague and character-based: "communication," "attitude," "collaboration," "culture fit," instead of specific deliverables.
• You're asked to "work on your relationship with X," as if the problem were mutual.
• You're left out of meetings, decisions, or threads you'd normally be in.
• Scrutiny of your work increases suddenly with no change in the work.
• Your wins go unmentioned, or get credited elsewhere.
• HR appears in a conversation that started as "feedback."
• A performance improvement plan (PIP) appears. Treat it as a serious warning, not a coaching exercise. In many organisations it's the paperwork that comes before an exit.

Part 6: Protecting yourself¶

1. Document from the first incident, not the fifth¶

Most people start documenting only after they realise it's serious. By then the most useful evidence, the early pattern, is gone.

• Keep contemporaneous notes: date, time, channel or meeting, what was said (exact words if possible), who saw it, and the impact.
• Note comparisons: "Same kind of typo by Y in #platform on the 14th, no comment."
• Keep notes about your own experience somewhere you'll still have access to if you lose your work account. Don't copy confidential company data, code, or other people's private information off company systems. That can be used against you. Your own dated notes are fine; screenshots of company systems are a policy question to check first.
• Stick to observable behaviour. "Corrected my variable name in a 40-person channel" is evidence. "He's trying to get me fired" is a conclusion; keep those out of the record.

2. Keep a record of your wins¶

Keep a running "brag doc": projects delivered, incidents resolved, metrics improved, and praise from peers, stakeholders, or customers (save the messages). When a narrative says your work is weak, a dated list of results is the strongest counter, and you don't want to be reconstructing it from memory under pressure.

3. Put verbal conversations in writing¶

After any meaningful conversation with your manager, especially one with feedback, send a short follow-up:

"Thanks for the chat today. To confirm what we discussed: you'd like X by Friday, and the concern about Y relates to the deploy on the 12th. Let me know if I've missed anything."

This creates a record, forces vague feedback to become specific, and makes it harder for the story to quietly change later.

4. Make your work visible directly to management¶

Don't let your work reach your manager filtered through the other person. Send short regular updates to your manager. Keep your skip-level aware of what you're delivering. Present your own work in demos and reviews. The goal is that your manager's picture of you comes mostly from you.

5. Respond to public corrections once, briefly, with facts¶

Don't let a misleading public correction stand, and don't get into a public fight either:

• If it's wrong: one factual reply, with evidence. "This was intentional. See the design doc, section 3."
• If it's right but trivial: "Fixed, thanks." Nothing more. Don't let it become a thread.
• If it's a pattern: move the conversation private and keep a note of it.

Calm, short, factual replies make the contrast between you and the other person visible to everyone reading.

6. Ask questions in writing, with your reasoning attached¶

When a question could later be framed as not knowing your job, put the context in the question itself:

"The log retention on the production cluster is set to 7 days, but the runbook says 30. I haven't worked on logging in a while and [owner] is out this week, so checking before I change anything: was this intentional?"

That one message records what you noticed, why you're asking instead of acting, and who would normally answer. It's much harder to present as incompetence later. Then close the loop: when the issue you raised turns out to be real, note the date it was fixed and who fixed it. That's the piece most likely to go missing from someone else's version of events.

7. Raise it with your manager early, framed as impact¶

Bring it up before the story is set, and do it in writing or follow up in writing. Frame it as impact on the work rather than a personality complaint:

"I want to flag a pattern. Over the last month, minor issues in my PRs have been raised in #platform rather than in the review, three times (dates attached). Other people's similar issues are handled in review. It's affecting how my work is perceived, and I'd like your help making sure feedback goes through normal channels."

This puts the pattern on record, with dates, before you're the one under scrutiny. If things go badly later, a record showing you raised it early matters a lot.

8. Demand specifics on vague feedback¶

When feedback is vague, ask, politely and in writing, for examples and measurable expectations: "Can you give me a recent example of the collaboration concern, and what would good look like by next month?" Feedback you can't act on can't be fairly assessed. A pattern of vague feedback in writing is itself evidence.

9. Build allies and witnesses¶

Targeting works best in isolation. Keep good working relationships across teams, help people, and be someone others have seen do good work. People who have watched incidents happen may later be willing to describe what they saw. Don't recruit people into a campaign, though; just don't be alone.

10. Know what HR is, and use it anyway when needed¶

HR's job is to protect the organisation. That doesn't make it useless: a formal written complaint creates a record the organisation can't later say it didn't know about. Many jurisdictions require employers to have a workplace harassment policy and to investigate complaints. Ontario's Occupational Health and Safety Act, for example, defines workplace harassment roughly as a course of vexatious comment or conduct that is known, or ought reasonably to be known, to be unwelcome. A sustained pattern of targeted public belittling can fit that kind of definition. Read your employer's policy before you need it.

11. Get legal advice early, not after¶

If a PIP, a "final warning," a demotion, or termination talk appears, talk to an employment lawyer before you sign anything, including a severance agreement or release. Many offer low-cost or free initial consultations. Rights to notice, severance, and wrongful or constructive dismissal claims vary by jurisdiction, and timelines to act are limited. (This is general information, not legal advice.)

12. Decide when to leave on your own terms¶

Sometimes, when management has fully bought in, the only win available is leaving before you're pushed, with references, savings, and a job lined up. That isn't losing. Watch for the point where your manager stops being persuadable, and start your search before the PIP, not after.

Part 7: Choosing your next team¶

The best protection is not joining a team where this works. In interviews, ask questions that show how conflict and feedback are handled:

• "How does the team give feedback on code: in reviews, in channels, in meetings?"
• "Tell me about a recent disagreement between two engineers. How did it get resolved?"
• "How does the manager find out how someone's work is going: from them, or from others?"
• "What happened the last time someone on the team was struggling?"
• "Why did the last person in this role leave?"

Watch for red flags. An interviewer might correct a peer condescendingly in front of you. Answers about conflict might be vague, or might blame "personalities." The manager might describe team members by reputation rather than by work. Where you can, talk to people who used to work on the team; they'll be more candid than anyone currently there.

After being burned once, it's easy to see targeting everywhere. Use the signal table in Part 3. One curt comment is a bad day. A pattern aimed at you, getting worse, with an audience, is a pattern.

Part 8: Checking yourself¶

Run the same lens on your own communication:

• Did I answer the question that was asked?
• Does this correction need an audience?
• Would I write this the same way if nobody senior were reading?
• Am I adding context because it helps them, or because it protects me?

A good default: lead with the short answer, offer the long one. "Port 8443. Happy to explain why it moved if useful."

Quick reference¶