View profile

Technical people can talk to people, too

Deploy Empathy
Deploy Empathy
This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
I want to talk about a difficult topic today, and I won’t mince words.
If you’re a developer, data scientist, engineer, or other technical person, you’ve probably come across the harmful stereotype that technical people have bad people skills.
This “can code = can’t talk” idea is harmful and limiting.
So many people have internalized this idea and believe that because they’re good with technology they must be commensurately bad with talking to and understanding people, as if there is some magical scale between technical skills and people skills. Add to one, take away another.
Years of being treated like you must have bad people skills if you spend a lot of time on the computer compounds these feelings.

I admit it—this is personal for me.
I’ve seen first-hand how damaging and incorrect this stereotype is.
I’m not an engineer myself, but both of my parents are software engineers and I’m married to an IT engineer who does software. In fact, I’m the only person in my immediate family without a science degree (I studied the dismal science, economics, instead).
So I know for a fact that technical people can have people skills.
Organizations believe this, too
This goes beyond people’s internalization of stereotypes and how that influences their own behavior. It’s overtly baked in or implied through organizational practices as well.
It’s pretty common for companies insulate their developers from customers—even companies that otherwise do customer research. It’s often under the guise of “their time is too valuable to talk to people,” yet running undercurrent is the idea that if the developers were let near the customers, they would offend them and scare them away.
Or—even deeper—giving the product builders direct customer understanding would minimize other departments’ ability to influence the roadmap, because the developers would be able to see when an idea was truly borne of customer need vs. someone’s vanity project.
As one reader of this newsletter put it,
There are a lot of people who are afraid or skeptical of customer interviews because, at some point in their career, some politically-favored group weaponized their exclusive or privileged access to customers for purposes that have nothing to do with customers at all.
Breaking down these beliefs and practices can be transformative for a company. I’ll never forget what happened when a team I worked on started including developers in usability testing sessions as observers. Team motivation and engagement skyrocketed because people had built empathy for the users and knew what users were trying to do and why.
There was less “wait, why do we need to build that?” in our planning meetings and more “How can we help people do that better?”
The data shows it's also factually wrong
The 1993 paper “Voice of the Customer” by Abbie Griffin and John R. Hauser is the seminal paper on customer research.
The paper focuses on usability studies for new product development—i.e., given a product, can people figure out how to use it and does it do what they want it to. (These days, “usability” usually encompasses accessibility, too.)
They ran a variety of different tests to see how to most effectively pull out customer needs. Focus groups, individual interviews, single interviewers, group interviewers, and so on.
Here’s where it gets interesting (and comes back to the topic of this issue).
They tested whether the number of people analyzing an interview had an impact on the number of customer needs identified. They included a qualitative research expert, two groups of students, and four groups of engineering teams that worked directly on the products in question.
And what did they find?
"Voice of the Customer," page 11
"Voice of the Customer," page 11
Engineering teams were more effective at pulling out customer needs than a qualitative research expert.
And it wasn’t just because they were a team. (Working with a partner or team can increase the amount of information gleaned from interviews, because everyone brings a different perspective.) Yet the engineers beat the teams of students, too.
If the social stereotype were true, you might expect the engineering teams to perform abysmally.
But they didn’t.
Instead, they blew everyone else out of the water.
The expert only identified 45% of needs, but the engineers identified 68% of customer needs. That’s a 51% improvement!
What this means is that if I were pitted against a random group of developers from this email list, y'all would beat me.
How awesome is that?!
So the next time you might be tempted to think that just because someone—and maybe that someone is you—is technical, they automatically can’t understand customers, think again.
And if someone throws that stereotype at you, either overtly or implied, keep this paper handy. To whip out this paper would be the equivalent of if someone told you good writing never has sentences longer than 20 words and you handed them Proust. Accept no BS.
Hat tip to Kano Method expert Mathieu Dhondt for reminding me of that finding. Go give him a follow and subscribe to his newsletter!
Alt text of the relevant part of the image: Screenshot from the academic paper “Voice of the Customer.” On average, the analysts were able to identify 54% of the customer needs with a range of 45%—68% across analysts. The qualitative expert was at the low end of the range while the engineering teams were at the high end. The students were in the middle of the range. Chart showing distribution of identification of needs by various teams.
Did you enjoy this issue? Yes No
Deploy Empathy
Deploy Empathy @mjwhansen

A practical guide to interviewing customers

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
440 Monticello Ave, Suite 1802 #43146, Norfolk VA 23510