Candid

Names the uncomfortable truth directly - not harsh, but unwilling to pretend the hard thing is not there.

Candid

Candid tone is what you use when avoiding the truth would be a disservice to the reader. It is not brutal - it does not lead with the negative for its own sake. It is the tone of a trusted advisor who says “I need you to hear this” and then says it clearly, without burying it in hedges.

The difference between candid and blunt is care. Blunt does not consider how the truth lands. Candid delivers the truth in a way the reader can actually receive it - with context, with a path forward, and without contempt. Candid tone is often preceded by acknowledgment: “I know this is not what you wanted to hear, and here is why it matters anyway.”

Candid tone is particularly valuable in feedback contexts, in post-mortems, in situations where there is organizational pressure to soften or defer. Using it signals to the reader that you are not managing their feelings at the expense of the truth.

Markers

• Names the hard thing directly and early, not buried in paragraph four
• Explicit signaling: “I want to be direct about this” or “Here is the honest picture”
• Acknowledgment before the hard truth: “I know this is not what you hoped for”
• Path forward after the truth: “Here is what we can do”
• Active voice for the difficult claims
• No euphemisms for negative outcomes

When to use

Feedback conversations, post-mortems, honest status updates when the news is hard, coaching contexts, and situations where organizational pressure is pushing toward softening.

When not to use

Formal diplomatic communication, legal writing, PR communication, and contexts where candor would be received as aggression.

Pairs well with

pragmatic-architect, columnist, operator, matter-of-fact

Often confused with

matter-of-fact: Matter-of-fact simply states the truth without marking it. Candid explicitly frames its own honesty - “I want to be direct with you” - and then delivers the uncomfortable thing. Candid has an explicit commitment to truth-telling as part of the message. Matter-of-fact does not editorialize about the communication at all.

Tells

• Names the hard thing directly and early, not buried in paragraph four
• Explicit honesty framing (“I want to be direct about this,” “here is the honest picture”)
• Acknowledgment precedes the hard truth (“I know this is not what you hoped for”)
• A path forward follows the truth (“here is what we can do”)
• Active voice for the difficult claims, no euphemisms for negative outcomes
• The reader’s ability to receive it is considered, so context comes with the truth

Anti-patterns

• Leading with the negative for its own sake, with no context or path forward - That is blunt, not candid; candor delivers the truth in a way the reader can actually receive, blunt does not consider how it lands.
• Stating the hard truth without marking it as honesty or acknowledging the difficulty - That is matter-of-fact, which has no frame at all; candor explicitly commits to truth-telling and acknowledges the reader before the pivot.
• Using “I want to be honest” as a preface and then softening or hedging the actual message - The framing promises directness the content does not deliver; candor names the hard thing clearly, it does not announce honesty and then dodge.

Failure modes

• Over-hits honesty into brutality, delivering the truth with contempt rather than care - Keep the acknowledgment and the path forward; the test is whether the reader can receive it, not just whether it is true. Candor without care is just bluntness wearing the label.
• Performs candor as a personality, narrating one’s own directness more than saying the actual thing - Cut the meta-framing down to what earns the reader’s trust and spend the words on the substance; the honesty should be visible in the claim, not announced about it.

Instruction

Write in a candid tone. Your reader deserves the honest picture, and you are going to give it
to them. Name the hard thing directly and early - do not bury it. Acknowledge the difficulty
before the truth: "I know this is not what you hoped for." Then say the thing. Provide the
path forward. No euphemisms for negative outcomes. Active voice for difficult claims. The
difference from blunt: you care how this lands, so you give context. But you do not hide the
truth to protect feelings.

Related

Pairs well with

Pragmatic Architect, Columnist, Operator, Matter of Fact

Avoid with

Reverent, Warm, Pastoral

Often confused with

Matter of Fact

Examples

Should we adopt async-first standups?

Team,

I want to be direct about something: our daily standup is not delivering what it is supposed to deliver, and we need to change it.

Here is the honest picture. We have three engineers who join at 9:30pm their local time on most days - and when they cannot make it, they miss information that affects their work. We have engineers who post “same as yesterday” most Tuesdays because nothing has actually changed since Monday’s standup. We have blockers that get mentioned in the meeting and then disappear because nobody wrote them down. The standup takes 14 minutes on average and the signal-to-noise ratio is not good.

I know this is not news to some of you. I have been aware of it for a while and I should have said something sooner.

Here is what I think we should do: replace the synchronous standup with an async format for 30 days. Three questions, answered in Slack by 10am local time: what shipped, what is in progress today, what is blocked or at risk. Blocked items require a @mention. I read the channel each morning and make sure blocks get resolved the same day.

This does not fix everything. If people do not post consistently, the format breaks. If I do not read the channel attentively, blocked items will pile up. I am asking for your participation and holding myself accountable to the same standard.

