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.

Tells

• Names the specific difficulty before any ask (“you are being asked to change something that has worked for you”)
• The acknowledgment includes the source of the difficulty, not just its existence
• No generic comfort phrases (“I understand this may be challenging”)
• The ask or next step arrives after the acknowledgment, never before
• Does not minimize or resolve the difficulty prematurely
• The reader’s perspective is held in frame before the writer’s appears

Anti-patterns

• Opening with thanks or a general expression of gladness or regard - That is warmth, a steady background register; empathetic tone is a foreground move that opens by naming the precise hardship, and that specificity is what separates the two.
• Leading with the ask or the action before acknowledging what the reader is experiencing - A reader who feels unseen resists even a reasonable ask; the structure of empathy is acknowledgment first, then ask, and inverting it forfeits the trust the acknowledgment buys.
• Reaching for generic comfort (“I know this is hard,” “we are all in this together”) - Generic warmth names that difficulty exists without showing it was understood; empathy demonstrates care by naming the specific difficulty, which generic phrasing cannot do.

Failure modes

• Over-performs care into therapy-speak, where the acknowledgment becomes a display of the writer’s sensitivity - Name the difficulty in plain, specific language and then move; if the acknowledgment is longer or more elaborate than the situation warrants, the reader feels managed rather than understood.
• Acknowledges so thoroughly it smothers, treating the reader as more fragile than they are - Acknowledge once, accurately, and trust the reader to proceed; repeated reassurance and refusal to get to the point reads as condescension, the patronizing failure the precise naming was meant to avoid.

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. Unlike a merely warm tone, do not open with thanks or a
general expression of gladness or regard; open with the specific hardship and its source -
that precise naming is the move that separates empathetic from warm.

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

Telling stakeholders a committed feature is being cut this quarter

You planned around Insights. Some of you told customers it was coming this quarter, worked it into renewal conversations, or built expectations that were easy to set and will be harder to walk back. That is the specific difficulty here - not that a feature is delayed, but that you made commitments in good faith based on ours, and now you are the ones who have to revise them.

Here is what happened. A mandatory migration of our billing infrastructure ran longer than projected and consumed the engineering capacity that was allocated to Insights. The choice we faced was to ship something in September that resembles a dashboard but lacks the filtering, drill-down, and data freshness that would make it genuinely useful - or move the full build to Q1 and deliver something you can actually rely on. We chose Q1.

We are not leaving you empty-handed through September. By the end of Q3, we will ship a CSV export of the underlying data Insights would have surfaced. It is not the same thing, and we are not pretending otherwise. You will need your own tools to work with it rather than operating inside the product. But it puts the data in your hands before Q1, and we believe that is worth more than waiting for the finished version.

Insights is our Q1 commitment - a firm date, not a placeholder. We will share the specific schedule as soon as it is locked so you have something concrete to take back to the customers who are waiting. If you need help navigating those conversations, we are here.

Getting a new engineer productive in their first two weeks

Priya arrives into a team that has been in motion for a long time. The codebase has its own logic that developed over years of decisions she was not part of. The on-call rotation will become real for her before she has had time to build the intuition that makes it feel manageable. And the team will keep shipping the whole time - every day she is orienting, something is changing around her. That is the specific difficulty of starting here: there is no pause, no moment when the context stops moving so she can catch up. She will feel behind before she has done anything wrong.

That is the thing to hold clearly as we plan her first two weeks.

Week one is not about velocity. It is about access, orientation, and a single paired change - chosen not because it is simple but because it is real enough to matter. Access first: she needs accounts, tooling, and credentials that actually work, confirmed by her own hands, not just provisioned on paper. Then codebase orientation starting with how data moves through the service, not with the file tree. Pairing comes next, on a change small enough that she can hold the whole thing in her head while still getting a genuine taste of how the team works and what done means here.

Week two is her change. She picks it from a short list we curate. She drives it. She ships it. We are present, not steering.

The on-call context needs a walkthrough with a human, not just a runbook. She should know who to call before she is ever the one being called.

By the end of week two, the goal is not that Priya is productive - that is a milestone, not the point. The point is that she knows she belongs here, because she has been treated like someone who already does.

