When building custom software to solve a specific business problem we are often working with people that have limited technical experience. In these situations, it is not uncommon for myself or my colleagues to explain a technical issue in non-technical terms. We give reasons as to why a specific change may not scale well, or why a certain feature may cause problems in the future, or why we're using one technology instead of another in language that may differ significantly than if we were having to explain the same thing to a coworker.
When working with someone who is not familiar with software development and the nitty-gritty of modern enterprise architectures, it can be challenging to drop the jargon and coming up with an effective way of communicating. Having just finished Charles Tilly's informative book Why?, subtitled "What happens when people give reasons... and why," I have a better appreciation as to how this occurs.
Tilly's main thesis is that we give different reasons to different people and the types of reasons we give often have a lot to do with the relationship between giver and receiver. He breaks down reason giving into four convenient categories of conventions, stories, codes, and technical accounts. His dust-flap example sums up these four categories nicely:
"Tilly shows how an air traffic controller would explain the near miss of two aircraft in several different ways, depending upon the intended audience: for an acquaintance at a cocktail party, he might shrug it off by saying, "This happens all the time," [convention] or offer a chatty, colloquial rendition of what transpired [story]; for a colleague at work, he would venture a longer, more technical explanation [codes]; and for a formal report for his division head he would provide an exhaustive, detailed account [technical account]."
It's important to keep in mind that part of being a professional is having the ability to be fluent in jargon and the specialized language of your profession. That's why you're an expert: you're fluent in tech-talk. You can say one word to your colleague and it can mean a lot. That's the power of language when used at this level. But it's also important to keep in mind that the receiver of the reasons, especially the highly technical reasons littered with codes and detailed jargon, will often challenge the giver to redeliver the reason. The receiver may ask for something more cause-and-effect, more narrative in structure.
They will ask for a story. One that they can understand. And one that answers their question of "Why?" in a way the other reason did not.
On our projects, I like to think this goes both ways: we're tech experts, our clients are experts in their own domain. Usually this brings about a nice equality when working together. We each learn some jargon along the way, ask each other "Why?" frequently, and struggle together to come up with appropriate stories and metaphors to help in the understanding in building something meaningful.
So next time you're asked "Why?" and struggle to come up with a "dumbed down" version of something that one sentence of codes or jargon could take care of, stop for a second. Challenge yourself and your own understanding of the concepts for a better, more appropriate explanation for your questioner, framed in an easier to understand narrative manner. Drop the frustration with the person seeking understanding. Tell them a story (not a fiction, mind you, but something with some characters, some plot and a theme that illustrates your point).
To use a bit of software jargon, make your communication "user-friendly" and see what happens next.