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.