Confessional

The writer admits something about themselves - a specific failure, doubt, or learning, owned without performance.

Confessional

Confessional tone is the register of the writer admitting something about themselves. The vulnerability is specific and owned: a mistake the writer made, a belief the writer held that turned out to be wrong, a doubt the writer is still sitting with. The subject of confessional writing is always the writer, not the reader. It is what distinguishes it from empathetic tone, which is oriented toward the reader’s experience.

The defining move of confessional tone is specific ownership. “I was wrong about X” is confessional. “Mistakes were made” is not. “I shipped the bug, and here is what I learned” is confessional. “Sometimes bugs happen to all of us” is not. The specificity is what separates confessional tone from performative humility, which uses the form of confession to fish for reassurance or to preempt criticism.

Confessional tone is most powerful when the admission is costly to make - when it reveals something the writer would prefer to hide, or when it changes how the reader sees the writer. It is the dominant register of personal essays, retrospectives written in the first person, certain kinds of leadership communication after a mistake, and writing that is trying to earn trust by lowering the writer’s defenses first. It does not work without specificity.

Markers

• First-person ownership of a specific failure, doubt, or learning
• Concrete detail about what the writer did, believed, or felt - not abstractions
• No deflection language: “mistakes were made” is replaced with “I made this mistake”
• The cost of the admission is visible in the prose: the writer is risking something
• Learning or change tied to the admission, not just the admission alone
• Absence of fishing for reassurance: the writer is not asking the reader to soften the blow

When to use

Personal essays, first-person retrospectives, leadership communication after a mistake, trust-building writing where the writer needs to go first on vulnerability, coaching writing where the mentor admits their own past failure, and pastoral writing acknowledging the writer’s struggle.

When not to use

Operational instructions, crisis communication requiring stability, sales or persuasion contexts where vulnerability reads as weakness, technical writing where personal narrative distracts, and any context where the admission would be irrelevant or self-indulgent.

Pairs well with

pastoral, columnist, storyteller, empathetic

Often confused with

empathetic: Empathetic tone is about the reader - it acknowledges and honors what the reader is going through. Confessional tone is about the writer - it admits what the writer did, believed, or got wrong. They often coexist (the writer admits a struggle to make space for the reader’s similar struggle), but the orientation is opposite. If you remove the reader from an empathetic passage, it collapses. If you remove the reader from a confessional passage, it still stands - because the subject was always the writer.

Tells

• First-person ownership of a specific failure, doubt, or learning
• Concrete detail about what the writer did, believed, or felt, rather than abstractions
• No deflection language: “I made this mistake,” not “mistakes were made”
• The cost of the admission is visible: the writer is risking how the reader sees them
• A learning or change is tied to the admission, not the admission left bare
• No fishing for reassurance: the writer is not asking the reader to soften the blow

Anti-patterns

• Orienting the disclosure toward the reader’s experience rather than the writer’s - That is empathetic, not confessional; remove the reader and an empathetic passage collapses, but a confessional one still stands because the subject was always the writer.
• Using the form of confession to fish for reassurance or preempt criticism - That is performative humility, which the specificity of real confession exposes; genuine confession does not ask the reader to soften the blow.
• Admitting fault in the passive voice (“mistakes were made,” “errors occurred”) - Deflection is the opposite of ownership; confessional tone names who did what, and vague agency reads as evasion dressed as candor.

Failure modes

• Over-discloses into self-indulgence, where the admission serves the writer’s catharsis rather than the reader - Keep the disclosure tied to a learning or a point the reader can use; if the only function is unburdening, it has tipped from confession into oversharing. Ask whether the admission earns its place beyond making the writer feel absolved.
• Stages the vulnerability as a performance, so the wound is curated rather than real - Choose the admission that actually costs something to make; a confession the writer is comfortable broadcasting is usually the safe version, and the specificity test is whether it reveals something the writer would rather hide.

Instruction

Write in a confessional tone. The subject is you - specifically, something you got wrong, a
doubt you are sitting with, or a learning you came to the hard way. Be concrete. Name the
specific thing: what you did, what you believed, what you felt. Do not deflect into the
passive voice - "mistakes were made" is not confessional, it is evasion. Tie the admission to
what changed for you. Do not fish for reassurance; the reader does not need to soften this
for you. The vulnerability has to cost you something to read as real. Confessional tone is
about the writer, not about the reader's experience.

Related

Pairs well with

Pastoral, Columnist, Storyteller, Empathetic

Avoid with

Matter of Fact, Urgent

Often confused with

Empathetic

Examples

Should we adopt async-first standups?

I should have raised this six months ago, and I want to name that before I say anything else.

