Writing is Not Thinking

The power of writing to process and inspire change

You’ve probably heard the phrase, “writing is thinking”.

I actually don’t buy it.

As an experiment, I spoke the first draft of this Substack post. I wanted to see what was possible with using AI to evolve a transcribed oral story into a written format. I’ve often wondered how the written and spoken word interact, and this experiment provided an opportunity to “cross the streams”.

So I prompt engineered. I leveraged all the models: Gemini, ChatGPT, Claude, Llama3. (Ok, not all, but four feels like plenty.)

And the final output, at first, appeared quite good. The AIs carefully structured my oral story into written form, and managed to maintain my original language and voice.

But… it didn’t quite work. There’s this untranslatable word from the Biblical Book of Ecclesiastes, “hevel”. I’ve seen it translated as “nothingness”, “vapor”, and “mere breath”. The AI-written version of my oral story felt like hevel.

I don’t think it’s AI’s fault. Oral word, stripped of context, pales compared to its written sibling. Oral word is meant to be embodied. You imagine a storyteller, standing over a campfire. The storyteller uses diction, movement, atmospheric sounds, shadows. Everything combines with the words to create a theatrical moment. To reduce the story to a transcript is to strip so much of the “body” of the work.

Is writing more thinking than speaking? I don’t think so. When I tell a story to my kids, I immerse myself in it. I often close my eyes, and enter into my imagination. I feel like a prophet, existing in a vision of another world, translating that world into speech as I explore it.

Writing feels quite different. When I write, it feels more like my thoughts flow out as water, and the act of writing somehow shapes those thoughts into word and form.

For me, writing isn’t thinking. It’s processing my thinking.

Which is a long way of saying that when I’m facing a struggle, I write. If, instead of writing, I silently ponder, I end up in an endless loop that does nothing except stresses me out as I spin in circles. If I try to “talk it out” with myself, I end up meandering to a totally different subject. Writing, though, leads to some kind of resolution. Usually not an answer, but at least a next action – or, just a sense of peace. The thoughts have been dealt with. They’ll come back, but they’re at bay for the moment.

Writing as self-soothing is useful. It’s a great reason to start a “morning pages” practice or to journal generally. But the true power of writing is not in the processing. It’s in the change-making.

And so I arrive at my oral story. It’s about the one document I’ve written that actually became known by a name: “the mise doc”. I’m not sure what it says about me that one of my career highlights is a memo. But it was a memo that changed work – and the lives of my coworkers – for the better.

I don’t remember the original title of the mise doc, but I remember its origin. I had joined Loom a few months previously as an engineering manager. Loom wasn’t just a series B startup – it was an async video messaging app in the height of the Covid-induced remote work diaspora. “Hypergrowth” was an understatement.

Not a surprise, then, that Loom didn’t have much in the way of a “software development lifecycle”. And at the time, even using those words would elicit groans if not screams from the engineering team. Have you ever tried to introduce structured process into a vacuum? It generally does not meet with excitement.

I knew better than to impose change as a new member of the team. Instead, I worked within the system for three months. And I observed that while nobody was excited to adopt “structure”, the engineering team also showed signs of exhaustion with the status quo. The recently hired VP of Engineering had introduced a deeply thoughtful career ladder structure to help engineers understand their roles and responsibilities. But at the day to day level, the lack of process or cohesion made everything a bit chaotic.

But humans like what they know, and change requires both effort and energy. I knew from previous experience that introducing “process”, top down, would meet with resistance. Imposed process does not typically win hearts and minds.

So instead, I wrote. And the mise doc was born.

One would imagine that a process doc would begin with, well, process. What’s Agile, how are we doing it, what are the meetings, yadda yadda. Instead, I started in a kitchen – specifically, a French restaurant kitchen. “Mise en place” means “everything in its place”, and it’s core to how a classical French kitchen operates. Just as an engineering team has specialists in different areas of the stack, a classical restaurant kitchen has different “stations”: grill, salad, pasta, etc. And across all these stations, the cooks meticulously arrange their tools and ingredients before service begins. This focused preparation is what allows them to enter flow state during the ridiculous pressure cooker of service, as orders constantly swirl in and plates rush out.

Process is often seen as a creative inhibitor, as onerous red-tape. And don’t get me wrong, it can definitely be those things. I’ve fallen asleep in seemingly-endless meetings that accomplished nothing except checking a box in a lifeless structural methodology. But when done well, process enables creativity. It enables you to stop wasting time on the things that don’t matter, and focus your energy on your creative output. What should I be working on? What’s the next priority? When’s our next check-in? How do I clarify a requirement? All these questions and more constantly distract from what an engineer should be focusing on: inventing elegant solutions to customer pain points that bring delight to users.

The mise doc would list out, in detail, all the various aspects of the day to day process we would follow, our weekly and monthly cycles. Crucially, the doc would lay out expectations for engineers at different levels, to make it clear how each engineer would be responsible for their “station” in the flow.

Months later, the team had rapidly accelerated in its delivery. I would be lying if I said they were happy, exactly. We were going 0 to 1 on a new product, and it was exhausting work. But the velocity of the team, and its cohesion, attracted the attention of other teams at Loom. And without my intention, the mise doc spread. First one team, then another, cloned it in Notion. They altered it to reflect their own team culture and structure. Within months, every eng team at Loom had its own variation of the mise.

When I began writing that doc, I had no intention of changing Loom’s eng culture. I was doing what I do when I write: I was processing. “Here are our new ways of working”. But why are they the ways of working? Why do we need ways of working at all? Why will this change make life better?

In writing, I process the why. But sharing writing is where the magic lies. My writing says: this is the world as I see it. Sharing my writing makes my observations a conversation. This is what I see – what about you?

For the last several months, I’ve been exploring the way we write and collaborate on writing. Just as different types of pens alter the ease with which we write across the page, our digital tools change how we express and share our thoughts.

When we write, we write to think, to process, to reflect, to capture. But I hope, I hope, that we also write to share, to converse, and to change. To change our own minds, to change the minds of others. To listen to their response. And, collectively, to change the world. Or at least, our little corner of it.