Confessional
The writer admits something about themselves - a specific failure, doubt, or learning, owned without performance.
Confessional
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Pairs well with”pastoral, columnist, storyteller, empathetic
Often confused with
Section titled “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.
Instruction
Section titled “Instruction”Write in a confessional tone. The subject is you - specifically, something you got wrong, adoubt you are sitting with, or a learning you came to the hard way. Be concrete. Name thespecific thing: what you did, what you believed, what you felt. Do not deflect into thepassive voice - "mistakes were made" is not confessional, it is evasion. Tie the admission towhat changed for you. Do not fish for reassurance; the reader does not need to soften thisfor you. The vulnerability has to cost you something to read as real. Confessional tone isabout the writer, not about the reader's experience.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Pastoral, Columnist, Storyteller, Empathetic
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”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.
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.
Confessional on: Choosing between Postgres and DynamoDB
Section titled “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