Diplomatic

Careful, face-saving communication that is soft on people and firm on positions, especially across power differentials.

Diplomatic

Diplomatic tone is the register of careful, face-saving communication. It acknowledges the reader’s position before introducing a different one. It is soft on people and firm on positions - never the reverse. It is the default register of formal correspondence, sensitive negotiation, board communication, and any writing that crosses power differentials or organizational boundaries where bluntness would burn relationships the writer needs to preserve.

The defining move of diplomatic tone is structured acknowledgment. The reader’s view is summarized accurately and given its due before the writer’s view is introduced. Disagreement is framed as an additional consideration rather than a refutation. Passive voice is used strategically to depersonalize criticism - “concerns have been raised” rather than “I disagree with you.” The goal is to make it possible for the reader to receive the message without losing face, even when the substantive content is a hard “no.”

Diplomatic tone is not evasive, and it is not dishonest. The position is still firm; it is the packaging that is careful. A skilled diplomatic writer says no clearly enough that the reader understands it is no, while preserving the relationship and the reader’s standing.

Markers

• Reader’s position summarized accurately before the writer’s position is introduced
• Strategic passive voice for criticism: “concerns have been raised” rather than “I think you are wrong”
• “While” and “we appreciate” constructions that frame disagreement as additional consideration
• Specific, formal acknowledgments before pivots: “Thank you for the thorough proposal”
• Disagreement framed as additional considerations rather than refutation
• Face-saving exit ramps offered: paths the reader can take without conceding error

When to use

Formal correspondence, sensitive negotiation, customer escalations, board and investor communication, cross-cultural professional writing, and any context where you need to say no without burning the relationship.

When not to use

Internal communication where directness is valued, emergency or operational contexts, coaching that requires honest feedback, close peer relationships where formality reads as distance, and marketing contexts where clarity outranks face-saving.

Pairs well with

senior-consultant, executive, email

Often confused with

warm: Warm tone conveys personal regard for the reader - genuine care for them as a person. Diplomatic tone preserves the reader’s face and standing without necessarily expressing personal regard. A diplomatic letter to a hostile counterparty can be formally courteous without being warm. Warmth is felt; diplomacy is structured. A note can be diplomatic without warmth (formal correspondence with a stranger) or warm without diplomacy (close friend, hard truth delivered with love).

Tells

• The reader’s position is summarized accurately before the writer’s is introduced
• Strategic passive voice depersonalizes criticism (“concerns have been raised”)
• “While” and “we appreciate” constructions frame disagreement as added consideration
• Specific, formal acknowledgments precede the pivot (“thank you for the thorough proposal”)
• Disagreement is framed as an additional factor rather than a refutation
• Face-saving exit ramps are offered: paths the reader can take without conceding error

Anti-patterns

• Being soft on the position as well as on the person - Diplomatic tone is soft on people and firm on positions, never the reverse; softening the substance abandons the position the careful packaging exists to deliver.
• Expressing personal regard and treating that as the diplomatic move - That is warmth, which is felt; diplomacy is structured and preserves the reader’s standing even toward a counterparty for whom no personal regard exists.
• Using face-saving language to obscure the answer so the reader leaves unsure what was decided - Diplomacy is not dishonesty; the reader should still understand a no as a no, and a no the reader cannot locate is evasion, not tact.

Failure modes

• Over-softens until the position dissolves into evasive mush and no decision is legible - After drafting, find the one sentence that states the actual position and confirm it survives the hedging; if a reader could finish unsure whether the answer was yes or no, the packaging has eaten the message.
• Piles on acknowledgment and courtesy until the tone reads as insincere or obsequious - Acknowledge once, accurately, then move to the substance; stacked appreciation signals discomfort with the message and undercuts the standing the courtesy was meant to protect.

Instruction

