The old cartoon character Foghorn Leghorn once said to his nemesis Henery Hawk, “You’re hearing me boy, but you just ain’t listening!”
Listening skills seem to be getting rarer and rarer these days, even in highly technical roles. I cannot count the times that I have encountered engineers with serious challenges in this area, yet they seem blissfully unaware that it is of vital importance.
For technical people, it is so easy to get lost in enunciating our point, selling our ideas, voicing our opinions, defending our positions, or simply wanting to be correct, that we don’t improve our listening skills.
With that in mind, I consider listening to be one of the most powerful skills – maybe the most powerful skill – in the software engineer’s arsenal.
However, I don’t mean “listening” in terms of passively hearing someone else speak. I mean a very special kind of listening. I am referring to something called “active listening.”
What is Active Listening?
Active listening means engaging with a speaker in an interactive manner. This can take a variety of forms, ranging from silence or simple acknowledgement of the speaker’s statements, to dynamic back-and-forth that brings value to both sides of the conversation.
For example, let us imagine that a software engineer is discussing a technical solution with two of his colleagues. He talks about the root cause of the problem. He illustrates how the problem can be solved. Of the two people listening to him, Listener A is checking his smart phone, his smart watch, and his shoelaces, in that precise order. Listener A stays silent the entire time. Meanwhile, Listener B ponders the speaker’s words. He asks about alternate designs that were previously considered. He asks how the solution is working in production.
It’s not difficult to ascertain that Listener B appears to be actively listening, whereas Listener A seems disconnected from the conversation.
Why is Active Listening So Important?
Solid listening skills will take your software skill set far beyond the coding realm, if that is something you wish to explore.
Take, for example, the above discussion, which seems like a routine conversation. Some important things happened in the exchange! Listener B increased his rapport and likely his credibility with the speaker, while Listener A did not. Listener B quite likely has a better understanding of the solution than Listener A, simply because he mentally engaged with the speaker.
Imagine if the speaker was the CTO of the company; if so, Listener B may have gained a bit of traction with the top brass, whereas Listener A illustrated that he did not seem to care at all.
Imagine if the speaker were Listener B’s spouse. Yes, active listening is a very powerful tool in personal relationships. In fact, that is exactly where I first learned to apply the skill. So I know firsthand that it works.
If you ever want to become a top software engineer, a sales engineer, a solutions architect, or any other technical role that requires interaction with customers or business people, some degree of mastery over the art of active listening is an absolute necessity. Even in minimal form, active listening can help the software engineer learn new concepts more quickly, minimize ambiguity, and demonstrate behavior that is perceived as professional by colleagues.
In its most complex form, active listening might include elaborately designed interactions that flush out very complicated knowledge that the speaker possesses. Does this sound like software requirements gathering? I hope so, because active listening is also a key skill in effective requirements management.
I hope by now you are coming around to the idea that this topic is important! However, it can be difficult to do it effectively.
Here are some of the active listening techniques that I use most often.
Asking Relevant Questions
I’ve interviewed many engineers for technical roles. Amazingly, I frequently encounter engineers whom, when asked whether they have questions about the role or the technical details, have no questions whatsoever. Is that a red flag in an interview? Absolutely! It demonstrates either a lack of interest, a lack of preparation, a lack of communication skills, or all of the above. Why would I want to work with someone having those habits?
Asking questions that are relevant to the topic under discussion is the simplest and most effortless way to engage in active listening. At a minimum, questions demonstrate that you are at least interested in the topic. Well-executed and well-thought questions can actually be a differentiator of your skills when you deliver them in a forum such as conference calls with upper management layers. Normally when I do this, I attach my name to my question: “Hello, it’s Cory, and I would like to ask ….” If the question resounded with the participants, people know that I was the source. Of course, in this situation I try to be very careful to make sure that my question is a good one!
Even if I am watching the most boring speaker on the planet talk about the most boring topic on the planet, if they were to ask me whether I had a question, I could at least say “I’d like to study the topic more, and ask some questions offline. Would that be alright?”
I encourage all software people to practice this skill.
Taking Notes
Taking notes is also an easy way to active listening skills, yet it seems to be very frequently ignored.
Imagine you are in a restaurant and you place an order with a waiter. The waiter gives you no verbal feedback whatsoever on what you ordered. Do you think your order will come out correctly? On the other hand, the waiter that appears to diligently write everything down might give you a bit more confidence that mistakes will not be made between you communicating your order, and the kitchen preparing your meal.
If a simple food order is important enough to write down, isn’t a discussion about your project also important enough to write down?
Taking notes is a simple way to demonstrate to a speaker or group that you care about what is being communicated. You can use an old-style notebook (yes, I use one of these) or an online service and your tablet or smartphone. Not only will you demonstrate a level of engagement, but the act of writing things down will actually help you to engage with the material that is being communicated. The added bonus? You will have a record to remember the items that require follow-up activities.
Call and Response
Remember the waiter example mentioned above? Now imagine that the waiter recites your entire order back to you as confirmation. Now do you think your meal will come out as ordered? This behavior is the call and response technique in action.
Call and response is where the listener paraphrases the speaker’s message back to the speaker. This can be applied in nearly any conversation where you need clarity on the topic. Here is an example that uses a classic software requirements quandary:
- Business person: “I need a machine that someone can ride on. It must be steerable, and it must move using its own power.”
- Me: “Ok, I heard what you said. I think you are asking for a vehicle with a steering wheel, four wheels, a seat, and engine, and it would be used to take its driver from place to place.”
- Business person: “You’re on the right track, but this machine also has to cut grass.”
- Me: “Aha! We are talking about rideable lawn mower!”
You can see the basic structure in my reply. I first acknowledge that I heard the speaker. Then I paraphrase what I think the intention is, giving the topic some honest thought.
The call and response technique is powerful because it encourages three crucial things:
- It tends to reveal hidden assumptions, like the lawn mower requirement above.
- The speaker gains a degree of confidence that the listener is paying attention.
- It gives the speaker the ability to glean whether the listener actually understands the topic at hand.
All of these items help to gain the trust of the speaker. Trust is what makes people want to work with you, so the ability to gain trust is pure gold! This is precisely why active listening is so powerful.
Mental Pictures
Being a highly visual person, I feel that if I can imagine a complex topic in my mind, I can generally understand it enough to communicate it, and to execute on it.
Given that, I quite often augment the call and response technique with a diagram as part of the response. The diagram is sometimes a flow chart, while sometimes it is a formal-looking UML sequence diagram, and sometimes it is something completely unconventional. It is what I refer to as a “mental picture,” which is my attempt to capture my mind’s own interpretation of the problem space.
For example, if I am interacting with an audience that is non-technical, and I want to describe a conceptual situation involving a one-to-many relationship, I will draw something like this:
I will then proceed to narrate the audience through my understanding, using the diagram as a point of reference. On the other hand, if I am communicating with a technical audience, I almost never use a figure that implies containment as that above; so I might draw something closer to an entity-relationship diagram in order to imply a domain model without the ambiguities of a class diagram (this is along the lines of my previous post on communicating software design.) An example could be something like this:
I will frequently ask for feedback on whether a given visual representation resonates with a certain audience. This is my own way of improving my ability to use diagrams and pictures to the greatest effect.
By including one or more well-thought out diagrams, I can establish much higher confidence that I am on the same wavelength as the speaker, or the group that is discussing the topic. Sometimes a simple diagram can help bring an entire group to a common understanding where spoken words fall short. This is another reason why software engineers should be great active listeners!
Pick Your Battles
I find active listening to be so effective, that I must carefully choose what techniques to apply, and when to apply them. After all, any person that starts really understanding the topics under discussion for their company or their project, can end up unwittingly being volunteered for plenty of extra work that is outside their main charter. This can be a positive thing or a negative thing, depending on the situation.
Summary
Active listening can be somewhat of an art form, but it is well worth exploring further. There are many other tricks and techniques associated with active listening that can be used to great effect. Feel free to adapt some of mine, or find and apply your own. If you find strategies that work for you, I would be most interested in learning about them!