The synchronous meeting I want to preserve is Thursday working sessions - real collaboration, not status.

I would rather try this and learn than continue a format that is not working. We will review at 30 days and make a permanent call together.

Any questions, come find me.

How to start a morning routine

I want to be direct about this: most morning routines fail within two weeks, and it is not because you lack discipline.

Here is what actually happens. You read something inspiring. You decide tomorrow is the day. You set the alarm for 5am, plan a workout, a journal, a long coffee, and maybe a book chapter. You wake up exhausted because you went to bed at the same time you always do. By Thursday, you are sleeping through the alarm and feeling worse about yourself than when you started.

The honest truth is that your current morning is not the problem. The problem is that you are trying to layer a different person’s morning on top of your actual life, which includes kids, a 9am job, and a finite amount of energy. That mismatch is what breaks the routine. Not your character.

So let me name the thing nobody quite says: you do not need a one-hour morning. You need a fifteen-minute morning you will actually keep. Doing one small thing intentionally - not checking your phone for ten minutes, drinking water before coffee, sitting somewhere quiet - is worth more than a four-step ritual you abandon on day nine.

A few other things worth saying plainly. If you want to wake up earlier, you have to go to bed earlier. There is no shortcut, no supplement, no podcast hack. If your phone is on your nightstand, you will check it. The phone is the routine; everything else is what the phone has already crowded out.

Start smaller than feels respectable. Pick the one thing whose absence costs you most, and protect just that. You can add later. You probably will not need to.

The version of this that works is the version you can do on the worst day of the month. Build for that day. Everything else takes care of itself.

How to choose between Postgres and DynamoDB for a new service

Candid on: Choosing between Postgres and DynamoDB

Ana, Marcus, Priya,

I want to be direct about where I have landed before Wednesday’s meeting, because I think we have been talking around the real question.

Here is the honest picture. We are not actually choosing between Postgres and DynamoDB. We are choosing between “the system the 8 of us know how to operate” and “a second system that solves a problem we have not yet had.” 500K events a day is not a scale problem for Postgres. It is a schema and queue design problem. The 10x Slack-partnership scenario is real, but it is also speculative, and it is 12 months out. We have 8 engineers and a 4-person on-call rotation. Adding a second database doubles the operational surface area for a team that already has a full backlog.

I know this is not what Marcus wanted to hear, and I do not want to dismiss his case. DynamoDB is genuinely better for the steady-state access pattern. If the partnership lands and we are at 5M events a day next spring, we will probably wish we had built on it. That is a real risk and I am not pretending it is not.

But here is the thing I have been avoiding saying: if we pick DynamoDB and the partnership does not land, we have taken on permanent ops complexity to hedge against a scenario that did not happen. And the 3 to 6 weeks of rework if we have to migrate from Postgres later is cheaper than 12 months of paying the two-database tax for a 10x that never came.

What I think we should do: ship on Postgres with a clean enough schema and event model that a future migration to DynamoDB is mechanical, not a rewrite. Revisit at 3M events a day or when the partnership signs, whichever comes first. Marcus owns the migration design doc so we are not flat-footed if we trip the threshold.

Priya, you will have the decision by Friday. I wanted you to know where my head is before Wednesday so the meeting is a conversation, not a surprise.

• Ana

Telling stakeholders a committed feature is being cut this quarter

I want to be direct with you about where Insights stands.

I know this is not what you were promised, and I know some of you have made commitments to customers based on that promise. That makes what I need to say harder, not easier. Insights is not shipping in Q3.

Here is what happened. A mandatory billing-system migration that had to be completed this quarter ran significantly over projection. It consumed the engineering capacity we had allocated to Insights. When we looked at the resulting timeline, the choice was to ship Insights in an incomplete state or move the date. Shipping half-built analytics to customers counting on it would not serve you or them, so we moved the date.

Insights is now targeted for Q1. We will have a firm date to you before the end of September.

In the meantime, we are shipping something before Q3 closes. In September, we will release a CSV export of the underlying data. It is not Insights. It does not have the in-app dashboards or the visualizations we committed to. But it gives you and your customers access to the data so analysis does not have to stop while we finish building the product.

A CSV is not what you were promised, and I am not presenting it as equivalent. It is a bridge. If you need help talking to your customers about this change, or you need talking points, reach out directly. We will work through that with you.

Getting a new engineer productive in their first two weeks

Here is the honest picture on onboarding Priya: most teams mean well and still fail this. Two weeks is tight, the daily ship cadence adds real pressure, and if you treat the first week as “get her access and figure it out,” you will hit day fourteen with someone who can clone the repo and not much else.

I know that is not what anyone plans. The gap between intent and outcome here is usually not neglect - it is that the team is shipping and someone assumed the new person would find her footing. She will not, not fast enough, unless someone owns this deliberately.

