“Seek first to understand, then to be understood.”
— Stephen Covey
“I remind myself every morning: Nothing I say this day will teach me anything. So if I’m going to learn, I must do it by listening.”
— Larry King
These statements by Stephen Covey and Larry King are what I believe are good guiding principals for communications. Clear and understood communications between two people or a group of people can be very hard, especially when the people have dissimilar backgrounds. This can lead to disastrous results for teams and projects.
Not listening in software projects can lead to a single project going off the tracks. However, a large transformation project can set an organization back years, due to its size and scope. To achieve success in either scenario, it is important to listen and understand, especially when gathering requirements.
Listening is Key to Requirements Gathering
Some years back in my career, I worked on teams with mostly software engineers. As a software engineer myself, looking at these teams, it was obvious we lacked skills in other areas. Therefore, I learned UX and requirements gathering. While applying these new found skills on projects, it became evident a certain type of person is required.
One project in particular, I joined late, but we had all software engineers on the team. This team had a number of years building software in the customer’s domain. So, they came in with the attitude, we done this before, so we know your solution, even before talking to the customer. This experience and their personality types prevented them from hearing the customer. After a few meetings with the customer, they were turned away.
A few months later, I joined the team and was told the story of how the customer turned them away. With my new skills in hand, I asked to give me a chance on getting the requirements and they let me.
My Way of Listening
My first move was to sit down with the users and interview them to get a basic understanding of their job and what they do on a daily basis. This helps me understand their perspective. In this mode, I am a sponge, pulling it all in and asking clarifying questions. If they ask about technology or a solution, I say we can talk about it later and ask them to stay focused on their work. With the preliminary interview done, I watch them do the work they want help with improving.
It is important to see a person doing the work, as you can capture the process and key metrics of the process to include time taken per step, work in process, lines of communication/coordination and so on. Once you get a good picture of the process, you can begin to look at solutions. This is where my UX skills come in.
Communications is about showing you understood what someone is saying. For software development projects, I like to use mock-ups. These mock up are something you can turn around quickly. In this situation, I would meet with the users in the morning with my mock up and get their feedback. Then I would go an refine the mock up based on the feedback. The mock up was my way of reaffirming I understood what they wanted in a new application. This might sound a waste of time, but it is not.
Not getting your requirements right in the beginning is like a missile with all thrust and no vector, it goes into the wrong direction or it just spins out of control. The same will happen to your project and it happened to the project above, until I was able to meet with the customer. In the process of interviewing the customer, it became obvious the customer needed three distinct applications. Had the team went in seeking to understand, before seeking their solution, they would had been months ahead. Listening is even more important for transformations.
Cannot Have a Successful Transformation Without Listening
Today, a number of businesses are going through IT transformations. In these transformations, they are adopting new practices like Agile, cloud and DevOps. All these are a great departure from the “old way” doing software development, which means not everyone will be on board. This is where listening is very important.
In a transformation effort, there are key people who may not be on board. These people have built their systems and processes around the “old way”. Now, a transformation team is coming to make changes. If a team came in and bulldozed through a new style of work without engaging the existing teams, there will be resistance. If this resistance is too strong, then your transformation is dead.
By listening to these key people as to why things are the way they are today, you will get engagement and learn a lot. First, the key person or resistor will see you are making an effort to understand. Second, you will learn what is important to the person, which is critical to making an argument for the “new way ahead”.
“Seek first to understand, then to be understood.” is straight out of Stephen Covey’s “The 7 Habits of Highly Effective People” and it works great when dealing with resistance to transformation. These key resistors are not bad people, they have concerns and if they are not dealt with properly, they will resist. By listening and understanding we are showing them respect for their experience, so they in turn will provide us with their perspective.
This new perspective allows us to address the concerns of the resistor. We can address their concerns in a number of ways, by either showing them how they are addressed in the new solution. By listening, we have have a way to deal with key resistors to transformation projects.
Conclusion
Listening is a skill. As a skill, a person can learn and hone it over time. However, as we have seen, certain people are more likely to be good listeners without any training. Therefore, you need to have those people, skilled in listening, dealing with customers, stakeholders and key resistors, if you want to have project success.