One thing that I think a lot of developers struggle with is with how to explain a technical problem to a non-technical person. Developers often work all day with other developers where they can bounce around ideas, talk about bugs, and use technical language without fear of confusion or being misunderstood. However, there are times where developers must attend meetings with potential customers, explain a new feature to a non-technical boss/employee, or converse with any other potential number of non-technical individuals.
This type of communication can often be overlooked by developers, particularly if you are an introverted person, like myself. However, the more you are involved in the software industry, you realize that being able to explain technical issues is extremely important. It doesn’t matter whether someone has technical knowledge or not — no matter who you talk to, you want to treat them with respect and conduct the conversation in a way that is beneficial and easy to understand for both parties.
For example, put yourself on the other side of the table for a minute. Let’s say you are having a private meeting with your lawyer. You have an issue, and you are looking for clarification, advice, and potential resolution. As such, you wouldn’t want them to start throwing around a bunch of legal jargon or start citing really obscure sections of some complex legal document. You want to know in plain, direct language, what the law says, how it affects your situation, and what the proper course of action is.
Likewise, as a software engineer, you need to be aware of who your audience is and what the best way to convey the information they are seeking. How can we do this?
Solutions
1. Show The Problem!
As software developers, the products we work on often have visual components. Subsequently, most of the problems that we encounter in development affect user experience in some way. This may be that an end user is seeing incorrect data, certain features are broken, a page hangs, etc… Problems such as this are something that can be seen. As such, we can use tools such as screenshots or screen sharing in order to demonstrate these issues.
This allows you to show the problem in a more universal way that doesn’t depend on knowing certain technical words or understanding any design/implementation complexities. For example, let’s say you have a bug where a modal doesn’t close. This could be due to a problem with an api route, a bad event handler, or any other number of things. But when you demonstrate the problem by doing a live run through of the feature, no matter what the cause, your audience will generally understand what’s wrong. Somebody may not know the word “modal,” but they will certainly be able to see that the “big floating box with a button in it” doesn’t close properly
2. Explain the problem in business terms.
This is really useful if you are talking to an investor or a non-technical boss. A lot of the time, non-technical people don’t necessarily want an in-depth understanding of the problem. What they really want is to understand a few basic things:
- How does this affect our customers?
- How long is this going to take to fix?
- Are there going to be any costs associated with this?
Rather than explain the technical details, you can boil down the issue into these core components.
For example:
“There is a problem with the code and thus the user is not able to perform Action A. I have located the problem, and it will take approximately X Days to fix. We will also need to upgrade to the next tier of aws which will cost Z Dollars more a month.”
This is great. It cuts through the technical level and gives these people the information they truly want.
3. Explain Your Terms
It may be that the above situations do not apply. There may be a situation where a non-technical person really does want a relatively in-depth understanding of the problem at hand. In this situation, what I find is helpful is to take a step back and really think about your words.
Since you are explaining a technical problem, it’s okay to occasionally throw in a technical word. But when you do, be sure that you explain that word. Don’t be ashamed or feel hesitant to explain terms that might seem a bit basic to you. Either you’re audience will nod in affirmation of something they already know, or they will be happy to receive an explanation of an unfamiliar word. Further, don’t take for granted that your explanation was understood. You should try your best to encourage questions and make sure that you can clarify any potential points of confusion.
I think that about covers it. Hopefully this information was helpful in understanding how to explain technical problems to non-technical individuals.
The post Explaining A Technical Problem To Non Technical People appeared first on Remote Dev Daily.
Top comments (0)