They say without conflict or growth in a character, there's no story. But why? Is this some tired trope or does it apply in real life? Well, let's walk this through. Is there a story when you're just going through your daily routine or when you're having choose between two great job offers? Is there a story when you're ready to get married but an old flame, whom you loved dearly, showed up? What makes even more interesting the reason for your breakup was a simple misunderstanding. Stories aren't just in the realm of fiction. Stories happen all the time in the real world! Why do some people read biographies, autobiographies, memoirs or historical accounts? They deem them to be worthy stories to read.
Even the Bible, though I fully believe it's God's Word, has elements of story. Here are a few examples:
- When God tested Abraham and told him to sacrifice his Isaac in Genesis 22. (Thankfully, there was a happy ending to this.)
- The story of Joseph and his brothers in Genesis 37-50.
- Joseph (different one) found out that Mary, who we was engaged to was pregnant and he wanted to divorce her quietly in Matthew 1:18-25. But he was informed that baby was the Promised Messiah, Jesus.
- When Jesus knew His death was near, He ask God, His Father, for Him not to go through it in Matthew 26:36-45, Mark 14:32-42, and Luke 22:39-46.
As conflict and growth of characters are essentials to crafting a good story, I believe these same elements are essential what makes us become better technical writers. How? Well, here are a few examples.
Let's say you're dealing with a difficult SME and you need to deliver some documentation by the next release, which is around the corner. This SME is hard to reach or gives little to no information on crucial parts for the information. So what do you do? Well, you either find a better way to reach this SME or find other key people who can help you get this information. To boot, you get this information at the last minute so you have little time to create quality documentation in the process right before release time. Doesn't this sound more like a story than dealing with an easy SME, who gives you exactly what you need and when you need it to create the documentation and you're done way before it's time?
To be frank, I like it when there's no drama and I'm able to get everything I need to create a document without issues. I suppose I could say the story is everything lined up exactly as planned. But that's somewhat of a rarity in our line of work. Eventually, this stops becoming a story and morphs into a routine. Where's the growth or conflict? I don't like any conflicts either, but we live in a broken world, so unavoidable. But brokenness births countless stories. This is my problem with those who looking for a "utopia" or demand constant perfection. If we got what many wanted, stories will cease.
Since conflict is inevitable, it's about knowing about how to find good resolutions to them. That's another key element in what makes a story. Who wants to read a story, unless you're an Eeyore, where there's no satisfying ending. Even open endings can be satisfying, if they're good.
I'll share a time where there was conflict, resolution, and growth that came from it.
My Story: Creation of a Style Guide
When I was working at a company, the SMEs would fight me and the other technical writer on how to write the documentation. The SMEs wanted to write in passive voice instead of active voice. They also wanted to write "the user" when it was a clear case of writing "you", which was their audience. But to be fair to them, in my zeal for clarity and style, I would in some cases inadvertently change the meaning of the content. (This could have been avoided if we were given access to test the software but that's another topic.)
We constantly battled over which words and phrases were correct, instead of focusing on releasing the documentation with the software. This fight drained the SMEs and us. The head of the company had to mediate in this conflict. After hearing both sides, he suggested that we technical writers create a style guide. So me and the other technical writer went to work to create the style guide. We used different sources, such as "The Elements of Style", to help us craft our tone and voice for the documentation.
After much discussion and iterations, we were able to create a style guide that would help direct us and the SMEs on how the documentation would sound. It wasn't perfect, for no style guide is, but it reduced the fights to nearly zero. Those who wanted to fight still, we would just refer them to the style guide and the directive we got from the head of the company about this.
We both became better technical writers from this. Though at that time, I hated going through every bit of this. I look back and thank God that this happened. If it didn't, I wouldn't have grown as a technical writer. I learned to better balance clarity and style, while retaining the original meaning of the SMEs intended. By having this balance, the intended audience will get clear and accurate information. This is not to say I've perfected this, but I constantly strive for this balance whenever I create documentation. I've also learned to ask better fundamental questions to better get this balance. And when possible, I ask for ways for me to test what I am writing about. Before this conflict, that wasn't on my mind.
I have to constantly remind myself conflicts can bring growth. It's too easy to wish a life without problems. Let's resist this silly (quite frankly, unbiblical) thinking. Without conflicts, there's no story. Without story, there's no life. Without life, there's no world.
