Handling Difficult People
How to stay professional when people aren't.
TL;DR
- Stay factual — respond with timestamps, links, commits. Not emotion
- Document everything — emails > calls. Summarize every meeting in writing
- Redirect to solutions — "We can discuss what happened, or focus on fixing it. Which do you prefer?"
- Set boundaries early — scope, responsibilities, timelines in writing before work starts
- Don't match their energy — calm + factual wins every time
- Know when to escalate — 3+ documented incidents, personal attacks, or >5 hours/week spent managing one person
- Separate behavior from character — they're not a bad person, they have a bad pattern
This is the companion to Feedback & Difficult Conversations. That article covers giving feedback. This one covers handling difficult behavior directed at you.
The 5 Types
Not personality labels — behavior patterns. The same person can shift between types depending on the situation.
| Type | What They Do | What They Want | Your Move |
|---|---|---|---|
| The Blame-Shifter | Points fingers before investigating | To avoid accountability | Redirect to facts: "Let's look at the timeline together" |
| The Scope-Creeper | Changes the goal, then blames you for missing it | To get more without paying for it | Lock scope in writing: "Here's what we agreed to on March 3" |
| The Everything-Is-Urgent | Treats every request as P0 | Immediate attention, always | Force prioritization: "Which of these 3 should I do first?" |
| The 'I'm Not Technical' Shield | Uses ignorance to avoid accountability | To push decisions (and blame) onto you | Put choices in their language: "Option A costs $5K more but ships 2 weeks earlier" |
| The CC-Everybody Escalator | Loops in managers before talking to you directly | Pressure through visibility | Respond calmly to the thread, address the issue, then DM: "Happy to discuss directly next time" |
Core Playbook
1. Document Everything
Calls and hallway conversations don't exist unless they're in writing. People misremember. People also conveniently "forget."
The rule: If it's not written down, it didn't happen.
How to do it:
- After every call: send a summary email within 1 hour. "Per our call, we agreed to X, Y, Z. Let me know if I missed anything."
- Before starting work: confirm scope, timeline, and responsibilities in writing
- When requirements change: reply to the original thread with the delta. "Original scope was A. New request adds B and C. This moves the deadline from March 15 to April 1."
Bad:
Verbal agreement in a meeting. No follow-up. Scope changes mid-project. You get blamed.
Good:
Email after the kickoff: "Per today's meeting, scope is X. Timeline is March 15. DRI is Sarah for design, Alex for backend. Changes go through the shared doc." Changes happen — you reply with the paper trail.
2. Stay Factual
Emotion is ammunition. The moment you get defensive, frustrated, or sarcastic, the conversation shifts from the issue to your reaction.
The rule: Respond with timestamps, links, and facts. Never adjectives.
Bad:
"That's not fair — I worked really hard on this and you're not giving me credit."
Good:
"The feature shipped on March 3 (commit abc123). QA signed off on March 5 (Slack thread). The bug reported on March 10 is in a different module (JIRA-456)."
Bad:
"You keep changing the requirements!"
Good:
"Original spec (March 1) had 3 endpoints. On March 8, 2 more were added (email thread). On March 12, the auth flow changed (Slack message). Current scope is 5 endpoints + new auth. Original timeline assumed 3 endpoints."
Facts don't trigger defensiveness. Accusations do.
3. Redirect to Solutions
When someone is focused on blame, redirect to forward motion. You can't change what already happened — you can control what happens next.
The phrase:
"We can discuss what happened, or focus on how to fix it. Which do you prefer?"
This works because:
- It acknowledges the problem without accepting blame
- It gives them a choice (people calm down when they have options)
- It shifts from backward-looking to forward-looking
Bad:
"That's not my fault — the API was already broken when I got the ticket."
Good:
"The API is returning 500s on the
/usersendpoint. Here's my plan to fix it: [steps]. I can have it done by Thursday. Does that work?"
Bad:
Defending yourself for 3 paragraphs about why the delay wasn't your fault.
Good:
"We're 2 days behind. Here are 3 options to get back on track: [options]. Which do you prefer?"
4. Set Boundaries Early
Most difficult situations happen because expectations weren't set upfront. Ambiguity is where blame lives.
Before work starts, lock these in writing:
- Scope — exactly what's included (and what's not)
- Timeline — delivery date with assumptions listed
- Responsibilities — who owns what
- Change process — how scope changes get handled ("New requests go to the backlog and we re-estimate")
Bad:
"Sure, I'll build the dashboard." (No written scope. 6 weeks later: "Where are the 12 charts I asked for?")
Good:
"Dashboard scope: 4 charts (revenue, users, churn, MRR). Data from Postgres, refreshed daily. Desktop only — mobile is out of scope. Delivery: March 15. New chart requests go through the backlog."
When someone pushes past a boundary:
Don't argue. Refer back to the agreement.
"Per our March 1 scope doc, mobile was out of scope. Happy to add it — that moves the timeline to April 1. Want me to update the estimate?"
Scenarios With Scripts
Client blames you for a "bug" that's expected behavior
The situation: Client emails your manager: "The system is broken. [Feature] doesn't work. This is unacceptable."
You check — it works exactly as specified.
Bad response:
"It's not a bug. That's how it's supposed to work. The spec says so."
Good response:
"Thanks for flagging this. I checked the behavior — the system is working as specified in the requirements doc (link, section 3.2). The current behavior is: [describe]. If you'd like it to work differently, I'm happy to scope that as a change request. Want to set up 15 minutes to align on the expected behavior?"
Why this works: No blame. Facts with a link. Offer to fix if needed. Ball is in their court.
Someone escalates without talking to you first
The situation: A colleague CCs your manager and their manager on an email about a problem they never mentioned to you.
Bad response:
Reply-all: "This is the first I'm hearing about this. You could have just asked me directly."
Good response (reply-all):
"Thanks for raising this. Here's the current status: [facts]. I'll have a fix by [date]. I'll follow up directly with [name] to make sure we're aligned."
Good follow-up (DM to the colleague):
"Hey — saw the thread. Happy to address the issue. For future ones, feel free to come to me directly first. Usually faster to resolve."
Why this works: You look calm and competent to the managers. The DM sets the boundary without making it a public conflict.
Scope changes and you get blamed for the delay
The situation: Original scope was 3 features. Mid-project, 2 more were added. Now the deadline is missed and you're on the hook.
Bad response:
"It's not my fault — you added 2 features! You can't blame me for being late."
Good response:
"Original scope (March 1, link) was 3 features with a March 15 deadline. On March 8, features D and E were added (email thread, link). Updated estimate was sent on March 9 (link) with a new deadline of April 1. We're tracking to April 1. Happy to walk through the timeline if helpful."
Why this works: Pure facts. Links to everything. No emotion. The paper trail speaks for itself.
When to Escalate
Escalation isn't tattling — it's risk management. Escalate based on criteria, not frustration.
Escalate when any of these are true:
| Criteria | Threshold | Example |
|---|---|---|
| Personal attacks | Once | "You're incompetent" — not feedback, it's abuse |
| Repeated pattern | 3+ documented incidents | Blame-shifting on 3 separate projects with email trails |
| Time cost | >5 hours/week managing one person | You're spending more time on conflict management than productive work |
| Business impact | Measurable | Scope creep caused 2 missed deadlines, costing $30K in delayed revenue |
| Direct conversation failed | You tried, they refused or escalated further | You raised the issue 1:1, they CC'd leadership the next day |
How to escalate:
- Bring documentation — dates, emails, Slack messages, impact
- Lead with business impact — "This pattern has cost us 40 hours and 2 missed deadlines" not "They're being difficult"
- State what you've tried — "I've addressed it directly on March 3 and March 10 (email links). The pattern continued"
- Ask for a specific outcome — "Can we align on scope ownership so changes go through the backlog?" not "Can you talk to them?"
Don't escalate when:
- You haven't tried talking to them directly first
- It happened once and isn't a pattern
- You're frustrated but there's no business impact
- You want to "win" — not solve the problem
Common Mistakes
| Mistake | Why It Fails | Do This Instead |
|---|---|---|
| Matching their tone | Now there are two difficult people | Stay flat. Facts, links, dates. Let them be the emotional one |
| Defending yourself in long paragraphs | Makes you look guilty | 2-3 sentences max. Facts + next step |
| Venting to coworkers instead of acting | Feels good, changes nothing | Document, address directly, escalate if needed |
| Avoiding the conversation | Problem grows. Resentment builds | Address it early. Small problems stay small |
| Taking it personally | Drains your energy, clouds your judgment | It's a behavior pattern, not a verdict on your worth |
| Escalating without documentation | Your manager can't help without facts | Bring dates, links, and business impact |
| Setting boundaries after the project starts | Too late — expectations are already set | Lock scope, timeline, and roles before work begins |
References
- Feedback & Difficult Conversations — Radical Candor + NVC for giving feedback
- Clear Communication — Writing clearly under pressure
- Check Your Motives — Make sure you're solving the problem, not winning the argument