How to Explain Technical Concepts to Clients
When explaining technical concepts to corporate clients, developers tend to be confronted with blank faces, glazed eyes and slack jaws. Even when outlining a solution that will streamline business and save a lot of money, these IT pros often suspect their business partners’ minds are elsewhere.
To keep executives’ focus in the boardroom, developers need to keep their conversations on the information these leaders need to know — although the complex nature of the implementation process probably would wow a room of fellow techies, these elegant details likely will be lost on a group of nontechnical thinkers.
Instead, developers should spend the time they have with their clients discussing the aspects of the project that relate to their jobs. They need to focus on the objective at hand and how the new solution will help realize that goal to help business leaders keep the conversation in perspective, said Randy Russell, RedHat director of certification programs.
By speaking directly about clients’ role in the implementation process and outlining what they are expected to contribute, technical professionals can keep their business meetings productive and meaningful, Russell explained. Further, asking clients what they would like to know before the meeting can help developers make their presentations more engaging.
“If nothing else, people appreciate being asked,” Russell said. “And beyond that, very often, they’ll give you things you weren’t going to talk about. It comes back to getting in that habit of thinking about, ‘What is the information the other party needs?’ not ‘What is the story that I want to tell?’”
Developers also can make their explanations more meaningful by using business-friendly language when talking about technical concepts.
Many IT pros are skeptical, even disdainful, of the corporate vernacular, but learning the fundamentals of business communication is beneficial for all technical professionals, Russell said. Even IT pros who have no interest in moving into managerial positions generally will be assigned to better projects and get their work done faster if they know how to talk to people in different areas of business.
“It’s not that they have to become those other people, but they do have to adopt some of that vocabulary and know when to use it in an informed and nonpatronizing way,” Russell said.
Beyond simply clumping conversations into “technical” and “nontechnical” categories, developers also need to customize their communications for specific nontechnical audiences.
For instance, in discussions with upper management, IT pros need to keep their technical descriptions brief and focus on the big picture because these leaders don’t have time to talk about details — they need to move on to other things.
When dealing with an employee population, however, details are often a crucial part of the discussion. Russell said. In e-mails or meetings that relate to new programs or processes, lower-level workers often need things explained in-depth and frequently require some hands-on training.
“You have to think about those kinds of things with the different audiences,” he explained. “You have to consider, ‘What is the audience I’m talking to, what is the information they need and how can I communicate that in a way that make sense to them?’”