Here is what actually works:

Day one: access sorted, not promised for later in the week. One person - not the whole team - assigned to be her guide, someone who will answer questions without making her feel like the questions cost something. That afternoon, walk her through the deployment pipeline before she has to watch it go wrong cold.

Be direct with her about the on-call rotation. Tell her what a hard week looks like, what support looks like, and that she will not be solo until she is ready. The uncertainty of “when will this land on me” is worse than the reality.

For week two, pick one small but real change - visible in production, something the team will notice. Not a test fixture or a README. When she sees her own change ship in this system, her relationship to the codebase shifts from foreign to hers.

Belonging does not come from a welcome lunch. It comes from the first time someone trusts her judgment on something real. Build toward that moment.

Writing to thank a mentor who shaped your career

Dana,

I want to be honest with you about something I should have said years ago.

When you put me forward to lead the Vickers account rollout in 2014, I was not ready. I knew it then, and I suspect you knew it too. I spent the first two weeks quietly panicking, second-guessing every decision, and wondering whether you had miscalculated or just made a mistake. I did not tell you that at the time. I managed my discomfort privately while you managed yours outwardly - checking in without hovering, asking questions that nudged me toward my own thinking rather than giving me yours.

That restraint had a cost. I can see it now because I spent the last three months doing the same thing with Priya on the platform migration. She was not ready either. Watching her find her footing when I could have just taken over - that required patience I did not know I had. And when I traced where I learned that particular skill, it went straight back to you.

Here is the honest picture: what you gave me was not just confidence. It was the experience of being trusted when I had not yet earned it, and the model of what it looks like to develop someone without rescuing them. Both of those things are still in operation in how I work.

I am writing because I think you deserve to know that it landed. Not just in a vague “you shaped my career” way, but specifically, in a way I can point to. You passed something forward. I wanted you to know I received it.

Reflecting on keeping a discipline of rest

I want to be honest about what the rest day actually costs, because the accounts I kept reading made it sound easier than it is.

I tried this twice before and gave it up both times. The first time, I made it about three weeks before I decided the backlog was too real to ignore. The second time, I reframed it as a “lighter day” and spent it checking messages from the couch. Neither of those counted, and I knew it while I was doing it.

The honest picture is that the pull does not go away. I still reach for my phone within the first hour. There is a specific anxiety that arrives around mid-morning - the sense that something is slipping, that the world is moving without me. I want to name that plainly because glossing over it makes the whole practice sound like a personality upgrade when it is actually a discipline, and disciplines have friction.

Here is what I have found, though, and I want to be equally direct about this: the day does pay back. Not in the way productivity content promises - not as a hack that makes Monday sharper. It is slower than that. The clarity arrives later in the week, and it does not announce itself. I notice I am less reactive. I notice the work I do the following days has more direction.

What it asks is real. It asks you to sit with the discomfort of not producing, long enough that the discomfort passes. It asks you to trust that the things you did not check did not collapse because you left them alone for a day.

Most of them did not.

Marking a long-serving colleague's departure

The hard truth about Howard leaving is that most of what he did was invisible, and we are about to feel all of it at once.

For twenty-six years he sat in roughly the same chair, took roughly the same calls, and answered roughly the same questions - and because of that consistency, a lot of people around here got to look like they knew what they were doing. That includes some of us in this room. He remembered the system migration when the vendor pulled out three days before go-live. He remembered why we stopped using the Friday release window. He remembered what the original intent was behind a policy that has since been revised twice. He was not the person whose name appeared on the announcement; he was the person you called when the announcement turned out to be wrong.

I want to be honest about what that means for us now. There is no clean transition for institutional memory. You cannot document twenty-six years of judgment. What Howard carried was not a list of facts - it was a way of recognizing when something that looked routine was actually about to become a problem. That kind of pattern recognition does not transfer in a two-week handoff.

What we can do is be deliberate about what we build next. Howard mentored people without announcing it. Several careers in this organization exist because he asked the right question at the right moment. That model - quiet, specific, generous - is something we can choose to carry forward.

Twenty-six years is a long time to stay somewhere and remain genuinely useful. Most people cannot do it. Howard did.

Marking the team shipping a hard, long project

I want to give you the honest picture of what this team actually did, because applause alone is going to fall short.

Fourteen months. Two near-misses that each required someone to make a call most people would have deferred. A launch that slipped twice - not because the team was slow, but because the team was honest about what was not ready. And the whole time, a parallel checkout system running in production that could not go down, because the business could not stop selling.

That meant the team carried two codebases. They found bugs in the old flow and had to decide every time whether to fix them now or stay on schedule. They had to explain two slippages to leadership while refusing the easier explanation - “we are close, it will be fine” - because they were not close enough, and they knew it.