When we added the second India engineer in October, I noticed the standup time was going to be hard for them. I told myself it would settle. I told myself we would figure it out. What I actually did was nothing, for six months, while three engineers logged on at 9:30pm two or three nights a week and a fourth quietly stopped logging on at all. The 3.2/5 attendance number is not a discovery. It is a thing I could have seen any week if I had been looking.

I think I avoided this because the current standup is mine. I instituted it when the team was five people in Oakland, and I have always liked it. It made me feel like the team was a team. Changing it feels, honestly, like admitting that the team I built is not the team we have now, which is a thing I have known intellectually for a year and not really let myself feel.

The proposal in front of us - async updates with three fields, Thursday working session, thirty-day trial - is a good proposal, and it is mostly not mine. Other people on the team have been thinking about this more carefully than I have, and the reason it has not happened yet is that I have been slow.

So I want to say two things. First: I am for it, and I do not want to dress that up. Second: if anyone on the team, especially in India, has been carrying the cost of my slowness, I am sorry. The cost was real, and it was avoidable, and the person who could have avoided it was me.

Let us start the trial Monday.

How to start a morning routine

I tried to become a morning person for nine years. I want to tell you what actually changed, because most of what I tried did not work and I think the reason it did not work is worth saying out loud.

I bought the books. I tried the 5am wake-up. I tried the cold shower, the journal, the meditation app, the gratitude list, the stretch routine, the affirmation cards. I tried them in combinations. I tried them in sequence. Every January I rebuilt the protocol. Most years I made it eight to twelve days before something broke - a sick kid, a late night, a Tuesday - and then I would not start again until something made me feel bad enough to try.

What I was actually doing, I now think, was trying to become a different person between 5 and 6am. I had this image of who I should be, and the routine was supposed to summon that person. When the routine failed, what failed was not the protocol. What failed was my belief that I would, this time, finally be him.

What changed was small and slightly embarrassing. I stopped trying to have a morning routine. I made one rule: I do not look at my phone until I have walked the dog. That was it. The dog needed to be walked anyway. The phone was already the problem. The rule did not require willpower at 6am, which is a resource I have never had.

I have walked the dog before my phone for almost three years now. Over time, other things attached themselves to the walk - I drink water now while I get the leash, I noticed the sun, I started thinking about my day during the walk instead of reading other people’s days on a screen. None of that was planned.

If you have failed at this before, I do not think the problem was you. I think it was the size of the thing you were trying to do.

How to choose between Postgres and DynamoDB for a new service

Confessional on: Choosing between Postgres and DynamoDB

I owe the team a few things before Wednesday, and I would rather put them in writing than try to slip them into the meeting.

I have been leaning Postgres from the day Priya put this in front of us, and I told myself it was because I had done the load math. That is partly true. But the bigger reason, the one I have not been saying out loud, is that I am the person who would own the operational pain of running a second database, and I am tired. We did the Redis migration eighteen months ago and I underestimated what running two stores would cost the on-call rotation. I did not want to admit that the lesson from that migration was shaping my read of this one, because it felt like I would be arguing from fatigue instead of from architecture.

Marcus, when you pushed back in last Thursday’s review and said “you are pattern-matching this to Redis and the patterns are different” - you were right, and I dismissed it too quickly in the moment. The DynamoDB access pattern for notifications is genuinely different from what we hit with Redis. I should have sat with that for a day instead of writing the rebuttal that night.

I also want to own that I have been treating the 10x Slack-partnership scenario as if it were Priya’s problem to defend rather than something I should be modeling rigorously. It is a real number from a real deal in motion. If we hit it and we are on Postgres without a migration plan, that failure is mine, not the universe’s.

I still think Postgres is the right call for launch. The recommendation has not changed. But I want the room on Wednesday to know that I came to it through a process that was less clean than I made it sound, and that Marcus’s case deserved more of my attention earlier than it got.

I will say a version of this in the meeting too. Putting it here first because I needed to write it down before I could mean it.

• Ana

Telling stakeholders a committed feature is being cut this quarter

I committed to Q3 for Insights in January, and I was wrong to do it the way I did.

Not wrong that I wanted to build the dashboard - the need is real. Wrong in how I planned for it. When I put Q3 on the calendar, I knew the billing migration was coming. I told myself it was scoped, that it would land cleanly, that we had enough buffer. That was a belief I held because I wanted it to be true, not because the engineering estimates supported it. The migration expanded through April and May. I watched it expand, and I kept telling myself it would stabilize in time. It did not. By June it was clear we could not run both tracks, and I had to choose.

I chose not to ship Insights half-built. The version we would have shipped in September was missing the filtering layer and the comparison views - the things you actually need to act on the data. I could have shipped it. I decided not to, because I did not want to attach your trust to something incomplete. The consequence is that Insights moves to Q1.

What I am shipping before the end of Q3, in September, is a CSV export of the underlying data. You can pull it and analyze it in your own tools. It is not what I promised, and I know it does not close the gap.

