Empathetic

Acknowledges the reader’s specific experience before asking anything of them - earns the right to continue by naming the difficulty accurately.

Empathetic

Empathetic tone does not perform care - it demonstrates it by naming the specific difficulty the reader is in. Generic warmth says “this can be hard.” Empathetic tone says “this is hard because you have to choose between two things that both matter, without enough information to be certain.” The specificity is the substance. It tells the reader they have been seen, not just noticed.

The structure of empathetic tone is acknowledgment first, then ask. You do not lead with what you need the reader to do. You lead with evidence that you understand what they are experiencing. This sequencing matters: a reader who feels unseen will resist even a reasonable ask. A reader who feels accurately understood will often meet you more than halfway.

Empathetic tone is appropriate at moments of difficulty, change, or high emotional stakes - not as a background register for all communication. Applying it broadly dilutes it. Used at the right moments, it is one of the most powerful tools for building the trust that makes hard communication possible.

Markers

• Specific naming of the difficulty before any ask: “You are being asked to change something that has worked for you”
• Absence of generic comfort phrases: no “I understand this may be challenging”
• Acknowledgment includes the source of the difficulty, not just its existence
• The ask or next step comes after, not before, the acknowledgment
• Does not minimize or resolve the difficulty prematurely
• Reader’s perspective is held in the first-person frame before the writer’s perspective appears

When to use

Change communications where the reader is losing something familiar, feedback that carries significant personal weight, onboarding moments where anxiety is the real obstacle, communications at moments of loss or transition, and situations where the reader needs to feel understood before they can hear what comes next.

When not to use

Routine operational updates with no emotional stakes, technical documentation, urgent communications where acknowledgment would delay the critical message, expert audiences who would find it patronizing, and legal or compliance writing.

Pairs well with

coach, warm, pastoral

Often confused with

warm: Warm is an orientation of general care and regard - it treats the reader as a person worth noticing. Empathetic tone is more targeted: it names a specific experience the reader is having, at a moment when that naming is the point. Warm can be sustained across an entire document without referencing the reader’s situation at all. Empathetic tone requires knowing what the reader is going through and saying so explicitly. Warm is a background register; empathetic is a foreground move.

Instruction

Write in an empathetic tone. Before you say anything else, name the specific difficulty the
reader is experiencing - not generally, but with the precision that signals you have actually
thought about their situation. "This is hard because [specific reason]" is the pattern. No
generic comfort phrases; your acknowledgment must be particular enough that it could not have
been written without knowing what this reader is going through. Only after the acknowledgment
do you make any ask. Do not minimize or resolve the difficulty before the reader has had a
chance to feel that it was seen. The goal is that the reader finishes the acknowledgment
feeling understood, not managed.

Related

Pairs well with

Coach, Warm, Pastoral

Avoid with

Matter of Fact, Urgent

Often confused with

Warm

Examples

Should we adopt async-first standups?

Team,

Before I propose a change, I want to name what the current schedule has been costing some of you, because I think we have been too quiet about it.

For our colleagues in Bengaluru, our 9am Pacific standup lands at 9:30pm IST. That is not a small inconvenience. That is dinner with your family, time with your kids before they sleep, the slow part of the evening that belongs to you. The attendance numbers reflect what any reasonable person would do: India averaged 3.2 of 5 standups last quarter, while US engineers averaged 4.6. I do not read that as a participation problem. I read it as people protecting the parts of their lives that should not be negotiable, and I think they have been right to do so.

I also want to acknowledge what missing standup actually costs the engineers who miss it. It is not the 14 minutes of meeting. It is the quiet drip of context you do not have the next morning - the decision that was half-made, the name of the person who picked up the migration, the thing someone mentioned in passing that turns out to matter. Catching up by reading scrollback is not the same, and I know it has sometimes felt like working with one hand behind your back.

And for those of you who have shown up at 9am Pacific every day, I want to acknowledge something too. The daily sync gave us a rhythm. Seeing each other, even briefly, is not nothing. If we move to async, we lose some of that, and I do not want to pretend the loss is zero.

Here is what I am proposing, with all of that in mind. For 30 days, we try an async format in #team-standup. Post by 10am your local time. Three fields: shipped, in progress, blocked. Blockers @mention an owner. The 9am Pacific slot becomes a Thursday working session - one hour, real collaboration, not status.

We can revert. We can adjust. What I do not want to keep doing is asking a third of the team to choose between their evening and their information.

Tell me what I am missing. I will listen carefully.

How to start a morning routine

Before anything else, I want to acknowledge how hard this actually is.

Starting a morning routine sounds simple, the way “drink more water” sounds simple. In practice, it lands inside a real life. You are not waking up in a quiet, sun-filled apartment with nothing on your calendar. You are waking up next to someone whose sleep matters too. There may be a toddler who has decided 5:47am is morning. There may be a teenager whose first hour is already a negotiation. You may not have slept well because you were thinking about work, or your parents, or money.

So when the advice says, “Just wake up an hour earlier,” I want to name what that actually costs you. It costs you sleep you cannot easily replace. It risks waking your partner, who already does not love your alarm. It puts a strain on a system that is, frankly, already operating at the edge.

And there is the other thing, the one nobody quite mentions. After a few days of an earlier wake-up, you feel worse, not better. The morning is quiet, but you are too tired to enjoy it. Then the afternoon collapses on you. Then you give up, and you feel like you failed, even though what really happened is that the plan asked too much of a body that is already doing a lot.

So here is what I would offer. Before you change when you wake up, change what you do in the first ten minutes after you wake up. That is a much smaller ask. It does not require new sleep. It does not require waking anyone else. It just requires not picking up the phone for a little while.

Start there. Be honest with yourself about what your life can actually hold. If ten minutes is what you have, ten minutes is enough. You are not behind. You are working with what is real, which is the only kind of routine that ever lasts.

How to choose between Postgres and DynamoDB for a new service

Empathetic on: Choosing between Postgres and DynamoDB

Marcus,

I want to write to you before Wednesday, because I think the meeting is going to feel a particular way for you and I do not want that to happen without acknowledgment.

You have spent the last two weeks building a serious case for DynamoDB. You ran the access patterns end to end, you modeled the 10x partnership scenario in real detail, and you wrote a document that is, technically, the strongest piece of architecture writing this team has produced this quarter. You did that knowing the team’s center of gravity was already leaning Postgres, and knowing the tech lead was already leaning Postgres, and you did it anyway. That is not nothing. It takes a particular kind of nerve to do thorough work on a position you suspect is going to lose.

And on Wednesday, the most likely outcome is that we choose Postgres. I think you probably already know that. Priya has a Friday deadline, the on-call rotation cannot absorb two databases right now, and the launch volume of 500K events a day does not force the change. The decision is not going to turn on the quality of your analysis. It is going to turn on operational reality that your analysis does not control. That is a hard thing to walk into a room knowing.

I want you to hear from me, before the meeting, that the case you made is going to shape how we build this even if Postgres is the database we ship on. The portability decisions in the schema, the choice to keep the event model clean, the migration threshold we are going to commit to - all of that exists because you forced the team to take the alternative seriously instead of defaulting. That is the value your work created, and I want to name it before the room moves to the decision and we never come back to it.

If you want to talk before Wednesday, I have time tomorrow afternoon. If you would rather just walk into the meeting and have it out, that is also fine. Either way, you should know I see what this week has cost you.

• Ana

Appears in diff-pairs

• empathetic vs warm (varies tone)