In software development today, the folks developing most software programs are not the same people interacting with the users of the end product. This often times leads to software that misses the mark when it comes to expected functionality or application flow, because it is hard to understand what someone wants when you don’t know them.
With most Software firms, as software ages, requests come in from customers either through support channels or through sales and marketing. These requests are logged against a companies bug and feature database and are later accessed by the development teams. A typical developer logs into either an issues database, or a feature request list, selects the feature or the bug to work on, assigns himself or herself to the problem, then proceeds to work on the problem. If there is a question about the bug or feature, the developer will contact someone in support/marketing/sales/consulting for an explanation. Those they contact will give their interpretation of the feature and the developer will code to that explanation.
Today in essence customer facing people in sales, marketing, and support drive functionality within the products. This makes sense in today’s world as these are the people closest to the customer. They have the most experience listening to customer concerns, business scenarios, and hurdles to make the given business a success. In IT departments in most large corporations these are the Project Managers, and Business Analysts. However what if there was a better way? What if we freed our development teams to just find out for themselves what is the requested feature or bug? What if we allowed them to call the customers directly and ask them what was meant by their request? What if we allowed them to run screen shots, and demo’s through the customer in question. Then what? I believe you will have two outcomes.
- You will improve the emotional intelligence of your development teams.
- Your software will be a lot closer to meeting the needs of the market.
First of all what is emotional intelligence? Wikipedia tells us this;
Emotional Intelligence (EI) describes the ability, capacity, skill or, in the case of the trait EI model, a self-perceived ability, to identify, assess, and manage the emotions of one’s self, of others, and of groups[1].
What abilities does someone with emotional intelligence poses?
- Perceiving emotions — the ability to detect and decipher emotions in faces, pictures, voices, and cultural artifacts- including the ability to identify one’s own emotions. Perceiving emotions represents a basic aspect of emotional intelligence, as it makes all other processing of emotional information possible.
- Using emotions — the ability to harness emotions to facilitate various cognitive activities, such as thinking and problem solving. The emotionally intelligent person can capitalize fully upon his or her changing moods in order to best fit the task at hand.
- Understanding emotions — the ability to comprehend emotion language and to appreciate complicated relationships among emotions. For example, understanding emotions encompasses the ability to be sensitive to slight variations between emotions, and the ability to recognize and describe how emotions evolve over time.
- Managing emotions — the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals.
In other words, someone with emotional intelligence has the able to fully understand the person or persons they are talking to. They know the right questions to ask, and how to ask them, in order to get more information out of the people in question. They also know how to gain the trust of others so to make those they are interacting with more comfortable, and willing to share. These abilities are not something we are born with. It takes time, energy, and a willingness to learn and interact with people, in order to learn them. Most of all, a persons EQ can develop over time from simply interacting with other people.
However in today’s development shops developers spend most of their time interacting with software, and are completely detached from the world at large. Because of this, they rarely get the opportunity to interact with customers. Management mandates that customers – and sometimes consultants – don’t contact developers directly and that developers don’t contact the customers.
The most important aspect of software development is not which technology you choose, or the amount of lines of code you write, but whether the customer is going to be happy with what you produce. How close you get to their vision and goal sets should be the ultimate goal of any software development project.
But by limiting the interaction our developers have with customers we limit their ability to know what the customer really wants. For every layer of interpretive explanation, marketing->sales->product manager->project manager->developer you add risk to the process of getting the initial requirement correct. For example; ever play that game where 20 people sit around a camp fire, and tell stories around the circle? The first person tells a story to the second person, the second to the third, and so on. By the time that story gets around to the 20th person it’s completely different than it was at the begging. Well this game illustrates how people work. Every experience consisting of sound, audio, or touch invokes different emotions and thoughts within each person, because we all have our own vocabularies and experiences to draw from. These thoughts and emotions are then communicated differently to the next person.
Well if we deny our developers the ability to interact with the source, how can we ever expect them to fully understand the requirements or gain Emotional Intelligence? We can’t, which I think is how companies die, as their software gets further and further away from the actual business need.
The closer your development teams are to the actual need, the closer the developed product will be to the customers needs. This doesn’t mean that there is no need for marketing, sales, and support, and yes you will still have to manage time, scope, and development cycles, be they agile scrum based sprints or waterfall type methods. However the more connected your development teams are to the needs of the customers, the more they will be able to interpret the requests, and anticipate future needs as they develop because they will understand the requests better.
Ultimately your products will be better, your development teams EQ’s will be higher, your design sessions will be better because everyone has the right information, and your customers will come back to you for more.
Good point! You are right, developers working for an anonymous customer – it’s a real problem. I have read that in companies that build expensive yachts for rich customers, each worker has a photo of the customer’s family pinned over his workbench. Similar idea: Each worker should at least see whom he/she works for. Actually, if take it wide, we might add empathy to “must have” qualities of an ideal sowftare developer. Imagine an empatic emotionaly intelligent developer working in close contact with a customer… What a wonderful picture!
Unfortunately, these are more theoretical than practical reasonings. However, to move forward we first of all need to set a goal. Ideas of how to reach the goal will come later on.
I agree, I don’t mean to imply that development teams need to necessarily be on site with the customers, having lunch and coffee with them. However it is my contention that the sheltered developer is the failed developer time and time again. I used to be one of those developers. But sometime around ’96 I was told, in the only review I felt useful, that I needed to understand more about my customers and how they used the products. Since then I have been part of the teams of people who take the developed products and try to explain to customers how they can use them.
Ultimately the goal is always the same. Develop a tool that your customer can rely on to make their job easier. But if you don’t fully understand what their job is, how close are you going to come to satisfying their needs?
Empathy is good quality of customer relationships.. understanding how their current tools get in the way of successfully achieving their goal sets, can help you gain a deeper understanding of how to solve their problems.
If we take this approach to open dialog, and customer connections… won’t our customers, and therefor us, be more successful in the long run?
Yes, sure, we ought to love our customers, because our success is impossible without their success. Recently I have written exactly this in my blog. The problem is how to manage this developer-customer collaboration, which – no doubts – is very useful for the both sides. More often than not it happens by usual scenario: Generally everybody understands that productive, friendly, earnest communication is of absolute need, but in practice there always appear very-very urgent issues, very-very serious circumstances, all of them hampering such a dialogue between developer and customer. It is like bad habits or addiction: No one would dispute it’s bad to have bad habits or to be addicted, but still there are millions of alcoholics, drugs addicts and smokers. It turns out that understanding of what’s bad and what’s good is not enough.
I have also mentioned it in the last post of my blog: We really need some rules, something to regularize and organize our praiseworthy intentions to work effeciently, to be good to customers, to be flexible and productive.
What is the URL of your blog I would like to read it?
http://pswhere.blogspot.com
You are welcome!