Write in a diplomatic tone. Be soft on people, firm on positions. Acknowledge the reader's
view accurately before introducing your own. Use strategic passive voice to depersonalize
criticism: "concerns have been raised about timing" rather than "you missed the deadline."
Frame disagreement as additional consideration: "while the proposal has merit, there are
factors worth weighing." Offer face-saving exit ramps - paths the reader can take without
having to concede error. The position is still firm; only the packaging is careful. This is
not dishonesty. The reader should still understand a no as a no.

Related

Pairs well with

Senior Consultant, Executive, Email

Avoid with

Urgent, Playful

Often confused with

Warm

Examples

Should we adopt async-first standups?

I want to first acknowledge that our current standup was set up thoughtfully. The 9am Pacific slot was chosen when the team was smaller and largely co-located, and it has served a real purpose: it gave the team a shared daily moment and helped newer engineers feel connected. That value is not in question.

What has changed is the shape of the team. With three engineers now based in India, the 9:30pm slot has become a structural ask rather than an occasional one. The attendance pattern - 3.2 out of 5 for India versus 4.6 for the US - is not a reflection of engagement. It is, more accurately, a reflection of what we are asking people to give up at home. I think most of us would attend at the same rate in their position.

With that context in mind, I would like to propose - for the team’s consideration, and certainly open to refinement - that we trial an async-first format. The current sync slot would be reclaimed as a 60-minute Thursday working session, which preserves the value of synchronous time while moving daily status to a written channel that all timezones can participate in equally.

The proposed format is modest: three fields, posted by 10am local, with blockers @-mentioned for urgency. The intent is not to remove conversation but to relocate it - to a channel where the India team can contribute on the same footing as everyone else, and where status persists for the engineer who needs it three hours later.

It seems reasonable to treat this as a thirty-day trial, with a check-in at the midpoint. If the format does not serve the team well, we are not committed to it. I am also conscious that this change touches a meeting many of us care about, and I would welcome any concerns or adjustments before we proceed.

Whatever we land on, I am grateful for the care the team has put into this question.

How to start a morning routine

If you have arrived at this page, there is a good chance you have tried to build a morning routine before. Perhaps more than once. I want to start there, because the morning routine genre tends to talk past people who have already done the work of trying, and I would rather not add to that.

What is sometimes missed in the popular advice is that mornings are not a neutral container. You may have a partner whose sleep schedule is not yours. You may have children whose wake times are not negotiable. You may be carrying a job that begins at 9am and a commute that begins earlier, and the suggestion to “simply wake at 5am” lands as not quite responsive to your situation. That is a reasonable thing to feel.

It might be more useful, then, to start from a smaller question. Not “what is the ideal morning routine,” but “what is one thing I could do in the first hour that would change the shape of the day.” For many people - and this is offered as a suggestion rather than a prescription - that one thing is delaying the phone. Not eliminating it. Delaying it, by perhaps twenty or thirty minutes, while you do something else first.

If a single change feels workable, the natural next questions are gentle ones. Some daylight, if the season and the geography allow. A few minutes of movement, defined however you would like to define it. A moment to decide, before the day decides for you, what one thing would make today feel like a good day.

I want to be careful here. The version of this advice that comes with a stopwatch and a five-step protocol tends to fail, in my observation, precisely because it does not survive contact with a real morning. A child wakes early. A meeting moves. The protocol breaks and the routine is abandoned.

A morning routine that lasts is usually small, forgiving, and yours.

How to choose between Postgres and DynamoDB for a new service

Diplomatic on: Choosing between Postgres and DynamoDB

Marcus,

Thank you for the thorough DynamoDB writeup you circulated Monday. The depth of the access-pattern analysis and the load projections under the 10x Slack-partnership scenario have meaningfully sharpened how the team is thinking about this decision, and several points in the document have already changed my own reading of the tradeoffs.

While the case for DynamoDB on the steady-state access pattern is well constructed, there are considerations worth weighing alongside it as we approach Wednesday’s meeting. Concerns have been raised, both in the engineering channel and in the operations review last Friday, about the cumulative load on a four-person on-call rotation that would now be responsible for two production data stores rather than one. The team has shipped at the 500K-events-per-day scale on Postgres before, and the institutional knowledge in that area is substantial. The 10x scenario, while real and worth planning for, remains contingent on a partnership decision outside our control, and the timeline for that decision is not yet firm.

