(for your reading pleasure, written by Jules (L). –ed)
We have all had that sinking feeling of defeat: you’ve just finished explaining a very important and highly technical thing to people who are not in IT, and you can read it in their eyes that they just don’t get it. Half of communication is on the listener’s part, it’s true. They have to pay attention, they have to ask questions, they have to care. But none of that is in your control. All that is within your control is how you present the information. And that’s where storytelling comes in. You may think you don’t need storytelling skills, but the truth is, you are a human, talking to another human, trying to convey a premise, stakes, characters, plotlines, and possible resolutions. That’s a story, and you need to know how to tell it.
The Hook: Give them something to care about, inspiring curiosity, fear, hope, etc. in plain English. Example: “SQL02 had some problems over the weekend, but I’ve talked with some very smart folks at Microsoft, and we have a clever plan to not only fix it but keep it from happening again.”
The Stakes: It doesn’t have to be earth-shattering, or even company-ending, for the stakes to be high. But you do have to make them CARE about what’s at stake. Emphasize what’s important about the problem, in non-technical terms. Example: “Getting our data in line with this compliance isn’t just government red tape. It demonstrates our integrity, and it a great sign of reliability to both clients and investors. Failing to do so could make an otherwise minor data breach into national news.”
The Characters: To be sure, your IT systems are characters in your narrative, and communicating their essential identity markers to your audience is key. You don’t have to tell them numbers. Tell them how to feel about those servers: “SQL02 has been unreliable, but we can change that, make it almost as good as SQL09, which as you all know is rock-solid and jet-fast.” Programs can be characters, code can be characters, and certainly your IT crew can be characters (but be nice about them, they’re real people. Bad-mouth SQL02 all you want, you can’t hurt its feelings.)
The Plot: This is the tricky part, to summarize what may be a complicated and years-long battle with legacy code, difficult people, old hardware, etc. As simply as you can, tell them what the major conflict is, and what is holding you back. Think about it in terms of actions, not thoughts or feelings; think about what is HAPPENING. Keep it to what they need to care about right then, in this story. It may be that the Big Bad Wolf was also the problem in Three Little Pigs, but that doesn’t matter if the story you’re telling is Little Red Riding Hood. Stick to your current narrative. There’s always time to chat about backstory later.
The Resolution: Now! Tell them what needs to happen! What you need from them! And what it will be like afterwards. Wrap this thing up and bring it home. Again, keep it simple; instead of “I need to patch SQL02 which will require a restart, which will cause x problems,” frame it as “The solution is to patch and restart SQL02, and have a plan we developed ahead of time for handling the outage, after which we will be more stable and secure.” You may or may not include “And we all lived happily ever after.”
So go! Tell the story of your server environment! Work out a plotline of advancements, with a redemption arc story for SQL02! Make your audience CARE! And may we all get more good work done, and be heroic, and ride off into the sunset in our Hondas.
–Jules