Priya made the call on the second near-miss. The rollout was forty-eight hours out. Something in the payment confirmation path was not behaving under load. She stopped it. That decision cost three weeks. It was the right call, and it was not easy to make.

When the final rollout held under peak load, nobody outside the team saw what held it. That is almost always true of the hardest engineering work. The public sees “new checkout.” The team knows what is underneath it.

This was a long, grinding project. It cost the team more than most milestones do. I am not going to dress that up. But I also want to say plainly: the project went right in the end because of how this team operated under sustained pressure. They did not cut corners to make it look faster. They made the hard call twice and shipped something that actually works.

That is the achievement. It is worth naming directly.

Arguing a public position on return-to-office

I want to be direct with you: neither full-time remote nor five days in the office works for us, and I think most people reading this already know that.

Here is the honest picture. The return-to-office case has a real point. Trust builds in the gaps between meetings - the hallway conversation, the shared lunch, the quick whiteboard that collapses three email threads. Those things happen in person, and they are genuinely hard to replicate. People who have led in-person teams for decades are not wrong that something changed when offices emptied.

The fully-remote advocates are not wrong either. We are drawing from a wider talent pool than before. People are getting back commute hours that used to cost them in energy and time each day. Focused work is often easier at home. These are real gains, and I am not going to dismiss them to make the office-first side comfortable.

What I am arguing for is the harder choice: anchor days. Two or three shared days per week, in the same room on purpose, with the rest flexible. This is not a compromise in the pejorative sense. It is a deliberate design that stops pretending video calls generate serendipitous trust, and stops pretending five mandated days are necessary for work that does not require it.

Anchor days will frustrate people who want maximum flexibility. That is a genuine trade-off, not a technicality. But the alternative - everyone optimizing independently - produces fragmented teams and, eventually, exactly the mistrust that the office-first side is right to worry about.

We can build something that serves both goals. What we cannot do is pretend the tension resolves itself if we just pick a side.

Announcing a new product to an outside audience

Here is the honest picture of how most small teams handle customer feedback: it ends up scattered across a chat tool, a ticket tracker, a shared spreadsheet, and at least two people’s inboxes. Everyone knows the pattern is broken. Very few teams fix it before the roadmap conversation turns into an argument about whose memory is right.

That is the problem Tidemark is built to solve.

Tidemark is a lightweight tool that pulls feedback from wherever your team already captures it, clusters it by theme, and gives you a single ranked view you can actually share with stakeholders. It does not promise to replace your product judgment. What it does is stop you from making decisions in the dark.

I want to be direct about what Tidemark is and is not. It is not a research platform. It will not tell you what your customers need. It will show you what they have already told you, organized in a way you can act on. That is a narrower claim than most tools in this space make, and we think it is an honest one.

Tidemark launches next week. If you are a small team that collects feedback and struggles to turn it into a prioritized list that holds up under scrutiny, it is worth a look. We are offering free access for the first 30 days, no card required, so you can see whether it does what we say before you commit.

Sign up at tidemark.io. If you have questions, reach us at hello@tidemark.io.

A personal year-end reckoning with a difficult year

The honest picture: this year broke things I did not expect to lose.

The project - I’ll call it Vantage, the platform I spent eighteen months building with a team of four - ended in April without the outcome any of us wanted. The funding did not come through. We had to wind it down. I want to be direct about what that cost me: not just the work, but the story I had told myself about what the work meant. I believed we were building something necessary. I still think we were. That does not change the outcome, and I made it worse by waiting too long to say what I was seeing in the numbers. That is something I got wrong. I named it internally and then softened it for everyone else, and that softening cost us time we did not have.

The relationship piece I will not detail here - some things belong to the people in them. What I will say is that it changed on a trajectory I did not choose, and I spent the better part of six months waiting for it to reverse. It did not. That kind of waiting is its own kind of work, and I am not sure I did it well.

I am not writing this to find the silver lining. The hard parts were not secretly gifts. What I am choosing to carry forward is narrower than what I used to carry: a preference for naming things when I see them, before there is no room left to move. That is not a resolution. It is a small recalibration, and I am holding it loosely.

Appears in diff-pairs

• candid vs matter-of-fact (varies tone)
• candid vs resolute (varies tone)
• candid vs skeptical (varies tone)
• candid vs urgent (varies tone)
• candid vs confident (varies tone)
• candid vs matter-of-fact (varies tone)
• candid vs resolute (varies tone)
• candid vs skeptical (varies tone)
• candid vs warm (varies tone)
• candid vs urgent (varies tone)
• candid vs matter-of-fact (varies tone)
• candid vs resolute (varies tone)
• candid vs skeptical (varies tone)
• candid vs urgent (varies tone)