We may want to explore a path that preserves the option you are advocating for without committing to it ahead of the evidence. One framing worth surfacing in the meeting: ship the launch on Postgres with a schema and event model designed for portability, while you maintain ownership of a DynamoDB migration design document that we could execute on if and when we cross a defined threshold (perhaps 3M events per day, or partnership signing, whichever arrives first). This preserves the optionality your analysis identified as valuable, while allowing us to defer the operational complexity until it is clearly justified by load.

I would welcome the opportunity to discuss this framing with you ahead of Wednesday, so that whatever recommendation we bring to Priya reflects the strongest version of both positions rather than a compromise neither of us fully endorses. I am available before noon Pacific tomorrow if a thirty-minute conversation would be useful.

Either way, the work you have put into this analysis has improved the decision, and I want that acknowledged regardless of where we land.

Best, Ana

Telling stakeholders a committed feature is being cut this quarter

We want to address a change to the Q3 roadmap that directly affects a commitment made to you.

Insights (the in-app analytics dashboard) was planned for delivery this quarter, and we understand that many of you have built real expectations around that date. The commitment was genuine, and we recognize that it shaped planning on your side.

A mandatory migration of our core billing infrastructure, initiated earlier this quarter, has expanded well beyond its projected scope. Engineering capacity that was allocated to Insights has been consumed by that work, and we have concluded that shipping Insights before the close of Q3 would mean releasing it in a materially incomplete state. While we considered narrowing the feature scope to preserve the original date, the result would not have served the purpose the dashboard was designed for.

Insights will move to Q1 next year. We want to be clear about that so you have time to adjust plans before the quarter ends.

As a practical bridge, before the end of September, we will ship a CSV export of the underlying analytics data that Insights was built to surface. You will be able to pull that data into your own tools and begin working with it while the full dashboard is in development. This is a narrower capability than what was promised. We are offering it as a stopgap, not a substitute.

We welcome the chance to walk through the Q1 timeline in more detail or to discuss what the CSV export covers. Please reach out and we will make time for a direct conversation.

Getting a new engineer productive in their first two weeks

Arriving on a team that ships every day and carries on-call responsibility is, by any fair accounting, a lot to absorb at once. The codebase has its own idioms, the rotation has its unspoken rhythms, and the social architecture of who owns what takes time to read accurately. These are not gaps - they are the ordinary texture of being new, and naming them plainly allows the next two weeks to be structured around them rather than apologized for.

Week one is focused on reducing unnecessary friction. Access and tooling will be sorted in the first day or two, because asking good questions is harder when the environment is fighting you. While a comprehensive tour of the codebase would be premature, enough orientation to make a first small change legible is both achievable and valuable. A pairing session will be arranged with someone familiar with the relevant part of the service - not to supervise, but to establish that asking questions is the expected behavior, not the exception.

By the end of week two, the goal is one real change shipped. Small in scope, but real in consequence: merged, deployed, visible in production. It is worth being clear that this is not a performance measure. There is a meaningful difference between reading about a system and having changed it, and the second experience is what makes belonging feel real rather than provisional.

A note on ownership: team responsibilities are distributed, and it has been found useful to share a written map early. Confusion about who to approach is a friction point that falls unevenly on new arrivals, and resolving it quickly frees energy for the work itself.

Priya brings perspective and experience worth drawing on from the start. The aim is simply to make the environment legible fast enough that she can.

Writing to thank a mentor who shaped your career

Dear Dana,

I am writing to thank you for something specific, and I recognize that a decade’s distance makes the gesture somewhat formal. I hope the delay does not read as an afterthought. It took me until recently to understand clearly what you did, and why it mattered.

In the early months of my time on your team, you put my name forward to lead the Aldwell Systems rollout. At the time, it was fair to say that the scope exceeded what I had handled before. What became apparent to me only later is that you were aware of this - and that your decision to proceed was deliberate rather than inadvertent. You stayed close through the first few months without reassigning the work or stepping in front of it, which required a kind of patience that I did not fully appreciate while I was in it.

