Let the developers talk to the customers

When somebody asks me how to motivate their developers, one of the first things I suggest is getting them closer to the customer. It’s hard to be motivated when you’re working in a feature factory, doing one task after another and never getting feedback from the people who are using that software.

Let that developer talk to the people using the software and all of a sudden they’re getting feedback. They start to understand why the feature is being built. They start to understand what problems the customer is trying to solve, and they start to empathize with that person.

I’ve been giving that advice for years, based purely on my own observations. Teams that regularly interact with their customers are more motivated and deliver better solutions than those who don’t.

The Agile Manifesto even has a line about this: “Business people and developers must work together daily throughout the project.”

So I wondered if there was any research that backed up my observations and there is, although it’s not specific to software development.

Adam Grant and his colleagues ran an experiment in a university call centre. The callers phoned alumni asking for donations, and a good chunk of that money paid for undergraduate scholarships. None of the callers had ever met one of those students.

Thirty-nine callers, split three ways. One group was called into a break room for ten minutes and met a scholarship student. They asked him about his classes, how he’d earned the scholarship, what he planned to do after he graduated. Five minutes of conversation, at most.

The second group sat in the same room, for the same ten minutes, with the same manager. They read a letter from that same student about what the scholarship had meant to him and discussed it amongst themselves. They just never met him.

The third group carried on as usual.

A month later they measured everyone again.

“The intervention group increased significantly in persistence (142% more phone time) and job performance (171% more money raised); the control groups did not.”
Adam Grant et al., “Impact and the art of motivation maintenance”

Phone time in that first group went from 108 minutes a week to 261. Weekly donations went from $186 to $503. Neither control group moved at all.

The letter group is what convinced me. Same manager, same attention, same room, same information about who benefits from their work. The only difference was whether a human being walked through the door. Reading about the customer did nothing.

So I went looking for the catch, because that result is almost too good.

There is one, and it’s in the third experiment of the same paper. This time they varied two things independently: whether people had contact with the person they were helping, and whether the work visibly mattered to that person. Contact on its own did nothing. Three of the four groups all landed between 25 and 27 minutes of effort. The only group that moved was the one that had both, and it landed at 30.

Contact alone isn’t enough. Contact is how we find out whether the work matters, and allows us to understand that we’re doing this for a person.

Grant found something similar a year later with lifeguards at a community recreation centre, a different group of people doing a completely different job. One group read four stories about lifeguards performing rescues. The other read four stories about the skills and career benefits other lifeguards had gained from the job.

The first group went from signing up for 7 voluntary hours a week to 10, and their supervisors rated them as more helpful than before. The second group dropped to 6 hours, and their supervisors rated them as less helpful.

Telling people the job is good for their career made them worse at it.

So what does this mean for a team? Not that we should schedule a customer visit and tick the box. The demo where a stakeholder nods politely at a screen share isn’t the mechanism, and neither is a persona on the wall or a carefully worded user story. Those are weak proxies for the real thing, which is a person, in the room, whose day is measurably different because of what we do all day. Take away either half and the effect disappears.

A quick disclaimer: I didn’t find research directly for software teams. The evidence is call centres, swimming pools and hospitals. The closest thing we have in our own field is a review of 92 studies of what motivates software engineers, where the most frequently cited motivator was identifying with the task: knowing its purpose and how it fits into the whole. That’s a related finding, but not quite the same.

Back to the point we started with, the closer the developers are to the customers, the better the results, and the more motivated we all are.

1. Grant, A. M., Campbell, E. M., Chen, G., Cottone, K., Lapedis, D., & Lee, K. (2007). “Impact and the art of motivation maintenance: The effects of contact with beneficiaries on persistence behavior”, Organizational Behavior and Human Decision Processes, 103(1), pages 53-67. The authors list the small sample as a limitation of the field experiment: the thirty-nine callers split seventeen, twelve and ten across the three conditions.
2. Grant, A. M. (2008). “The significance of task significance: Job performance effects, relational mechanisms, and boundary conditions”, Journal of Applied Psychology, 93(1), pages 108-124. The lifeguard result is Experiment 2.
3. Beecham, S., Baddoo, N., Hall, T., Robinson, H., & Sharp, H. (2008). “Motivation in Software Engineering: A systematic literature review”, Information and Software Technology, 50(9-10), pages 860-878. “Identify with the task” appears in 20 of the 92 studies they reviewed, more than any other motivator in their table.