Guide

I Rebuilt the Process,
Then Became the Person I Replaced

A weekly process nearly disappeared twice in two years. What fixed it wasn't a better system. It was writing the standard down.

These examples come from my own operations work, not inHaus client engagements.

I took over podcast production at a media company. The person leaving gave me twenty minutes.

She was generous with those twenty minutes. She walked me through the show, the cadence, the pieces that had to exist before an episode could go out. None of it helped, and that wasn't her fault. The actual system wasn't something she could hand over in a conversation. It lived in her personal AI account: the show notes, the editing sequence, the way each piece connected to the next one. When her access ended, the process ended with it.

Nobody had done anything wrong. Nobody had ever asked her to keep it somewhere else. The company had a podcast that came out every week and no record anywhere of how that happened.

The rebuild

Rebuilding from twenty minutes

I worked backward from the output.

I listened to published episodes and read published show notes and reconstructed the sequence from what had survived. Where I couldn't tell what she'd done, I decided what I would do. That took a while, and the version I ended up with was faster and better than what I'd inherited.

That improvement had a specific cause worth naming. Rebuilding from scratch forced decisions the original process never had to make out loud. What order the steps go in. What format a description takes. What counts as finished. When you inherit a working process, those answers are already baked in and invisible. When you rebuild one, you have to choose them, and choosing them makes them sayable.

I just didn't say them to anyone. I made the decisions, ran the process, and kept the answers where the last person had kept hers.

The calm

A year and a half of everything being fine

The show went out every week. The quality was consistent. Nobody raised a concern, because from the outside there was nothing to raise.

This is the part that's hard to see while you're in it. A process that works and a process that transfers look identical from the outside, for as long as the same person keeps showing up. There's no warning light. The only difference is what happens the week that person isn't there, and most businesses go years without running that test.

The recognition

Then I had surgery scheduled

I sat down to plan coverage, and I understood what I was looking at.

I had become her.

The system was better than the one I'd inherited and it existed in exactly the same number of places: my head, and accounts that belonged to me. If I'd gone in for the procedure without doing anything about it, the next person would have gotten a twenty-minute conversation and a wish of good luck, and a weekly show would have collapsed for the second time in two years, for the same reason both times.

The instinct at this point is usually to hire. Bring in a second person, split the knowledge, build redundancy. I've written separately about why hiring doesn't resolve this, so I'll leave it there. The short version is that adding a person to an undocumented process changes who is overloaded, not whether the business depends on someone's memory.

The fix

Writing it down

So I documented it before I left.

Step by step, with screenshots, with the exact instructions for every tool involved. It was unglamorous work and it was finite. It took the time it took and then it was done.

The steps were the easy part. The hard part was the standard, meaning the places where I'd been deciding things by judgment and had never noticed I was deciding anything. Which audio needed a second pass. How long a show note runs before it needs cutting. What "clean" means on a transcript, specifically, in a way another person could apply without asking me.

That's the real content of documentation. Not the sequence, which most people can figure out. The judgment calls, which nobody can, because judgment is invisible to the person exercising it. Every process that only works when one particular person runs it is carrying a standard that lives in that person and has never been written in a sentence.

I wrote the sentences.

The test

The handoff

The day I went out, I handed the document to someone who had never edited a podcast.

They followed it. The show went out. The quality held.

I want to be careful about what that proves, because it isn't that I wrote unusually good documentation. It's that the work was never as personal as it felt. The parts I thought required me were mostly just parts nobody had described yet.

Here is what the process looked like when it was finished.

Workflow Spec · 002Reconstructed and documented
Workflow
Weekly podcast production
Owner
Assigned at handoff. Prior podcast editing experience not required.
Trigger
Recording lands in the shared folder
Standard
• Transcript generated and cleaned before editing begins
• Edit follows the documented sequence, not preference
• Show notes, descriptions, and captions produced to one format
• Graphics built from the standing template
Handoff
Finished package to publishing. Producer approves only if flagged.
Escalation
Anything off-standard routes to the owner same day.
Status
Running
Last updated
2026-08-30

What actually changed

The process stopped depending on any particular person, including the one who built it.

That last clause is the whole point. I didn't document the work so that the company would have a copy of how I did things. I documented it so that how I did things stopped mattering. The version running now is not my version. It's the standard, and the standard belongs to the business.

Most founders are one of the two people in this story right now. Either you inherited something that only works because someone still remembers how, or you're the one currently holding it and it's running well enough that nobody has questioned it. Both end the same way. It's usually a surgery, a resignation, or a week off that finds out.

The question worth sitting with is which process in your business only works because you remember how.

If you want a structured version of that question, bring it to a discovery call. Thirty minutes, a straight look at where your business still routes through you, and an honest answer on whether I can help.

Book a call

Related reading

Why hiring didn't fix it

The full method

Want to know which system to build first?

Thirty minutes. I'll name the workflow that's trapping you and tell you whether inHaus is the right fix.

Book a call