Neurodistinct™

LESS GEEKY TECH TALK = WINNING COMMUNICATION WITH THE NON-TECHNICAL

Us Neurodiverse thinking Tech Geeks tend to just “stick to the facts” when we explain. For me and most of the tech tribe, this means explain it in the detailed concepts we think in. This works great when the other person has a technical understanding of the topic and the time for the details. When dealing with the non-technical, “tech talking” for 10 or 15 minutes continuously is always the wrong approach. Most non-technical people are neurotypical types. They often color their impressions and make decisions based on how they feel. Frequently they consider social and emotional impressions over facts. This means facts and details will not make a lasting positive impression. Instead, you have to get them to relate to you and feel a human connection. Short personal stories and sound bites, not tech details are the key.

A well-crafted story, even if only a minute long, will make an emotional impression which will be long remembered. Weaving in a few facts with a positive human connection and the facts will not be forgotten. The goal when answering any question technical or not, is to make the questioner feel something so they tie the details to an emotional feeling and make it a long lasting memory.

Never answer with just Yes or No

Most tech environments are fast paced with a focus on all the technical details we need to develop the project. Myself and most neurodiverse techies I work with, just want the facts as fast as we can get them. In these environments a “yes or no” answer works fine for many questions. When communicating across the tech/business barrier with the non-technical, just answering “yes or no” is interpreted as a negative sign. It misses the mark in making the other feel something from the answer, other than short changed. Because of this, it is imperative the yes or no be delivered with more information than most of us autistic leaning tech types are used to. If asked do you know program XYZ, try these more complete yes or no responses. You will be amazed how much answering this way improves working with business teams.

·      Yes, I know that program. I used it as a major piece in the solution I built for the accounting department. In my role as the primary developer I worked extensively with that tool.

·      No, I have not had an opportunity to work with that tool. But, I am very familiar and comfortable with program ABC which is the major competitor to XYZ. I am sure with the familiarity I have with ABC and already understanding the concepts these tools are based on, and I could very quickly transition to the package you use.

Create 60 - 90 second stories for common questions and scenarios

Every common business questions needs to have a short story describing it. This is not a case study or even a user story, but a synopsis which is intended to convey the feeling you are competent, understand the issue, and can be concise. The basic story should be memorized, but be delivered in a manner that sounds authentic. After delivering the story you want to ask if the answer was sufficient or if there are additional areas or details they would like to hear.

Story Structure

Good stories are structured to get maximum emotional impact and elicit the feeling you want from others. While the words and details are important, it is even more important to personalize the story for maximum impact. The type of stories needed for most business/tech questions follow these:

•  Succinctly answer the question with a brief summation of the business situation relevant to it.
•  Describe the challenges you face to accomplish or achieve what you described in #1.
•  Describe how you plan to overcome the challenges to be successful.

Example story

Answering the question from a business stake holder, tell us how you plan to solve our issue?

First, I am going to work with you closely to make sure I understand the details of the problem. As I research the process, I will probably have to ask more detailed business questions and data meaning. Once we all agree on the scope, user needs, and details, I will architect a solution. If I understand correctly, we need to be able to cut from the old to the new over a weekend? I also think I heard the prior week is planned for working with your department to bring them up to speed on the new solution. Does this answer your question or are there some areas I missed?

For reference, delivering this story at a comfortable pace for the listeners takes me about 40 seconds. If you are doing it in less time you are going too fast, not pausing at the punctuation, and overall making your listener feel stupid! The example story gives you a great way to test this yourself. Recruit some non-tech co-workers. Read them the story in 25 – 30 seconds. Probably feels natural. Now do it again at a 40 – 45 second pace. I know it feels slow. Now ask them which one was easier to understand technically and which was easier to follow overall? You are going to be surprised!

Summary

It is not the number of words or the amount of technical jargon that will form long term working relationships. Speak to where they are. Address how the new solution will help them feel better when doing this work. Verify the message got across and they are happy with the level and amount of information. You have to ask, “Did that answer the question?” Otherwise you miss out on a perfect opportunity to demonstrate your new super power communication ability.

Tim Goldstein