Everyone has their own technology dialect. Find common ground. Figure out how they think and communicate to them with their own words. Comparisons can help but can also confuse. This is a great example of why Tech workers need to excel in customer service.

Here's what I do: - Rephrase/Paraphrase when you communicate the progress - Focus on impact - Avoid delving into technical jargon - Emphasise how the issue affects the customer and their business - Set realistic expectations - Be clear in conveying the timelines the issue is taking to resolve - Keep stakeholder in loop - They appreciate when they see progress happening and seeing that their issues are prioritised

During discussions about issues, technical team can have restrictions if the non-technical stakeholders don’t understand the issue/bug the team is dealing with. This will create confusion, frustration and tension among the entire team leading to failure in resolving the situation. -If technical jargons are used, try to use simple words to define the jargon so that the other team member get familiar with the situation. -Flowcharts and schematic diagrams are great examples of representing the situation and it guides the team via user flows to reach a solution.

One thing I’ve found helpful is to outline what is at risk of being held up or stopped by this bug. Quantifying in financial terms is also helpful so they clearly understand the impact to the business without getting too interested in the technical specs. In order to avoid having non-technical stakeholders trying to help provide solutions, reassure them that you understand the severity.

Give more credit to the stakeholder. If they are discussing with you, they should have wherewithal to keep up in the conversation. Spend more time thinking about the end-user. If the stakeholder uses a certain dialect, or language natively, ideas that are usually common ground turn noncommunicative. Technical terms may lose meaning as you and the stakeholder find a proper lexicon. Expect to miscommunicate. Even technical laborers in the same team experience communication issues. Proper communication is a function of time invested with the stakeholder, among other things.

While analogies can be helpful, they can often lead to confusion or fundamental misunderstandings of the issues, which can lead to tensions between teams. I find it's better to break down the technical jargon or stack traces into more digestable, familiar terms, while still taking care to maintain the accuracy and integrity of the technical issues they communicate, regardless of the audience I am presenting to. Users and teams are going to play telephone as they delegate and re-explain to their own teams and stakeholders, so any degredation of information from the source can be disastrous down the road.

Whenever I have to do it, I focus on the dynamics, rather than the actual technicality of the issue. One common alignment between all employees is the company's solution. Often times it works to take one aspect of the solution, explain what is behind it and what i preventing this to go forward, simply.

In my case i would like to share with analogical, especially in Indonesia the people here don't like complicated things or else they will not understand what u say. Business users that use our apps dont like to hear the technical, they need to hear the concept of being simply.

Bugs are like whack-a-mole. Some fixes break other things. "Fixed" looks different to everyone. "Under-promise and over-deliver" is a beautiful motto. Embrace the team that's dedicated to the remedy, not the bandage. If the fix was easy, the product is generic. Integrity build culture.