Monday I wrote about the handoff prompt, which is what you do when a long project runs out of room and needs a clean start. This is the other half of that pair, and it's the half that surprises people.
At the end of a working session, when the thing you set out to build is finished and there's no reason to still be sitting there, I ask one more question. Some version of: how did that go, and what could I have done better?
Not what could it have done better. What could I.
The questions
Six of them, and I've stopped varying them much:
What were the struggles or the gotcha moments — the things worth telling the next round about?
What could I have done to make this faster or more accurate?
Was there context I should have brought up sooner?
What was the best part of how we worked?
Did I give you anything you didn't need?
What did we learn here that makes the next one better?
That's the whole thing. Five minutes at the end of a session that already ran two hours.
What it actually tells you
Here's the answer I get more than any other, and it took me a while to stop arguing with it.
I write a lot of reference documents for the work I run this way. Real ones, that took real time. And what comes back at the end of a session is some version of: that document was twice as long as it needed to be, and I used about half of it.
Or worse, the one that stung. I'd built four separate reference cards, one for each step of a build, and handed all four over at the start. The debrief told me plainly that three of them overlapped and two would have produced the same result.
I had put a lot of work into those four cards.
That's the honest part of this and it's why I'm writing it down. I over-explain. I pile things up at the front of a job because it feels like being thorough, and a lot of the time I'm adding weight without adding quality. I don't see it while I'm doing it. It sees it every time.
That is hard to hear when you've spent a Saturday making something. It's also the only reason the work has kept getting better instead of just getting bigger.
The change that stuck
The most useful thing this ever told me was about how I open.
I used to start a big job with a pile. Here are six reference documents, here are the folders, here are the memory files, here's everything I could think of that might matter. Read all this and let's go. It felt responsible.
What I was told, eventually, was that the point of the whole thing gets lost in that pile. Say what we're doing first. Then let me ask you for the detail when I get to the step that needs it.
So now I open like this:
The goal of this thread is to build and upload training module EC-026 to our system. There are a lot of steps and I have clear instructions for each one. Start by reading —
Goal first, shape second, detail on request. That one change did more for the quality of my long builds than any prompt I've ever copied off the internet.
The part I'd steal if I were you
Some of my bigger projects have a private channel where it's just me and the work. Nobody else is in there.
At the end of the debrief I ask for one more thing: post it in the channel, written for whoever picks this up next. What we learned. Where it got stuck. The gotchas. And the places where I explained something wrong.
That last one is the whole point. It's a written record of my own bad instructions, sitting somewhere the next round will read it before it starts. So the same wrong explanation doesn't cost me the same afternoon twice.
Every one of those notes is small. Half of them are one sentence. But they stack up, and a project six weeks in runs noticeably smoother than the same project on day one, for reasons that have nothing to do with the tool getting smarter.
The catch
Ask at the end, not in the middle. Mid-job you're still working, and you'll get agreement instead of an assessment. The debrief only works once there's a finished thing to look back at.
You still get to disagree. Some of what comes back is wrong, or right in general and wrong for how you actually run. Take it the way you'd take a comment from a good foreman who wasn't there for the whole job: worth hearing, not automatically correct.
But if you argue with all of it, stop asking. You'll waste both your time. The value here is entirely in being willing to find out you were the slow part.
Carry this out
At the end of your next long session, before you close it, ask one question: what did I give you that you didn't need?
That single question is the cheapest one on the list and it's the one that changed how I work. Everything else is a bonus.
Reply and tell me what it says. I'd honestly like to know whether everyone gets told they over-explain or if that one's just me.
Friday: what I do when I've got a free hour and no idea what to spend it on.

