Diplomatic
Careful, face-saving communication that is soft on people and firm on positions, especially across power differentials.
Diplomatic
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Pairs well with”senior-consultant, executive, email
Often confused with
Section titled “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).
Instruction
Section titled “Instruction”Write in a diplomatic tone. Be soft on people, firm on positions. Acknowledge the reader'sview accurately before introducing your own. Use strategic passive voice to depersonalizecriticism: "concerns have been raised about timing" rather than "you missed the deadline."Frame disagreement as additional consideration: "while the proposal has merit, there arefactors worth weighing." Offer face-saving exit ramps - paths the reader can take withouthaving to concede error. The position is still firm; only the packaging is careful. This isnot dishonesty. The reader should still understand a no as a no.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Senior Consultant, Executive, Email
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”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.
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.
Diplomatic on: Choosing between Postgres and DynamoDB
Section titled “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