Every project is a monster you battle and slay
I’ve been thinking of a quote I once heard about writing being a monster that you battle and slay. I couldn’t initially find the quote, but I liked the idea that writing projects were monsters that you go up against. This couldn’t be more perfect a description for a recent project of mine.
I feel like I’m a pretty good technical writer, but recently I found myself in full battle with a project monster. I was picking up the pieces of some documentation sketched out (I wouldn’t say written) by another person (not a tech writer), who had since left the company (somewhat abruptly).
It seemed that all the knowledgeable people were tucked away in some other priority, in another state and part of the company. Those who did make themselves available didn’t have the knowledge to help. Even the QA team shrugged their shoulders when I requested an end-to-end walkthrough. So I tried to figure it out on my own. And I found myself banging my head against the wall. How is this thing configured? Is there some backend process I’m not seeing? How does it actually work? Does it even work?
When I finally did get past an initial hurdle (thanks to some benevolent field engineer who took pity on me and threw me some nuggets of knowledge), I found myself up against yet another obstacle. The sample implementation partially installed, but it wouldn’t run. Why wouldn’t it run? And if I couldn’t even get it to work, how could I possibly expect users to make it work for them? I found myself going in circles, not getting anywhere.
I tried to put off the project, but it kept coming back to me, higher priority than before. Docs were essential for this product, and it was a visible goal all the way up the leadership chain — I returned again to it. But as I was focusing my full energy on it, I couldn’t seem to break through. Why did the secrets of this project keep eluding me? What was I missing?
This project consumed me with frustration that turned into mild depression. I felt no energy to blog. I lost energy for conversation. I started to lose some confidence in myself. Frustrated and at my wits end, I fired off an email to a product head about being “blocked” (the magic word, really, in engineering) until I could get a sample implementation working. The product head listened. He allocated his smartest engineer to help me, and after an hour on the phone, sharing screens, holy schmoly the sample finally worked!
This breakthrough led to other breakthroughs, and I could observe the logs for each interaction, and little by little I unraveled the secret behind the product. I could finally see how it ticked, and how all the pieces (figuratively pinned on a mental wall by an insane detective) started to fit together and make sense.
I still have a lot of work to do, but I feel like I understand the product’s secret, and I can now make progress in the writing.
Not all projects are monsters to battle, for sure. Some projects are just annoying and tedious. But more often than not, complex technical writing projects are monsters we battle. We might have to learn some technical language or framework to make progress, meet with engineers, re-listen to recordings of meetings, sift through QA test scripts, logs, and other sessions before things start to make sense. But at some point the product seems to unlock, and we understand key concepts, and this empowers our ability to write.
Although I’m writing about tech comm projects, I know fiction writers encounter similar monsters. Only instead of understanding how a product works, they rack their brains to understand how a character’s mind works, how plots fit together, how motivations and psychology interact in intricate ways. I don’t write fiction (at least not intentionally in docs), but I can see overlap.
As I was hunting around for that writing quote, I also ran across a writing quote from Nietzsche, who happens to be my favorite philosopher. Nietzsche says,
He who fights with monsters might take care lest he also become a monster. And when you gaze long into an abyss the abyss also gazes into you. (Beyond Good and Evil, Aphorism 146)
I think the meaning here is a little more straightforward and potentially unrelated. If some feral monster is trying to kill you, to survive you’ll likely need to become a feral monster yourself and kill it. Battling monsters often requires you to abandon your high ethics and gentlemenly ways and paint your face with warpaint and scream like a wild man, etc. (I think Nietzsche might be taking a jab at turn-your-cheek ethics here. I’m not sure.)
Certainly, when you find yourself with a new, highly complex, confusing, and intimidatingly technical project for which you must write clear and user-friendly documentation in a short amount of time, it is like staring into Nietzsche’s abyss. Does this abyss have the potential to gaze into you? Is descension into madness somehow required in order to defeat madness, as Nietzsche says? Do you have to become a monster to defeat a monster? And does this apply to writing?
Maybe. I’ve been binge-watching a show on Netflix lately called Outlander. In it, one of the characters, after a traumatic and humiliating experience, descends into a darkness from which he can’t seem to recover. He stops eating and lies inert in his bed week after week while his wife stands by, not understanding how to help. Someone finally tells her that if she wants to save her husband, she’ll have to descend into the darkness with him. So she does, more or less, nearly taking her own life. And it works. She brings her husband back from the darkness.
I heard a similar echo in a Jack Reacher book I’m currently listening to. In Never Go Back, Reacher explains why it is that when he sees a monster coming at him, he instinctually lunges back at it instead of running away. Talking with a colleague, he explains:
They thought my brain was wired backwards. They got all excited about my DNA. Maybe they were planning to breed a new race of warriors. You know what the Pentagon was like back then. But they were young anyway. When it comes to fear my DNA is the same as anyone else’s. I trained myself, that’s all, to turn fear into aggression automatically…. I figured it was a choice. Either I cower back or I get in their faces.
You return intimidation with greater intimidation, return aggression by getting into the aggressor’s face, become a monster to kill a monster.
I’m not sure if Nietzsche is entirely relevant here, or if filling your soul with an abyss or darkness or becoming a monster is somehow necessary to defeat a tech comm project monster. But perhaps there’s something to this idea.
In the tech comm experience I related above, frustration pushed me to my threshold. I hit a point where I couldn’t make any progress, and I started to go mad. It caused me to reach out in an aggressive way to the product head to unblock me.
Maybe with project monsters, you have to step up your level of aggressiveness. When QA sort of shrugged their shoulders at me, maybe I should have come unhinged and escalated this. What? You don’t actually test the product end to end, but you certify it for release nonetheless? ^#@!!$#%&
I’m not sure that going berserk or Rambo-like in these scenarios (turning into the monster) will really help me defeat a figurative project monster, but perhaps some new behavior is warranted. For example, becoming a stalker and following key project people’s activities online (inside the firewall), becoming obsessive and immersed in learning about the project’s technology to the extent that you spend all week on lynda.com doing nothing else, canceling all meetings on your calendar for one month out, shutting off your email and messaging clients entirely, inviting yourself to meetings you’re not invited to, scheduling high-level engineers to give long afternoon trainings for your benefit, meeting with leaders 2 or 3 levels above you to discuss priorities, convincing your boss to bribe key engineers with a parade of gifts, devoting your full mental attention to each small success or error message until you understand every angle of it, combing meticulously through support logs and customer relationship databases for information and clues, working late into the night when you catch a trail of information, mapping out every single person related to the project and their roles and interaction points, relentlessly emailing people about every unanswered question again and again – I don’t know, all of this seems a bit mad, out of the ordinary, but maybe this kind of obsessive, semi-insane, otherwise questionable, over-the-top behavior is what’s needed to kill a project monster?
In short, for complex technical projects, the monsters we battle, maybe Nietzsche is right here — we have to become a monster to kill the monster? But for our own sanity’s sake, I hope this isn’t the case.
On another note, with some help on Twitter (thanks @TheLauriest), I finally found the quote I was initially searching for. It is from Winston Churchill:
Writing a book is an adventure. To begin with it is a toy and an amusement. Then it becomes a mistress, then it becomes a master, then it becomes a tyrant. The last phase is that just as you are about to be reconciled to your servitude, you kill the monster and fling him to the public.
Churchill describes the evolution of the writing project from an amusing toy to a mistress, master, tyrant, and monster. But what about the corresponding evolution of the writer with each phase? That is the more interesting story.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.