Home > Blogs > Get Your Ears On

Get Your Ears On

As we gain more experience and expertise in our selected domains, there becomes a stronger tendency to lean primarily on that knowledge to solve problems. Sometimes this works, but sometimes we tend to lean too far in that direction and forget that we should be listening before we start solving. There are times when we need to remind ourselves to get our ears on.

In working with technology teams and their clients, I can't recall the number of times that the team has strongly pitched their technological prowess, while the client just shakes their heads and complains that they aren't being listened to. A little tip: unless you are selling technology products to technologists, your client probably doesn't care if you sling some mean Ajax skills, or whether you think Java is better than .Net or anything else. If I have someone in to build a new kitchen for me, the fact that they lean towards Makita tools over Bosch doesn't help me at all. Indeed, if they push this as a reason for going with them, I'll probably turn them away.

Instead, what helps me is that they understand what I need.

This is actually done far less than we might expect, particularly with technology. Even if it is not as blatant as the examples above, all too often we get just enough knowledge in a particular domain to be really dangerous. Our superficial (or even extensive) knowledge in a particular domain does not give us the ability to act as experts on behalf of our client's needs. We may be able to suggest alternatives for what they are originally asking for, but if we don't ask, if we don't dig deeply, we won't even know if they really need what we have to offer.

That argument is all immaterial, of course, if our focus is on selling our products rather than really solving our client's problems. Unfortunately, we don't have to be that self-centered to fall into this trap of not listening.

As we are exploring the problem space with our clients, if we don't take the time to reflect back our understanding of the problem to confirm that we really 'got it', we tend to move forward with incomplete assumptions. If we grab some thoughts from them via e-mail or a phone call than push forward with our solution, we can get into trouble. To take a few sound bites and translate that into a comprehensive solution, we can overwhelm the client with our technological notations to the point where they are stunned. "I guess that's what I said, it sure looks like you have done a lot of work." Often, what they will end up doing is confirming our presumption of what their needs were, but they will remain uncomfortable and ultimately unfulfilled.

We need to have our ears on, and the client needs to know that they really have been heard. These are two very different things, and require a feedback loop that we often don't take the time to develop. We need to richly interact, and carefully introduce them to the tools we use to express the issues so as to not overwhelm them. Don't pass them a full set of architectural drawings for a house without walking them through a basic understanding of how to read them. The same goes for a comprehensive requirements specification or project plan.

Sometimes, getting our ears on means we need to be active in building that shared understanding. There are many things that we need to do to ensure that we are actually on the same page, but the first is to remove that earwax. Those two things we were born with on our heads are often the most important assets we have.