Sometimes, sticking with a technical explanation is better than convoluted analogies and diagrams.
I love analogy and metaphor as they’re powerful tools for communicating unfamiliar or complex topics. Someone from a non-technical background can quickly grasp the importance of application programming interfaces by explaining that they serve as a translator between two systems that otherwise don’t speak the same language, or that core technologies serve as a foundation upon which more complex technical systems are created.
SEE: IT expense reimbursement policy (TechRepublic Premium)
However, sometimes these metaphors can become as complicated, or even more complicated, than the topic they’re meant to convey. For example, I’ve come across dozens of Roman buildings in PowerPoint presentations, where the various columns were supposed to represent some system, process or technology that supported a roof and stood atop a multilayer foundation. The more convoluted representations would include a half-dozen layers and multiple colors that created a delightfully festive, but otherwise overly complicated diagram. The majority of a meeting would be spent explaining the “helpful” chart, and at best when the meeting ended, participants might understand why column 8 was teal and column 34 was aquamarine, but otherwise departed more confused than when they arrived.
In one of my expeditions deep into the metaphorical hole, my team created a wildly complex airplane dashboard that was meant to represent a problem-solving approach. The graphics were beautiful and the analogy seemed gleefully elegant, and we couldn’t wait to share our brilliance with a potential client. However, we abandoned this metaphor after our first client presentation with this visual aid required an explanation of aviation history, a primer on aeronautical physics and a discussion of the various functions of specific airplane instrumentation. Perhaps the client had a better understanding of how an airplane functioned, but I don’t believe she had any clue how our approach worked or might help her company.
The outcome is usually more important than the details
There’s no escaping the fact that technologies, management approaches and implementation details are often profoundly complex and nuanced topics. However, our colleagues are often more interested in the outcome and determining if they can trust our abilities to deliver it. For example, suppose an individual is seeking critical medical care. In that case, they’re probably more concerned with whether the doctor is competent and experienced with this particular procedure and the likelihood of a successful outcome than the nuances of which scalpel will be used and the backend systems the hospital systems use to communicate.
SEE: Tech projects for IT leaders: How to build a home lab (TechRepublic)
Rather than trying to help someone understand the complexities and nuances of a technology or approach, focus on how it helps them achieve an outcome about which they’re concerned. One could spend an hour providing a non-technical colleague with a working understanding of middleware or that same hour could be spent explaining that there’s a technology that will allow their marketing project to be connected with sales data far more quickly and thus accelerate the timeline for a critical program.
Be careful when explaining the how
As technologists, we’re paid to understand complex technology, and often required to determine how a sea of existing and emerging tools and technologies can help our businesses get work done. For many of us, this pursuit is what keeps us coming to work every day, and it’s exciting to share our passion with those who are interested.
Having a colleague ask, “well how exactly does this work” is often perceived as a license to dive into a detailed technical explanation of a particular topic. While this response takes the question at face value, it’s usually an indicator that the person asking the question perceives the technology as creating unnecessary risk. The how is less about the nuts and bolts behind the scenes, and more a question of competence and trust.
SEE: Burned out on burnout: Companies may be trying too hard to ease employee stress (TechRepublic)
Unless you’re absolutely certain that you’re speaking with someone who is genuinely curious about the nuances of why you’ve selected MQTT for your Internet of Things rather than XMPP, the “how does that work” question is probably better interpreted as “How will you actually pull this off without derailing my program and costing me lost time and resources.” Rather than talking about the tech, a “how” question is usually your cue to talk about risk mitigation, how you’ve vetted the team and the technology, what support structures are in place and what you’ll do if something appears awry.
Spending the time to clearly articulate the processes you’ll put in place to maximize the benefit of a given technology, while minimizing the risk and resources required will equip you with thoughtful answers to these types of questions. Ultimately, this gives your peers significantly more confidence than that lovely six-dimensional pyramidal chart, the “Roman house,” or whatever other convoluted analogy creates less confidence in your peers rather than more.