3 Simple Ways IT Must Navigate Tech Jargon

Working in high tech for 20 odd years I've been bombarded by jargon -- heck, as a marketer I've liberally used much of it myself -- from "proactive management" and "new paradigm," to "value ecosystem" and "disruptive innovation" (sorry folks).

There are truckloads of acronyms too, such as ITIL, COBIT, SOA, and REST. There are combinations of words like DevOps, and now cringe-worthy, made up words (well to my spellchecker anyway) like… wait for it… gamification.

Negotiating the terminology minefield is one thing, but I'm continuously stunned by all the tech trash talk. It's not a lack of intelligence, but rather a failure to get across what something actually means to a real-world business.

[Solutioning, diarizing, and zerotasking have lurched into the business lexicon -- but must go, says a former CIO. Read Stop Butchering The English Language]

CIOs should relate to this because they walk the jargon tightrope every day. They're the go-between, acting as the term translator. Sometimes this translation involves using simple language to demonstrate the business value of a concept. It also means acting as a circuit breaker when terms flare up in the business ranks and could be damaging if overused -- like cloud, BYOD and "Shadow IT."

So without resorting to term speak (hard for a marketer, trust me on that one), here are three quirky, but common-sense approaches IT leaders can use to explain the real value of a vague term.

Watch more TV shows -- Well, good documentaries actually. Recently an IT service manager I know landed a new job at an organization badly in need of service improvement. The IT department had good people and management technology, but IT problems and business outages persisted, and morale was low.

If ever there was a case for service management it was here, but the business side was skeptical and IT resistant to change. But to build a business case for training and a program for service improvement, my friend didn't talk at length about best practices like ITIL. On the contrary, she did something simple but brilliant -- she got her team and business managers to watch an episode of the TV documentary Mayday (about air crash investigation in the UK and Australia).

Mayday episodes show how the National Transportation Safety Board (NTSB) methodically determines the exact cause of airline accidents so that policies can be put in place to prevent future disasters. For my friend, this was a great way to show her team and management that IT fire-fighting was ineffective and that team-driven proactive problem management would reduce costs and improve customer service.

Learn a simple new language -- Many years ago as a young pre-sales tech I was asked to present an infrastructure management product to a prospective customer -- an auto-tire retail chain. I loved the technology and, over the course of a one-hour session, deftly demonstrated all the tech wizardry, widgets, and dashboards, blissfully dropping terminology bombshells such as "proactive control," "deep root cause analysis," and "single pane-of-glass."

I felt confident and in technical control, that was until a quiet guy at the back of the room (and they're always at the back) hit me with a simple business question. "So how will all this help me sell more tires?" This painful lesson taught me the importance of presenting technology terms in context of a business need. If I'd have done that upfront, I'd have avoided 45 minutes of technology tap-dancing, especially when you consider the quiet guy at the back was a key decision-maker.

In short, keep the language clear and always be able to answer the question: How does this help the business?

Go shopping at the mall -- Whenever I'm introduced to a new term or concept, I shop around. There's the simple grocery shopping, like scouring the web to fill the tech essentials and subject matter cupboard. All necessary of course, but with newer concepts like DevOps, filtering through the masses of nonsense, technical bias, and outlandish claims leaves little time for anything else.

My approach therefore is to get an understanding of the main idea behind a term and then look for examples of how it actually works at a business. Recently, for example, I went clothes shopping at a store called Zara with my partner to get a better handle on DevOps. Why on earth would this help, you might ask? Well, Zara is the perfect example of how collaboration across teams has helped the company disrupt its market and become extremely profitable in the cutthroat world of retail fashion.  

To look at how Zara manages its product lines from design to retirement really shows how a concept like DevOps plays out in the real world. For example, Zara has fashion designers work hand in hand with manufacturing in the same factory. This not only ensures that new designs get to the stores faster ("continuous delivery" in DevOps language), but also that specific design issues are corrected immediately ("feedback loops" in DevOps).

In my eyes, this kind of collaboration, continuous delivery, and faster time to market makes Zara a DevOps champion. There will never be a shortage of IT termification (a word I made up), so follow your business instincts to understand where the business value hides in all the noise, jargon, and acronyms.

Tech Marketing 360 is the only event dedicated to technology marketers. Discover the most current and cutting-edge innovations and strategies to drive tech marketing success, and hear from and engage with companies like Mashable, Dun & Bradstreet, ExactTarget, IDC, Microsoft, LinkedIn, Oracle, Leo Burnett, Young & Rubicam, Juniper Networks and more -- all in an intimate, upscale setting. Register for Tech Marketing 360 today. It happens February 18-20, 2014, in Dana Point, Calif.