There’s a lesson I keep relearning that I’ve started calling the Cinema 4D lesson, because the first time I really understood it I was trying to learn Cinema 4D, which is a 3D modeling program, and I was watching tutorial after tutorial about a particular kind of surface material that kept eluding me. I’d follow the steps exactly, I’d get something that looked approximately like the result, but it wasn’t right, and I couldn’t name what wasn’t right about it. Then one night I simplified everything. Stripped the file down to just the material and a single sphere, no lighting rigs, no complex geometry, nothing to hide behind. And I immediately saw what was wrong and why it had been wrong for two weeks. The complexity wasn’t revealing the problem. It was obscuring it. Simplicity is always hiding somewhere in the mess, and finding it is usually the whole job.
I built a pipeline to run this blog. Not because I’m particularly interested in automation for its own sake, but because I’m sixty-four years old and I have a project that needs to produce writing at a pace that my keyboard-and-sitting practice wasn’t going to sustain, and I wanted to figure out how to do that with discipline and intention rather than in scattered bursts when inspiration showed up. The pipeline, at its core, is simple: I talk, the talk becomes material, the material becomes a post, the post gets an image, the image goes through a critique and revision process, and everything ends up published and documented. That’s the clean version. The version I actually built was considerably more elaborate, and I spent a lot of time being proud of how elaborate it was, and then I spent even more time watching the elaborate version sit idle.
You know how this goes, you know, because you’ve done it too. You build the complicated thing, the thing with all the dependencies and the automated steps and the moving parts, and it feels like progress because it feels like you’ve solved the problem before you’ve had to do the work. And then something in the complicated thing breaks or stalls, and because you’ve built a lot of complexity between the problem and the solution, you can’t see clearly which part is broken, and the whole thing stops while you debug the thing you built instead of doing the thing you set out to do. The automated pipeline was sitting idle, doing nothing visible, for stretches of time, while the manual version of the same process took five to eight minutes per post. Simplicity was hiding in the manual version the whole time.
So I stripped it down. I went to the minimum viable process. I recorded the voice. I had the recording transcribed. I gave the transcript to a prompt that embodied my voice and my stories and my twenty-five years of teaching — a prompt I’d spent real time building, not a shortcut — and I drafted the post. Then I put the post through a critique, the way I would put a student’s work through a critique, asking the same questions I’d ask in a studio: does this sound like me? Does the story land? Where does the reader lose the thread? I revised. I sent it to an image generation process with a prompt built to capture not the literal subject but the metaphor under the subject, and I brought the image through three rounds of its own critique. I published. That’s the process. Five to eight minutes of active work per post, once the voice recording exists.
What surprised me was how much designing the pipeline taught me about the work itself. I’m a design educator. I’ve been teaching people to make things and iterate on things for a quarter century, and I know that the process of making something reveals what the thing needs to be. I thought I knew that about designing, about photography, about building curricula. I didn’t know I was about to re-learn it by designing a system for producing essays. But here’s what happened: building the pipeline forced me to articulate what my voice actually is, what a post in my voice actually requires, what the specific stories are that anchor everything and without which a post is just generic wisdom anyone could have written. You can’t build a prompt for your own voice without understanding your own voice, and I didn’t fully understand mine until I tried to write it down as a set of instructions.
The prompt that sits at the center of this process is a document. It has rules, non-negotiable ones, about sentence flow and paragraph structure and punctuation — no em dashes, not ever, not for any reason, because readers have learned that em dashes signal AI and I’m not interested in signaling AI, I’m interested in sounding like myself — and it has the stories, the actual material from my actual life, because you can’t have authentic writing without authentic experience underneath it, and any system that tries to produce authentic writing without that foundation will produce something that sounds approximately like a person but reads like a simulation. The document is, in a real sense, a portrait of how I think, what I know, and what I’ve lived. Building it took longer than the pipeline itself.
The other thing designing this process taught me is the discipline of restraint, which is maybe the hardest lesson in design and the one that keeps needing to be re-learned. The pipeline can produce posts fast, but fast is not the point. The discipline is in the sourcing: I only write from material I’ve actually lived, stories I’ve actually told, experiences I’ve actually had. I don’t fill gaps. I don’t round out a story with what might have happened. The synthesis document that feeds this process is built from transcripts of my voice recordings, interview sessions, documented memories, and that’s it. If it’s not in there, it doesn’t go in the post. That constraint is not a limitation. It’s the whole quality system. Everything that makes this blog mine rather than generic comes from maintaining that discipline, from trusting that twenty-five years of teaching and a life that took some significant turns is sufficient material without any invention on top of it.
Every system teaches you something about what you actually needed. This one taught me that the writing was the easy part, and the hard part was knowing who I am clearly enough to put it in writing. If you’re trying to build a creative process of any kind, that’s the lesson I’d hand you first, not the tools, not the automation, not the workflow. The pipeline question is: do you know yourself clearly enough to instruct the process? If you do, the rest of it is just sequencing. If you don’t, no amount of complexity in the system is going to produce clarity in the output. Go find out who you are, first. Write it down. Then build the thing that lets you do it at scale.
Further Reading
- “Accidental entrepreneurs” are on the rise (Fast Company) — Solving problems leading to systemic solutions
- Why Your Founding Team Needs A Designer (Fast Company) — Design thinking in entrepreneurship