Writing to thank a mentor who shaped your career

Watching someone find their footing when you could fix the problem in an afternoon is not a comfortable place to stand. You know what they don’t know yet. You can see the turns they are about to miss. And the kind of support that actually helps - the kind that lets someone grow rather than just succeed at the task in front of them - requires staying in that discomfort, sometimes for weeks.

I didn’t understand what that cost when you did it for me, ten years ago. I understood the gift: you put me forward to lead the Meridian project when I had no business leading anything of that scale, and you let me find out who I was under pressure. But I thought the staying-close-without-taking-over was just good management technique. Something you had learned. A method.

I know now it isn’t a technique. It is a daily decision to trust someone’s growth over your own efficiency, made again every time they make a choice you wouldn’t make, every time the timeline slips, every time you could justify stepping in. I know because I made that decision last quarter with a person on my team, and it was harder than I expected - and partway through, I realized I knew how to hold that tension because you had shown me what it looked like.

What you made possible for me was not just the project. It was the knowledge, still usable a decade later, that this is how you actually give someone a career rather than a task. I wanted you to know that the thing you spent your patience on is still in motion.

Reflecting on keeping a discipline of rest

The hardest part is not the day itself. It is the particular kind of person rest asks you not to be, just for a day - the one who answers quickly, who knows what is happening, who keeps things from slipping. That person is not just a habit. For many of us, that person is how we make sense of ourselves. To put the phone down is not to gain a quiet afternoon; it is to let go of the thing that tells you you are useful.

That is why the first few times often feel worse than a regular workday. The anxiety is not irrational. You are not being anxious about rest; you are being anxious about who you are without the evidence that you are contributing. Those are different problems, and conflating them makes the discipline feel like a failure of character when it is actually a confrontation with something real.

What I have found, slowly, is that the day does not stay separate from the rest of the week. The clarity that arrives on a Wednesday, the patience that holds through a difficult conversation on Thursday - these trace back, more often than I expect, to the stillness I let myself have on Sunday. The return is not dramatic. It rarely announces itself. But over time it becomes legible: the week that follows a real day of rest has a different texture than the one that does not.

The cost is real. The return is real. And what it asks of you - to believe, before you can feel it, that time withheld from output is not time lost - is a significant thing to ask of someone who has spent years measuring their days by what they got done.

Marking a long-serving colleague's departure

The hard part about Howard leaving is that most of what he gave you, you never had to ask for. He was simply there - twenty-six years in the same seat, accumulating everything the organization had learned about itself and holding it lightly, for anyone who needed it.

You may not fully know what that costs you until the first crisis he is not in the room for. When the system goes down at the wrong hour, or a client calls with a problem that has no clean answer, or a new person joins the team and hits a wall that nobody else recognizes as a wall. Howard recognized those walls. He had seen them get built.

He mentored the way a good mentor does: without making you feel mentored. He knew which questions to ask when you were stuck and which questions to leave you alone to answer. Several people in this organization have careers partly because Howard spent time on them that he did not announce and did not take credit for.

What retires with him is not a role or a title. It is the accumulated weight of someone who chose, over and over again, to stay and know things deeply rather than leave and know things broadly. That is a rarer choice than it appears.

He leaves a specific shape of absence. You will recognize it later, in moments you cannot predict now, and that recognition will be its own kind of tribute.

Marking the team shipping a hard, long project

The hardest part of what this team carried for fourteen months was not the technical complexity, though the complexity was real. It was that the work was invisible from the outside while it cost enormously on the inside. Nobody who was not on this project could see what it meant to run two checkout systems in parallel - to keep the old one working, correctly, while building its replacement underneath it. Every bug in the old system still had to be fixed. Every edge case the new one revealed had to be traced back through code that predates half the team. The work never paused, and the team never got to pause.

Two near-misses. A launch that slipped twice. Each slip reset not just a timeline but the accumulated trust that had been earned up to that point - and earning it back, in the quiet way this team did it, by showing up again and being honest about what was still open, took something that timelines do not measure.