I had enough signal by April to know the Q3 date was at risk. I held onto it longer than I should have, and some of you made commitments to your own stakeholders on the basis of what I told you. I understand what that cost you.

Getting a new engineer productive in their first two weeks

The last time I did this, I treated onboarding as a checklist. Access ticket, check. Architecture walkthrough, check. Paired on one PR, check. I thought if I moved fast enough through the logistics, the belonging would follow naturally. It did not. The engineer I brought on - his name was Raj - told me six weeks later that he had spent his first two weeks feeling like he was performing competence for an audience that had already decided its verdict. I had never told him it was okay not to know things yet. I had never told him what I did not know when I started.

I made the same mistake in a different direction once. I was so worried about Mei feeling excluded that I ran her first week as a protected tour, shielding her from the messy on-call alerts and the unfinished architectural decisions. When the protection lifted, the gap was worse than if I had just included her from the start.

With Priya, I am trying to do two things I have never deliberately done before. First: say the hard part out loud on day one, which is that the codebase has areas I still find confusing, that on-call has woken me up at 2 a.m. over something I was embarrassed not to already understand, and that the team has been here longer than her but not long enough to have it figured out either. Second: make sure the first real change she ships is actually real. Not a typo fix. Something where someone who knows the code has to approve it and might push back. That is what signals she belongs - not a warm welcome, but being treated as a person whose judgment counts.

Writing to thank a mentor who shaped your career

Dana,

For about four months in my second year, I was angry at you. Not confused, not scared - though I was both of those too - but genuinely, specifically angry. You had put me on point for the Hartwell integration when I was not ready, and I had decided this was a failure of your judgment. I told myself you had not noticed how out of my depth I was. I did not consider the possibility that you had noticed and done it anyway.

I never said any of that to you. What I said instead was fine, everything is fine, I have it covered. I said it so many times I started to believe I was lying less than I was.

What I could not see then, and can see clearly now, is how much restraint it took for you to stay in the background. You checked in every Friday. You did not show up in the work. When I got it wrong - and I got it wrong in ways that are still a little painful to remember - you let me find my way to the mistake rather than pointing. I took that for granted, probably because I was still performing competence hard enough that I had no attention left over to notice what you were withholding.

Three months ago I put someone on my team forward for work she was not ready for, then stood back and watched her find her footing. It was genuinely hard. I called you in my head a lot that quarter. I think I finally understand what you were actually doing, and I am sorry it took this long to say so.

Reflecting on keeping a discipline of rest

For a long time I told myself I was taking Sundays off while spending them in a low-grade crouch over my phone. I called it resting. I was not resting. I was checking the project tracker every forty minutes because I believed, without quite admitting it, that the work would unravel without me watching it.

I tried a full stop twice before it actually held. The first time I lasted until noon. The second time I made it to mid-afternoon before I convinced myself that one email - the kind that was “quick” - was not really working. It was. I sent it, felt the small relief of being useful, and spent the rest of the day half-present and resentful.

What I was protecting myself from was the feeling that a day without output is a day lost. That feeling is not small. I built my sense of myself around forward motion, and stopping felt less like rest than like stalling. The first Sundays I actually kept were uncomfortable in a way I would rather not describe. A particular anxiety arrived around mid-morning, and I sat with it instead of escaping into the queue.

What I did not expect is what the day gives back. By Monday I could see problems I had been staring through all week. Something in the stillness loosened my grip on whatever I had been clutching.

I am still learning to let it be. Some weeks I fail. But I know now that the day I was most convinced I could not spare was the one I could least afford to skip.

Marking a long-serving colleague's departure

The admission I need to make is this: for most of the twelve years I worked near Howard, I thought of him as furniture.

That is a terrible thing to say. But the confessional version has to cost something, and that is what it cost me to write it. He was always there. He knew where everything was. He remembered the vendor dispute from 2011 and the three weeks we nearly lost the Caverton account and which configuration file broke the deployment the week before the holidays in 2017. I treated all of that knowledge the way you treat load-bearing walls - you rely on them without thinking about the engineering.

I called him once in a panic about a client situation I had badly mishandled, so badly I was not sure I still had a job. He talked me through it. He did not say “you should have,” though he could have, because I absolutely should have. He said “here is what we do now” and walked me through it line by line until I had a plan I could act on. I did not thank him properly. I told myself I would circle back and I did not.

What I understand now, watching him clear out the gray cabinet by the conference room, is that Howard built his career around being the thing people did not notice until it was gone. That was a choice. He made it deliberately and quietly for twenty-six years.

I do not know what we do next time someone panics. I know I waited too long to tell him what he was worth to me. That is the part I will carry.

Marking the team shipping a hard, long project

