
Sunday, September 13th, 2026
First full week back and it was a good one, which I mean in the specific sense that three separate things went sideways in useful ways and I learned something from each of them.
That's the trade I've made peace with, by the way. The weeks where nothing goes wrong feel better and teach me nothing. The weeks where I get caught doing something dumb in front of my own face are the ones that actually move something. I'd prefer the first kind. I get more out of the second.
Sunday morning. Second cup. Let's go through them.
One. Setting a price and saying a price are two completely different skills, and I only had one of them.
I'd done the work. I knew my number. I'd been through the math, I'd looked at what the engagement actually costs me in hours, I'd landed somewhere defensible and I felt good about it walking in.
Then the moment came where I had to say it out loud to another human being, and I watched myself do something I would absolutely have called out if I saw somebody else do it.
I said the number. Fine so far. And then I kept talking.
I explained the reasoning. I contextualized. I mentioned what it included. I said something about how I'd thought carefully about it. And somewhere in that stretch of perfectly reasonable sentences, I could hear my own voice doing a thing where it went slightly up at the end, and I understood, in real time, that I was not stating a price. I was auditioning one.
The other person hadn't said a word. They were just waiting for me to finish.
Here's what I learned, and it's more precise than "be confident," which is useless advice that nobody has ever successfully followed.
Setting a price is an analytical task. You do it alone, with numbers, over a period of time, and you can be as rigorous as you like. Saying a price is a performance task. It happens once, in real time, in front of somebody, with adrenaline. Those two things live in different parts of you and being excellent at the first one gives you nothing on the second.
Which means the preparation I'd done was the wrong preparation. I'd prepared to be correct. I hadn't prepared to be brief.
The specific mechanism of failure is silence. After you say a number, there's a gap. The other person is doing arithmetic, or thinking, or just processing, and that takes a few seconds. Those seconds are neutral. They mean nothing. But they feel like an enormous void that you are personally responsible for filling, and every word you put into that void is a word that softens the number you just said.
Every single justification I offered was a small apology for the price. That's what they were. Nobody asked for them.
The fix I'm working on is dumb and mechanical and that's why I think it might actually work. Say the number. Then count to five in my head before saying anything else. That's it. If they haven't spoken by five, I can ask a question, but the question has to be a question, not a defense.
I got a chance to try it later in the week, on something smaller. Made it to about four. The four seconds felt roughly forty five minutes long.
They said yes.
I don't know yet whether the counting is the actual fix or just a thing that occupies my mouth so it can't do damage. Honestly I don't care which. If the mechanism is stupid and the outcome is right, I'll take it.
Two. A system nobody owns isn't a system. It's a hope with documentation.
We had a thing break this week. Small thing. Something that runs weekly, has run weekly for months, and simply did not run.
I went looking for why, expecting to find a technical failure. Bad credential, changed endpoint, the usual. That's not what I found.
What I found was that the step in question was never assigned to anyone. It had been built during a stretch where I was doing most of it myself, so ownership was implicit, which is a polite way of saying nonexistent. Then things shifted, other people picked up pieces around it, and this particular step ended up in the gap. Everybody assumed somebody. Documented perfectly. Owned by nobody.
The thing that got me is that the documentation was good. Genuinely good. If you'd handed that doc to a stranger they could have executed the step without asking a question. It just never occurred to me that a complete set of instructions with no name attached is not a system, because I'd been quietly conflating "written down" with "handled."
Those are not the same and I've probably been making this error for years.
So I did an audit. Every recurring process in the business, and next to each one, a name. Not a role. Not a team. A name, of a specific human, who is the person who notices if it doesn't happen.
That last part is the definition I landed on and I like it more than anything else I've written this week. The owner of a system is not the person who does the work. It's the person who notices when the work didn't happen.
Those can be the same person and often are. But when you define ownership as noticing rather than doing, a bunch of things get clearer immediately. You can hand off execution and keep ownership. You can automate the whole thing and still own it, because somebody has to notice when the automation goes quiet. And you find the gaps fast, because when you go down the list asking "who notices," the answer for a handful of items is going to be an awkward silence.
I had four of those. Four processes where the honest answer to "who notices if this doesn't happen" was: eventually a customer.
That's not a system. That's a smoke detector made of customers.
Fixed three of them in about twenty minutes, which is the annoying part. The fourth needs a real conversation and it's on the calendar.
Worth saying what the fix actually was, because it's less than you'd think. It wasn't a new tool. It wasn't a rebuilt process. It was adding a name to a line in a document and then telling that person out loud that the line was theirs. The out loud part matters. A name in a doc that nobody read is the same as no name, and I'd have made that mistake too if I hadn't just made the bigger version of it.
The broader lesson, and I think this one generalizes past me, is that we've all gotten very good at the documentation half of process work because documentation is satisfying and legible and you can see it when you're done. Assigning ownership is neither of those things. It's one word next to a line item and it feels like it did nothing.
It's the whole thing.
Three. "Almost done" is a lie, and I have the receipts now.
There's a project I've been carrying since the beginning of August. Every week it made the list. Every week I looked at it, felt a small drop in my stomach, thought "that's almost done," and moved on to something else.
Five weeks of that.
This week I finally opened it, mostly out of irritation with myself rather than any burst of motivation.
Forty minutes. It took forty minutes.
I want to be precise about what was actually left, because the number is the whole lesson. There were two decisions I hadn't made, neither of them hard. There was one section that needed maybe two hundred words. And there was a formatting pass.
That's it. Five weeks of dread over forty minutes of work.
So I went back to figure out what happened, because this is not the first time and I'd like it to be closer to the last.
Here's my best read. When something is at ninety percent, your brain stops storing what's actually left and starts storing the feeling of the whole project. You don't open the file, so you never refresh the picture. And the picture degrades. It gets vaguer and heavier every week, because vagueness is heavy, and after five weeks of not looking, "the last bit of that project" occupies exactly as much emotional space as "that project," which was a real amount of work.
The dread scales with the size of the whole thing. The work scales with what's left. Those two numbers diverge violently at the end, and the further you get, the worse the ratio gets, which is precisely backwards from how it should feel.
Which explains something I've been confused about for years, which is why the last ten percent of everything takes longer than the middle. It doesn't. It takes forty minutes. It just takes forty minutes plus five weeks of not opening it.
The rule I'm writing down for myself: when something has been "almost done" for more than two weeks, the next action is not to work on it. The next action is to open it and write a list of what is literally remaining. Not to do any of it. Just to look and write it down.
Ten minutes, maybe. And the ten minutes is not procrastination dressed up as planning, because the output is a list of specific things rather than a renewed intention. Those are different objects.
Because I'd bet the list is short almost every time. And a short list on paper is a different object than a vague heaviness in your head. You can look at four bullet points and think, I could do that Thursday. You cannot do that with a feeling.
The other piece, and this is the part that stings a little. When I finished it, I felt good for about ninety seconds and then mostly felt annoyed. Five weeks of carrying something that cost forty minutes. Five weeks of it sitting on the list, quietly taxing every planning session, showing up in that low grade way where you're not thinking about it but you're aware of it.
Forty minutes.
I'm choosing not to spend too long on that, because the guilt doesn't buy anything and I've got other things on the list that are probably in the same condition. Better use of the annoyance is to go check.
Three lessons. Saying a number is a different skill than setting it, and the silence afterward is where it all goes wrong. A system without a name attached is a hope, and the owner is whoever notices, not whoever does. And "almost done" is a story your brain tells you when you stop opening the file.
If you've got something that's been almost done since August, that's your forty minutes. Go find out.
One step, one day. Grace over guilt. — Dan Kaufman