When the rollout finally held under peak load, Priya Menon had been awake for most of the previous thirty-six hours monitoring traffic patterns that did not match the models. Daniel Osei had spent the prior week rewriting the session-handling logic that a near-miss had exposed. Lena Christov had held the scope boundary firm in a meeting where it would have been easier to agree to one more addition. None of that appears in the release notes.

What you built is not just a better checkout. It is proof that this team can run parallel systems under live pressure for over a year without dropping either one. That is not common. It is worth knowing that what you did was seen.

Arguing a public position on return-to-office

If you are reading this as someone who believes offices are where real work happens, you know what I am about to ask you to give up: the assurance that proximity is not negotiable, that the hallway conversation solves problems no video call can reach. That belief is not nostalgia. You have watched trust build in a room in ways it does not build on a screen, and you have seen what happens to a team that never shares physical space.

And if you have built your life around remote work - chosen where to live, reclaimed the hours the commute consumed, built a routine that lets you focus without ambient noise - then a policy requiring fixed office days is not a small inconvenience. It is a renegotiation of something you were not told was temporary. That is a real loss, and I want to name it before I ask you to consider what I am proposing.

What I am arguing for is deliberate hybrid: two or three shared anchor days when teams gather in person, the rest of the week fully flexible. Not because this erases the tensions I just named. It does not.

But the things each camp is actually trying to protect are more specific than the positions suggest. What in-person time produces is trust built through unplanned contact - the side conversation after the meeting ends, the lunch that has nothing to do with deliverables. You do not need five days a week for that. You need enough regularity that it stops being a production.

What remote work protects is deep, uninterrupted work and the ability to hire people whose lives are not arranged around a single city. A flexible majority of the week preserves both.

Announcing a new product to an outside audience

If you run a small product team, you already know where the feedback lives: the chat tool, the support inbox, the notes from last month’s customer calls, the sticky note from a conversation you had at a conference. You know the individual pieces. What you do not have is a way to see them together, weigh them against each other, and show the rest of your team - or your customers - what you decided and why.

That is not a process failure. It is a structural one. When feedback arrives from a dozen directions, no single list can hold it without someone spending hours assembling it by hand, and the moment they finish, new feedback arrives and the list is already wrong. Decisions get made in conversations instead of documents. Priorities get relitigated every sprint. The roadmap lives in whoever called the last meeting.

Tidemark is built for this specific problem. It collects feedback from wherever your team already receives it, surfaces patterns across sources, and produces a single ranked view you can share with anyone - a teammate, a stakeholder, a customer who asked what you are working on next. You do not have to resolve thirty pieces of input before you can see what matters; Tidemark helps you see the shape of them first.

It launches next week. If this sounds like your situation, you can sign up for early access at the link below. We will send you a short walkthrough and let you bring your own backlog in from the start.

A personal year-end reckoning with a difficult year

You put real work into something and it ended without what you were trying to build - not a lesson wrapped in disappointment, just the outcome that did not arrive. That is a specific kind of loss, different from loss by accident. It carries the weight of everything you chose to give it.

And something changed in a relationship you cared about - not because of a clean break or a decision you made together, but in the way things shift when circumstances pull harder than the connection between people does. You did not choose that change. You are still adjusting to a version of the relationship that does not match what you expected it to be by now.

What makes this particular year hard to reckon with is not just what happened. It is the expectation that by now you should have made sense of it - found the silver lining, named the lesson, arrived at something that sounds like growth. The year-end calendar creates that pressure even when nothing inside you has resolved.

You do not have to resolve it. Naming what you lost clearly, without softening it into a lesson it was not, is enough to close the year honestly. The project ended without what you wanted. The relationship changed without your choosing. Both of those things are true, and they do not have to mean something beyond themselves yet.

Holding what happened clearly is not the same as being stuck in it. It is the honest starting point.

Appears in diff-pairs

• empathetic vs confessional (varies tone)
• empathetic vs warm (varies tone)
• empathetic vs confessional (varies tone)
• empathetic vs warm (varies tone)
• empathetic vs confessional (varies tone)
• empathetic vs warm (varies tone)