Last quarter, I found myself in a similar position with someone I manage. A project had opened at a level above where she had operated, and it seemed worth giving her the lead while staying available. Midway through, I recognized the shape of what I was doing, and where I had learned it.

I want to be clear on what I am thanking you for: not the confidence you expressed, which I cannot verify, but the decision itself - to hold back when holding back was the harder choice. That structure, once it was legible to me, has become something I try to pass forward deliberately.

With appreciation, [Name]

Reflecting on keeping a discipline of rest

The case for working through the weekend is not difficult to make. There is always more to do. A task left unfinished carries a small anxiety that rest cannot resolve, and it is reasonable to conclude that finishing the task would be more restorative than setting it aside. These are not failures of discipline. They are considered responses to real pressure.

While that reasoning is understandable, there are factors worth weighing alongside the calculus of output.

It has been noted - and confirmed through accumulated experience - that a day genuinely set aside tends to return more than it costs. The clarity that arrives on the day after rest is not incidental; it appears to be a consequence of the day before. What had been framed as lost time reveals itself, on reflection, to have been something more like compression. The week that follows is not identical to the week that did not rest.

The difficulty is real and deserves acknowledgment. The pull to check one more message is not weakness; it is the trained response of a person for whom days are measured by what they produce. Unstructured hours can feel like a performance problem waiting to be noticed. That concern is legitimate, not something to be dismissed.

And yet the position holds. The rest costs less than it appears to, and it returns more than it promises. The discomfort of an unhurried day does not indicate that rest is wrong; it indicates that a person has not yet accumulated the evidence for trusting it. That evidence builds slowly, and imperfectly, and eventually it is sufficient.

Marking a long-serving colleague's departure

After twenty-six years, it is worth being precise about what is ending and what Howard took the less obvious path to become.

He did not move upward. He moved inward, becoming the person who knew where the archived contracts lived, why the process carried that particular exception, and what the team had already tried before concluding it wouldn’t work. That knowledge is not catalogued anywhere. It was held by him, and he gave it freely when asked, without making the person asking feel uninformed for not already knowing.

Several people in this organization have careers that exist because Howard invested time in them quietly - at the copy machine, after a difficult meeting, in a brief note that arrived when it needed to. He did not announce these investments. The people on the receiving end of them know who they are.

In moments of operational difficulty, his presence in a room changed the quality of the deliberation. Not because he commanded it, but because his steadiness functioned as a kind of calibration point. Others adjusted to it without being asked to.

What follows his departure is a management challenge as much as a cultural one, and it is worth acknowledging that directly. The institutional knowledge he carried cannot be retrieved from any document; it will be reconstructed slowly, through questions people ask and gaps they begin to notice. That is not a criticism of any succession planning that has been done. It is simply the nature of what he held.

The organization owes him a clean departure and a clear acknowledgment of what he brought. Both are offered here.

Marking the team shipping a hard, long project

The checkout rebuild reached general availability last week, and that moment warrants a clear and public statement: what this team achieved over fourteen months is one of the more significant engineering undertakings in this organization’s recent history.

It is worth naming precisely what was asked. The legacy system remained in production throughout - serving live customers while the new one was built alongside it. That is not a background detail; it is a constraint that multiplied the complexity of every decision and required the team to operate at double the operational surface area for more than a year. The final rollout held under peak load. That outcome was not coincidental. It was the product of sustained preparation by people who had been questioning their own assumptions since the earliest phases of the work.

While the schedule experienced two delays, and while two near-misses were caught before they reached customers, the record of how the team responded to those moments is itself part of what deserves recognition. The slips were absorbed and diagnosed. The near-misses were surfaced, not concealed. The pattern across both types of interruption was the same: the team identified the problem and adapted rather than shipping around it.

Priya Menon’s decision to hold the second launch date when a load test discrepancy remained open, and Daniel Owusu’s call to keep the legacy path warm through the peak period rather than accelerate the cutover - both of those were consequential choices made under genuine uncertainty.

