• Focus on describing the value as vividly and specifically as possible
• Use everyday analogies
• Tell stories to emphasize key points
BY:
Salvatore Nicci
Technology Analyst / Reporter
PROJECT COUNSEL MEDIA
11 March 2022 (New York, New York) – While now old hat to litigators, the advanced technology and procedural rules governing eDiscovery in its present form have only been around for about 15 years. That’s when a cottage industry of savvy tech providers started offering outsourcing services to law firms attempting to identify, preserve, collect and process the often overwhelming amounts of documents and metadata that could be evidence in a lawsuit.
But it is complex. It’s not just wrapping your mind around the combination of a proliferation of data and the expanding complexity of that data (never mind the expanding privacy and other regulations) but also the complexity of the software, the complexity of the software engineering and the need to also wrap your brain around machine learning, emerging tech, and a ton of what the tech providers call “data-driven solutions”. All of this tech has taken over the main stage of the ediscovery industry, and the delivery of legal services in general.
I’ve been in New York to attend one of the Analyst Syndicate brainstorming sessions. We have been members of the Syndicate for years (it’s a multi-dimensional platform through which the world’s best technology and business analysts publish their research and recommendations and hold jam sessions). They eschew being called “thought leaders” (gag) but they are pretty much the best brains in technology and business I’ve ever met.
And I was right down the street from Legalweek, the ediscovery industry’s premier trade show, so I popped in for a day. Significantly reduced in size (vendors and attendees) since I was last here 4 years ago but not unexpected due to our slow recovery from COVID. I wanted to meet vendors (and also watch vendors interact with potential customers and attendees) to see how they explained the complexity of the software, the general complexity of eDiscovery tech – all those “data-driven solutions”.
I visited 12 vendors and surreptitiously recorded (me bad) my conversations with their representatives and their conversations with other attendees, to be used in a later post. Many just seemed to blind people with science and relied (far too much) on their set PowerPoint and other presentations on their booth laptops and not having real conversations with the person standing right in front of them. You could see the fog developing around the heads of some attendees who, rather than ask return questions during/after the presentations seemed only able to repeated a series of “Uh, huh. Uh, huh. Uh, huh“. The same was true for two of the panels I attended.
It was in follow-up to one of the Analyst Syndicate brainstorming essays “The art of explaining complex technology for fun and profit” which is publicly available and which I have attached below. Lots of good advice for the eDiscovery crowd.
The Art of Explaining Complex Technology for Fun and Profit
You’re smart. You understand your business. You’ve mastered the latest technologies. But you keep getting rejected when you propose new investments to the executive committee. Or you can’t seem to close the deal with a prospect. How can you turn failure into success?
Avoid “talking down” to colleagues
How can IT leaders and technology vendors explain a complex technical issue to executives and business managers and customers? My answer is simple: don’t try to! In most cases, the explanation of how the technology works is less important than the value the technology provides. Knowing what the technology accomplishes and what benefit it provides is usually more useful than a detailed description of its inner workings. The key question in executives, business managers and customers’ minds is “what’s in it for me (WIIFM)?” WIIFM pokes at the utility of technology to each person individually and the part of the organization the technology is supposed to benefit. The IT leader/vendor who addresses this question will communicate more effectively than one who stays in the technology functionality weeds describing the finer points of how the technology works.
There are corollaries in other disciplines. For example, I can make an excellent loaf of bread without knowing the specifics of the chemical reaction that allows yeast to create gases that leaven bread. However, it is helpful to know that properly proofing the yeast – knowing the job the yeast is supposed to do – will result in a loaf that is delectable rather than a doorstop.
The IT leader/vendor can avoid sounding like they are “talking down” to colleagues/customers when discussing technology issues if they take a minute to understand what is behind the question. What does the person really want to know? Usually, it has little to do with how technology works and more to do with its usefulness and its applicability to solve the organization’s problem. IT leaders should avoid “setting the detailed technology table” before they let the executives and business leaders enjoy the meal.
Here are three common situations when technology explanations might be requested:
- An IT leader is requesting funding for a project;
- A vendor is trying to make a sale;
- A tech-savvy person is being asked a question about the technology.
Successfully requesting project funding
In my role as an IT leader, I was often in the situation of needing to ask business leaders to fund a project. This usually meant creating a presentation or white paper that described what we wanted to do and what technology was needed to accomplish it. Oh yes, explaining how much it would cost was pretty important.
Multiple studies describe the typical IT leader as a person with an analytical social style. Analytics have an aptitude for dealing with data and detail that overwhelms people with other social styles (driving, expressive and amiable). These styles tend to be more focused on results, emotions and relationships, respectively. The IT leader who knows the CEO wants to boost productivity by improving employee engagement will cite data on the positive correlation between flexible work programs and productivity. Then they will explain how investments in collaboration and video conferencing tools enable flexible working.
The better approach to gaining approval for a project is to understand the social styles – and hence the motivation – of the business leaders and appeal to that rather than provide a detailed dissertation on technology. How technology works excites the analytical mind and leaves the other social styles befuddled. The IT leader should start by describing technology results. Let the business leaders ask technology questions if they want more detail on its operation.
Clinching the software deal
The vendor who wants to make a sale can also use this approach. As an analyst, I received many briefings consisting of detailed information on product functionality. Sadly, there was little insight into how the product could be used to solve a business problem. Neither was there info on what benefits customers were getting from using it.
The better approach to making a sale is to emphasize results in terms of business value and customer satisfaction. This works better than touting how cleverly the product was designed or how quickly it was brought to market. It also is more meaningful than citing the combined experience of all the people in the company.
Using analogies to explain complex technology
IT leaders asked questions about technology can use analogies to explain it. An analogy describes how one thing is comparable to something else. For example, explaining that “an application programming interface is a way to programmatically interact with a separate software component or resource” could use the analogy that it functions like a waitperson who takes your food order, relays it to the kitchen and returns the food to you when it’s ready. Similarly, the concept of folders on a computer is a carryover from the days when people used manilla folders to store information in actual file cabinets.
Analogies might not always be totally accurate but they are often good enough to explain how technology works. And they don’t sound condescending. This is particularly true since technology evolves and often the terminology evolves with it but not all non-techies keep pace. For example, I was once asked by a colleague what “cloud” was. This was at the time when cloud was a new and poorly understood concept (circa 2006). Another colleague provided a technically accurate description. The colleague was still confused. I added that cloud was an updated version of time-sharing. That explanation was as much as he needed or wanted to know.
Recommendations:
- Focus on describing the value as vividly and specifically as possible – talk about outcomes and benefits. Ditch the acronyms and jargon. Use knowledge of social styles to highlight what value each person considers most essential from the technology.
- Use everyday analogies – analogies work when there is a shared experience. Select analogies that will appeal to a wide audience. Avoid analogies from obscure knowledge domains or esoteric topics.
- Tell stories to emphasize key points – the IT leader who can embellish a request to update security with a story of expensive it was to deal with the last denial of service attack might fare better than if they just state the request. Stories are a great way to connect with people regardless of their social style.
