Speaking Technically: Driving Change
Stories are about change. Our protagonists go about their normal lives until something changes- an “inciting event”. They then deal with that change through a chain of rising action that eventually reaches a climax. This locks a new status quo in place. The characters, and the world they inhabit, are now different.
The first step to change is identifying that something needs to change.
In Office Space, Peter starts with a life that he’s not too happy about. When his hypnotherapist dies mid-session, Peter has been changed. This is the inciting event. He doesn’t go to work on the weekend, doesn’t worry about his cheating (now ex-)girlfriend. In the rising action, Peter starts with mild office hijinks, escalating into all-out theft from his employer. In the climax, Peter decides to return the money and admit his theft; Milton steals the check and burns the office to the ground. Peter leaves the office job he hated and joins his friend’s construction crew, cleaning up the ruins of the old office.
Stories are a Crucible
There’s a process to all stories. On one end, we insert characters and a world, and something that throws them out of balance. Out the other end, changed versions of those characters and that world come out. You can put your organization on the input side of a story, and use the story to create a version of your organization that works differently in some fashion.
There’s a long trip from telling a story to actually seeing change happen. Change starts with a vision, with a buy-in to that vision. Stories are a powerful tool for laying out a vision, and for expressing that vision in a way that encourages others to adopt it. They help us communicate clearly and persuasively.
Fictional Success
The first step to change is identifying that something needs to change. Your organization has some anti-pattern or legacy process that’s just begging to cause trouble in the future. What inciting event could lay that bare? Now you know how your story starts.
The second step to change is identifying the path to change. Instead of the process you’re currently using, you want to introduce this new process or technology. This “New Way” is the protagonist of your story.
Combine those two features: your protagonist (the “New Way”) meets the inciting event (the problem that happens if you keep doing the same old thing). Now, the rising action: show us how the “New Way” deals with this problem. Show us more, related problems, and tell us how the “New Way” changes them. Identify new and bigger challenges for our “New Way” to overcome, and build up to a climax. Show how the new way solves a big, complex problem that’s intractable in the “Old Way”.
While doing this, don’t forget failures. Your “New Way” isn’t perfect. No one will believe you, and no one will like your idea if you don’t show us situations where it can’t automatically succeed. Treat your technologies like people. They have flaws, weaknesses, and blind-spots. Understanding the negatives helps your audience appreciate the positives even more.
After the climax, show us the new world. How does our organization work, what does it do differently now? This new world should be better than the current one, and you should be able to express this simply and clearly.
Example: ORM
I worked in an organization that focused on line-of-business applications. These were mostly simple CRUD applications, so I suggested moving away from hand-coded SQL queries to an ORM. I told them a story about how much repetitive code we created, and how much more maintenance that made for us. I told them about how we could quickly and easily generate that code using an ORM. I included the failures: ORMs don’t perform as well, they don’t work for every database schema, they sometimes depend on “magic” that’s hidden from the developer.
In the end, we switched new development to ORM approaches. Developers were much happier, since they spent less time doing plumbing. Our users were happy because we delivered features more quickly.
Vetting Ideas
There were some stumbling blocks in adopting ORM. The worst was situations where developers tried to use ORM in cases where it didn’t really make sense.
Not all changes are good changes. This technique of building a story about how the new process changes the organization for the better, is a great way to drive change. It’s also a great way to resist change- because if you can’t build a simple story around a change, maybe that change isn’t right for your organization.
For example, switching from a Relational Database to a NoSQL database is quite a fad at the moment- but lots of organizations are finding that an RDBMS was a better option and having buyer’s remorse. A NoSQL database, like MongoDB, is document oriented- you store entire documents, not individual records. There are lots of benefits to that approach, if your data fits neatly into that schema. Unfortunately, so much real-world data is relational- an order contains items from our inventory, is placed by a customer, and shipped by our shipping partner- that it’s difficult to tell a story about how changing to NoSQL is going to make our organization better. For many organizations and business cases, it simply isn’t.
Making Change
Stories are tools of change. If nothing else, the characters and setting of the story should change. A great story, well-told, can change the audience. If you tell the right story, to the right people, in the right way- you can change your workplace.
Storytelling enhances every aspect of your job: debugging, requirements gathering, interviewing, learning new tools and platforms, knowledge transfer, and more! If you’d like to transform the way you communicate, sign up for my upcoming workshop with master storyteller Kevin Allison.
October 19th
1–4PM
Rehearsal Studios at CUBE PGH, 5877 Commerce St, Pittsburgh PA 15206
With less than two weeks left, seats are filling up fast. Grab yours now!
Sign up today
Other “Speaking Technically” articles: Failing Upwards, Characters and Personification, Detail Oriented