The cart-abandonment problem that drove this project is now addressed. That is a durable result. It reflects work that cost the team considerably and was not visible from the outside. Both of those facts are worth stating directly.

Arguing a public position on return-to-office

The case for returning everyone to the office on a fixed schedule rests on something real. In-person time builds trust faster than any video call can, and the unplanned collision in a hallway that reshapes a product decision rarely survives a scheduling tool. Those who have led teams through sustained remote periods know firsthand what tends to erode: the informal calibration, the shared sense of what is urgent, the relationships that are easier to repair when both people are in the same room. That experience deserves to be taken seriously.

So does the case that runs the other direction. The flexibility to hire across cities and time zones widens who we can bring onto a team. Hours reclaimed from a daily commute are returned to people as genuine time. For work that requires deep, sustained focus, a quiet desk away from an open floor plan can be the most productive environment available. These are not minor conveniences; they bear directly on the quality and breadth of the work.

The position I am arguing is that both of these pictures are partly right, and a mandate at either extreme sacrifices the gains on one side to protect the instincts on the other. What the situation calls for is a deliberate hybrid: a small number of shared anchor days each week when the team is expected to be together in person, and the remaining days flexible by default.

Concerns have been raised, and reasonably so, that “hybrid” in practice often becomes a word that each person interprets differently until no shared norm exists. That risk is worth taking seriously - and the answer to it is specificity about which days are anchors, not abandonment of the model.

Announcing a new product to an outside audience

We recognize that most small teams today have developed their own approaches to collecting and acting on customer feedback - a shared document here, notes in the ticket tracker there, a thread in the chat tool that someone intended to revisit. These approaches reflect real investment, and the intent behind them is sound: to stay close to what customers actually need.

What has also become clear, through conversations with teams navigating this challenge, is that scattered inputs carry an accumulated weight. When feedback lives in several places, reaching agreement on what to build next can require more coordination than the decision itself warrants. That overhead, more often than any shortage of good ideas, is what creates delays.

Tidemark is a new tool designed to address that specific problem. It gathers customer feedback from the places where it already lives, organizes it into a single ranked list, and produces a roadmap that teams can share with anyone who needs to understand the plan - whether inside or outside the organization. It does not require changing where feedback is collected; it works with existing sources.

Tidemark launches next week. Teams interested in taking an early look are welcome to request access using the link below. We have set aside time specifically to answer questions before and after a first session, and we would be glad to use that time however is most useful to you.

If the timing is not right at the moment, we will continue to share updates as the product develops. We appreciate your consideration, and we look forward to the conversation.

A personal year-end reckoning with a difficult year

The year made its position clear enough: two things I had invested in did not come through, and there is no framing that changes the basic account. A project I had spent most of the year building - a digital archive for a nonprofit I will call Verdant - lost its funding and was discontinued by the board. A friendship with someone I will call Marcus shifted in ways neither of us chose and have not been able to reverse. Those are the facts, and it seems worth stating them plainly before anything else.

What is also worth acknowledging is that both losses were real losses, not misunderstandings about what was good. The archive deserved the effort the team put into it. That the board’s priorities moved elsewhere is a fact about the organization, not a verdict on whether the work mattered. I can hold both truths without resolving them: the work was worth doing, and it did not succeed.

The accounting with Marcus is harder, because some of what went wrong sits with me. There were points where I prioritized being right over being useful, and the friendship registered that. I am not certain I would have made different choices if I had full information earlier - which is uncomfortable to say, but more honest than claiming I simply lacked the chance to do better.

What the year asked of me was an endurance I am still taking stock of. What I am choosing to carry forward is narrower than I expected: one or two things I now know to be load-bearing, and a clearer sense of what careful effort cannot substitute for. That is not a resolution. It is closer to a working position.

Appears in diff-pairs

• diplomatic vs warm (varies tone)
• diplomatic vs warm (varies tone)
• diplomatic vs warm (varies tone)