Are we really listening

I learned an important lesson about listening when I just joined KMS six years ago. I was in a Monthly Business Review (MBR) meeting with our org’s Vice President (VP). I was driving a project on its critical path, so I prepared thoroughly in case I got picked. Then the VP asked: “Jin, when do you think you can deliver this in region xxx?” Man, this was my moment to shine! “The reason we had to delay the project was …” I gave a long narrative full of technical jargons on why the project was at risk and how I was turning it around. The VP finally had enough: “Jin, I was asking for a date. You can just give me a date!” “Oh …” I was embarrassed as you might have guessed. I didn’t listen to the question. I just let out whatever I had prepared. If the VP was my customer at the moment. I wasn’t Customer Obsessed. I was obsessed by myself, my ego. In Amazon, we have a guideline that when answering questions, start with: Yes, No, a Date, or a Number. Only give the details when you are asked and only give the details relevant to the questions. I did many interviews in Amazon. A common pitfall from interviewees is they just give the answers they so deliberately prepared, that have nothing to do with the questions being asked. There is another pattern of not listening to the question. That is when we stop learning about new things. Whatever the questions or situations, we just pick something we know well, then give that as the answer. This usually happens on people with certain amount of industry experience. We were in a meeting discussing a TCP connection capacity issue in our load balancer. In this case customers’ API requests were rejected before they reach KMS endpoint. A team member suddenly said: “why don’t we redirect the TCP connections to a server and return 400 errors?” The room was quiet for a bit to digest this novel idea. “But if customers can’t even establish TCP connections with our server, how do we return HTTP errors to them?” I asked. “I was thinking we can return the code in the IP header, you know, like in IP tunneling protocol GRE” “Err, how do you think we can change the IP header on the load balancer? Even if we can, our customers are mostly Python, Java, Node.JS application layer developers. And their applications often run inside AWS server-less infrastructure. How do they sniff the IP traffic and read the error code?” “…” It turns out the team member had many years of experience on VPN/IP tunnel product before. So instead of listening actively about the current problem and understanding the customers’ pain, he tried to bring the problem to somewhere he knew well - therefore the idea to return a HTTP error code (layer 7) to a TCP connection failure (layer 4), using IP header (layer 3). Listening is an art I don’t claim to be an expert at all. But I am eager to improve. So listen actively and mindfully to others, let go the self!