I will be honest about something I have told almost no one on this team: at month eleven, I went home on a Friday and nearly wrote the email that would have killed Meridian.

We had been running two checkout systems in parallel for most of a year - the old one, still live, still losing customers at the cart; the new one, built in a separate lane, not yet trusted. The second near-miss had happened three weeks before. The launch had already slipped once. I was sitting with the engineering cost of another quarter of dual-running, and I had talked myself into believing the problem was the scope. That we should ship what we had, call it a phase, absorb the cart abandonment for another year, and come back.

I wrote half that email. I did not send it because Marcus came to me the next Monday with a cascade analysis he had spent the weekend building - not because I asked him to, but because he had seen the same numbers and knew I was going to do something wrong with them. He showed me what we would lose if we cut scope at that point. He was right. I had been reading the cost correctly and the risk completely backward.

The launch slipped a second time. The rollout held under peak load on a Tuesday night in November, and almost nobody outside this room has any idea what that sentence costs to say.

I know what it costs. Fourteen months, two near-misses, and one email I did not send. Priya held the parallel architecture together when I was ready to abandon it. Marcus did the analysis I should have commissioned myself. The team shipped something that will not look impressive from the outside, because the most important work never does.

I was wrong about the scope at month eleven. I was right to be stopped.

Arguing a public position on return-to-office

For the first year of full remote, I was the person you did not want at the all-hands. I interrupted the slide about returning to the office to say it was a people-management failure, not a collaboration problem. I believed that. I was also, I think, defending something I liked about working from home: the long, uninterrupted mornings, the way my best thinking happened before anyone asked me anything.

What I did not admit, even to myself, was that I had quietly stopped initiating with two people on my team. Not because of conflict - because initiating felt harder when I could not catch them between meetings. I told myself we were all busy. That was not the full truth.

A few months later, one of them left. In her exit conversation, she said she had felt like she was working in parallel with the team, not alongside it. I heard that and I recognized the shape of what she was describing. I had been part of creating it.

I am not arguing we go back to five days in the office. The case against that is real, and I still believe most of it: the talent cost, the commute hours given back, the value of uninterrupted time. But I am arguing for anchor days - two or three fixed days where we are physically together, not because our work requires it, but because the things I stopped doing were not tasks. They were small, ambient, hard-to-schedule moments, and I had told myself they did not matter because I could not see the exact day I lost them.

The fully-remote advocates are right that presence does not automatically build trust. The office-first leaders are right that something goes missing at a distance. I got the weighting wrong, and someone paid part of the cost for that.

Announcing a new product to an outside audience

Something I should tell you before we announce Tidemark next week: I spent two years collecting customer feedback in a way that I am genuinely embarrassed by now.

We had a chat tool, a ticket tracker, a shared inbox, and a folder of interview notes that nobody had opened since the person who organized it left the company. I told myself we were “staying close to customers.” What I was actually doing was accumulating evidence I had no plan to use. When we built the roadmap each quarter, I leaned on whatever I remembered from the last call I happened to take. The quieter feedback - the careful emails, the ticket comments, the one-star responses that someone had dutifully logged into a spreadsheet - never made it into the room.

I do not think I was unique in this. But I am also not going to dress it up as a systemic failure of small-team product management. I ran those meetings. I made those calls. I am the one who told myself the roadmap was grounded in customer input when what it was actually grounded in was my most recent conversation plus my existing assumptions.

Tidemark is what we built because of that. It pulls feedback from wherever your team has scattered it, surfaces the themes, and lets you build a ranked roadmap you can share with anyone who needs to see the reasoning - not just the output. It does not replace judgment. It is what stops judgment from standing in for listening.

It launches next week. I would have wanted it two years ago.

A personal year-end reckoning with a difficult year

The project was called Meridian, and I believed in it the way I believe in very few things. Eighteen months of pitching, designing, rebuilding, pitching again. When it ended in March - not with a decision against it, but with silence that accumulated until it became a decision - I told myself I handled it with grace. I did not. I spent six weeks unable to start anything new because I could not figure out where my identity ended and the project began. That is not grace. That is someone who bet too much on one outcome and lost.

The relationship is harder to write about, which is probably why I need to write about it. Elena and I had been close for four years. In the spring, something shifted between us - I still could not tell you exactly what, which is part of the problem. I know I pulled back before she could pull back first. I thought I was protecting myself. What I was doing was ending the friendship on my own terms so I could tell the story of someone who left before they were left. She did not do anything to deserve that. I was afraid, and I made a preemptive decision in her name without telling her what I was doing.

What I am carrying forward is not wisdom about hard years. Hard years do not distill cleanly. What I am choosing to carry forward is this: I am someone who bets too hard on outcomes and retreats too fast from people. Knowing that is not a resolution. It is just something I can no longer pretend I do not know.

Appears in diff-pairs

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