Four Lessons Learned to Close Deals #2

Lesson #2: Listen to understand

Most Technical people listen with the intent to rapidly respond with a technical answer, in an attempt to be the smartest person in the room, but often causes them to miss the actual problems.?Understand what is being said and respond appropriately to the intent, even if your response is to ask a question that requires them to look at some other item.

My best example is when I realized my foreign projects had fewer scope changes, less scope creep and more on time completions.?Since I only speak English, foreign projects would force me to get a deeper explanation with more details in the examples of the problems they are encountering.?When someone is explaining a problem, but English is not their first, or second, or even their third language, they may often choose words that are not what you would expect in describing their problem.?This would make me really think about what they meant, and to examine the problem from a different perspective before I started crafting a design solution to their needs.??

A great example of this is a client based in the US that had Datacenters in Germany, China, South Africa, and Mexico, all with the same business challenge.??I worked with the technical lead in the US to build out a solution, but prior to implementing the design I visited each country and spoke to the technical leads there.?When I compared these discussions with the US design it almost seemed like a different problem all together.?Yes, there are local and regional items that needed to be considered, but the core technical issues were identical in each location.?That was not actually identified until I was forced to listen with the intent of understanding because the words used to describe the problem.??

The word “broken” has multiple connotations.?Each one imparts the same high-level meaning, but each has a subtle nuanced difference.?When a problem is explained with, “it is broken”, do they mean physically damaged, functionally inoperative, or programmatically malfunctioning??Do I need to design a solution that accounts for an action like water in the server room, or self-recovery after a system fault, or is there a logic defect that needs to be addressed???

It was once said to me by one of my foreign colleagues that, in English, listen, and silent use the same letters for a reason.?If you are thinking or talking about the design before the description of the issue has been completed, you are probably not being silent and listening with the intent to understand.??

The results of listening to understand will bring you to the next lesson.