Opening: One Line, Two Different States of Mind
Monday morning, a message arrives from a colleague: "Why did you do it this way?" It is the same single line, yet it reads entirely differently depending on the receiver's state of mind.
- Suspicion mode: "They are blaming me. They are saying my approach is wrong."
- Good-faith mode: "They are probably curious about context I have. I can just explain."
The sender was merely curious, but the day's collaboration turns on which state of mind the receiver reads it in. Read in suspicion mode, a defensive reply goes out, the other side receives it defensively, and a small misunderstanding spreads into conflict. Read in good-faith mode, it ends with a single line of context.
This essay is not a naive plea to "just trust everyone." Quite the opposite. It is about building solid trust by assuming good intent and verifying.
What Assuming Good Intent Means
Assuming good intent connects to what philosophy calls the "principle of charity." When someone's words or actions are ambiguous, you first interpret them in the most reasonable, most charitable way available.
Beneath this lies a simple but powerful premise: most people do not wake up in the morning and head to work thinking "today I will torment my colleagues." Most frustrating behavior has context we do not see. They were chased by a deadline, lacked information, had other priorities, or simply had a bad day.
Psychology has a concept called the "fundamental attribution error": we tend to attribute others' mistakes to their character ("that person is just irresponsible") and our own to circumstance ("there was nothing I could do at the time"). Assuming good intent is a tool for consciously correcting this bias. You give others the same situational benefit of the doubt you give yourself.
The Mechanism by Which Good Intent Reduces Conflict
Why does assuming good intent smooth collaboration? It becomes clear when you compare it with the vicious cycle in which conflict amplifies.
[Vicious cycle of assuming bad intent]
ambiguous message -> "this is blame" -> defensive reply -> they get defensive too
-> relationship stiffens -> next message read worse -> conflict
[Virtuous cycle of assuming good intent]
ambiguous message -> "are they curious about context" -> calm reply -> they stay calm too
-> trust accumulates -> next message read better -> cooperation
The key is that interpretation is self-fulfilling. If I interpret the other person as an enemy, my reaction actually makes them an enemy. If I interpret them as a colleague, my reaction actually makes them a colleague. The first interpretation sets the trajectory of the relationship that follows.
Verification Is Still Necessary: Trust but Verify
Here balance matters. If assuming good intent becomes "blind trust," it is dangerous. The phrase "trust but verify" shows the exact balance point.
Assuming good intent is about a person's **intent**. Verification is about the **facts** of the work. The two do not conflict.
- Assuming good intent: "My colleague did not miss the schedule on purpose." (interpreting intent)
- Verification: "Still, the schedule did slip, so let us confirm a new deadline together." (confirming facts)
A good collaborator trusts people while building a safety net with systems. Code review, tests, documentation, and meeting notes exist not because we suspect anyone, but because anyone can make mistakes. The healthiest stance is "I trust you, but since we are both human, let us keep the checks in place."
The table below shows applying good intent and verification together.
| Situation | Assume good intent (intent) | Verify (facts) |
| --- | --- | --- |
| Data is wrong | "Probably a mistake" | Check the number's source together |
| No reply | "Probably busy" | Send one more reminder before the deadline |
| A decision changed | "There must be a reason" | Ask the reason and record it |
Curiosity Instead of Blame
The most concrete way to practice assuming good intent is to swap blame for curiosity. When a problem arises, ask not "whose fault is this?" but "what happened?"
Here are two dialogue examples handling the same situation.
[Blame mode]
A: Why didn't you announce the deploy in advance? It caused an outage.
B: I posted it to the channel. Isn't it your problem you missed it?
A: Who reads all of that?
-> No fact-finding, just hurt feelings
[Curiosity mode]
A: I don't think the deploy notice reached me. Where did you post it?
B: The deploy channel. Oh, maybe you're not subscribed to it.
A: Right. From now on, should we add a mention for important ones?
-> Root cause + prevention
The difference in curiosity mode is that it reframes the problem as a system issue, not a person. The higher the psychological safety Amy Edmondson described, the more natural these curiosity-based conversations become, because people do not take mistakes as attacks on their character but as problems to solve together.
Reducing Misunderstanding in Remote and Async Work
Where assuming good intent matters most is the remote, async environment. Text has no facial expression, no tone of voice, no immediate feedback. The human mind fills the gaps left by missing information, and when the mind is in a bad state, it fills those gaps negatively.
Practices run in two directions.
**The receiving side (the reader):**
- Do not read a short message as rudeness. "Got it" may not be cold, just busy.
- If there is room for misunderstanding, do not conclude immediately; ask. "Do you perhaps mean X?"
- If emotions escalate over text, switch to a video or voice call. Text easily amplifies conflict.
**The sending side (the writer):**
- Add one more line of context. Instead of "why did you do it this way?", try "I'm curious about the context. Could you tell me why this part ended up this way?"
- In async, state intent explicitly. A single line of "not blame, just a confirming question" makes a big difference.
- Praise in public, deliver hard feedback one-on-one.
Responding When Trust Breaks
Assuming good intent has clear limits. If the same person breaks the same promise repeatedly, assuming good intent every time then is not good faith but self-deception. Trust is not given without limit; it is recalibrated when broken.
A staged approach works well.
1. **First time:** Assume good intent. Anyone can slip. Let it go lightly.
2. **Second time:** Check whether it is a pattern. Ask directly, but without blame: "The deadline has slipped twice recently. Is something blocking you?"
3. **Third time and beyond:** Treat it as fact. Set a clear boundary using specific examples and impact, not emotion. Involve a third party or manager if needed.
The key is to hold both the generosity of the first time and the firmness of the third. Be only generous and you become a pushover; be firm from the start and you wreck the relationship. Assuming good intent is a starting point, not a destination.
A Case: The 3 a.m. Commit
On a remote team, a colleague went days without responding to code reviews. At first everyone was frustrated. "Why is this person so uncooperative?"
One teammate sent a message with curiosity instead of blame: "A few review requests have piled up. Are you swamped lately? Let me know if we need to reprioritize." A reply came. The colleague worked in a different time zone and, while caring for a family member, could only carve out time in the early hours. That was why the commit timestamps read 3 a.m.
Had they gone with bad-intent assumptions, they would have branded the colleague "uncooperative" and the relationship would have soured. Approaching it with good intent plus verification surfaced the real cause, and the team rebalanced the review load. It preserved both the colleague's situation and the team's progress.
Self-Diagnosis Checklist
[ ] When I get an ambiguous message, I first try the most charitable reading
[ ] When a problem arises, I ask "what happened" before "whose fault"
[ ] I handle intent (the person) and facts (the work) separately
[ ] When emotions escalate over text, I switch to a call or in person
[ ] I see verification as a safety net for everyone, not as suspicion
[ ] When the same problem repeats, I escalate from generosity to firmness
[ ] I add one more line of context and intent to the messages I send
Closing: Solid Trust
Assuming good intent is not naivety. It is in fact the most efficient collaboration strategy. The cognitive cost of suspecting the other person's intent every time, and the emotional cost of defensive responses, are larger than you think. Set good intent as the default and you save that cost for the actual work.
At the same time, assuming good intent becomes solid only on top of verification. Trust the person's intent but confirm the facts of the work, and when trust breaks repeatedly, draw the boundary again. Collaboration is healthiest when generosity and firmness, trust and verification, are held together.
Take one ambiguous message you received today and re-read it once toward the most charitable interpretation. That small shift in interpretation may prevent more conflict than you would expect.
References
- Amy Edmondson, "The Fearless Organization" — https://amycedmondson.com/the-fearless-organization/
- Google re:Work, Psychological Safety — https://rework.withgoogle.com/guides/understanding-team-effectiveness/
- HBR, "What Is Psychological Safety?" — https://hbr.org/2023/02/what-is-psychological-safety
- Principle of Charity, Stanford Encyclopedia of Philosophy — https://plato.stanford.edu/
- Will Larson, "Engineering management" — https://lethain.com/
- The Fundamental Attribution Error, Verywell Mind — https://www.verywellmind.com/what-is-the-fundamental-attribution-error-2795261
현재 단락 (1/75)
Monday morning, a message arrives from a colleague: "Why did you do it this way?" It is the same sin...