For a few years, I tried my hand at filmmaking. I was OK at it; however, it was during a time when the competition was amazing. OK, wasn’t good enough. Fortunately, I had a backup job and, after a couple of years of being OK at filmmaking, I returned to technical writing. I was surprised to find that after being a filmmaker for a while, my technical writing had, somehow, improved, even though I did absolutely zero technical writing as a filmmaker.
Here are some of the lessons I learned as a filmmaker that apparently had more value when applied to technical writing.
All that matters is what people see on the screen
As an independent filmmaker I watched many independent films. Those scars will be with me for the rest of my life (If you’ve watched indie films, you know what I mean. If you haven’t, you’ve been warned). Some of my films must have scarred others (sorry). I believe filmmaker Robert Rodriquez said in Rebel Without a Crew, that you needed to make several hundred films before you become a filmmaker. I would agree. I still had a few hundred more to go before I ran out of money.
Before watching others’ films, the Directors (or, more often, director/producer/writer/photographer/star) would give a brief commentary and, invariably, these commentaries included all the things that didn’t go as hoped or as planned—preparing us for what were about to experience (i.e. lowering our expectations). While of some interest to the filmmakers in the audience, this information was irrelevant to anyone else.
What matters to the audience (i.e. those who might actually pay to see/rent/download the film) is what is on the screen. Period.
Tech writing takeaway: the reader will judge the content for what they see and not what you would like them to see.
The budget must match the story
Or, the story must match the budget. Whatever works for you. Some of the independent films I saw could have been better if they only had a larger production budget. Most just needed a better script. But, the better low-budget films had a correspondingly smaller story. A personal tale. A single actor in a single set. A story in which a low-budget would not highlight what was missing.
Tech writing takeaway: Get the most you can with what you have, but know where the limits are and don’t try to do exceed them–advocate for more resources if they are required. Otherwise, the result will suffer and I’ll refer you to the previous lesson for why that’s not a good thing.
The story is more important than the tools
If the script is bad, the film will be bad. Period. Great cinematography, heartfelt acting, amazing visual effects, and sound that sends chills down your spine will not make a bad story better. Production tools have absolutely no effect on the script. Zero. And the script is why people watch the movie. All the rest are supporting characters.
A good script is one where the images form in your mind as you read and you’re half-way through it before you realize it. Most indie scripts (as in 99.99% of them) are simply painful to read—usually because they still need more work and the writers are impatient. Shooting them with the latest tools doesn’t make them less painful to watch.
Tech writing takeaway: Know the story you want to tell and tell it well.
Tech writing is different. NOT!
During a job interview for a tech-writing job, I was asked about my filmmaking experience and how that might apply to technical writing. I replied that it helped me tell better stories. The interviewer replied, “but what does that have to do with technical writing?” Apparently, I needed to tell a better story about my filmmaking experience.
Tech writers tell many stories.
Tech writing tells a story of a frustrated customer who becomes a satisfied customer.
Tech writing tells the story of the developer, who, before finding your documentation, could not accomplish that cloud-service task, and now, they can AND now, they can make money for their client or customer.
Tech writing helps developers say hello. And, not just hello, but hello to the entire world! (OK, that might be stretching it.)
Tech writing tells many stories. Knowing the story you’re telling and to whom you’re telling it, you can connect with the reader. That doesn’t mean you need to start each tutorial with, “Once upon a time…” or “It was a dark and stormy night…”
But, you have to remember:
- All the reader sees is what you show them. They don’t see the limitations of your publishing system, task-queuing app, or evasive subject-matter experts. They see you telling them a story that resonates with them and their context or not.
- The budget must match your story. Get your stakeholders to believe in the story. Does your story need more design resources? Do you need more tools to build/test/publish? Advocate for the budget you need to tell the story.
- The story is more important than the tools. Your priority is the story you’re telling through your content. Be sure you are clear on what that story is before you get too far into production.
If you’re not clear on the story you’re telling, your first priority is to clarify the story. Know your customers’ stories? Call them scenarios, if that helps. How can you make your current and future customers heroes in their stories?
Jumping in and producing content can look like progress, but that appearance can be misleading, especially if you don’t know the story that content supports.
So, what’s your content’s story?
Other thoughts about stories in tech comm
- Mazurkewich, Karen. (2018). Technical Experts Need to Get Better at Telling Stories
- Johnson, Tom. (2018). Principle 8: Align the product story with the user story
- Baker, Mark. (2015). The Role of Story in Technical Communication
- Lemanski, Steve. (2014). Technical Storytelling: The Power of Narrative in Digital Communication