Listening to a podcast by journalist and author Jon Ronson, I was struck by what he had to say about social media echo chambers and feedback loops. It made me think about the parallels between his observations and findings, and how we run user-centred projects. In particular, the importance of working in the open.

Who is Jon Ronson?

I came across Jon Ronson’s work through podcasts he produced for BBC Sounds, and he was interviewed by Louis Theroux for a series during pandemic lockdowns.

“Jon Ronson is a journalist, author and filmmaker. He produces informal but sceptical investigations of controversial fringe politics and science. His book So You’ve Been Publicly Shamed (2015) concerns the effects of public humiliation in the internet age.”

Wikipedia’s entry on Jon Ronson

So You’ve Been Publicly Shamed is a book by Jon Ronson. He recorded an abridged audio version, published by BBC Sounds.

Speed signs and feedback loops

Ronson’s book So You’ve Been Publicly Shamed was serialised and abridged for BBC Sounds, and is read by him. Away from project management and user centred design it’s a great listen and I recommend it.

Listen to the abridged reading of So You’ve Been Publicly Shamed by Jon Ronson on BBC Sounds

(If you’re outside the UK, the BBC have also published this to other podcast platforms like Apple and Rephonic).

In episode 6 he tells the story of the introduction of digital signs that tell you how fast you’re driving.

Speed signs – an excerpt from the book

“…in an article about a radical traffic-calming scheme tested in California in the early 2000s.The story-by the journalist Thomas Goetz-is a fantastically esoteric one. Goetz writes about how in the school zones of Garden Grove, California, cars were ignoring speed signs and hitting “bicyclists and pedestrians with depressing regularity.” And so they tried something experimental. They tried Your Speed signs.

The signs were curious in a few ways. For one thing, they didn’t tell drivers anything they didn’t already know. There is, after all, a speedometer in every car. If a motorist wanted to know their speed, a glance at the dashboard would do it. And the Your Speed signs came with no punitive follow-up-no police officer standing by ready to write a ticket. This defied decades of law-enforcement dogma, which held that most people obey speed limits only if they face some clear negative consequence for exceeding them.

“So why do they work?” I asked. The reply surprised me. “I don’t know,” he said. “I really
don’t know. I … yeah. I don’t know.”

Being a tech person, he was more interested in the radar and the casing and the lightbulbs than in the psychology. But during the past decade, the mystery has galvanized social psychologists. And their conclusion: feedback loops.

Feedback loops. You exhibit some type of behaviour (you drive at twenty-seven miles per hour in a twenty-five-mile-an-hour zone). You get instant real-time feedback for it (the sign tells you you’re driving at twenty-seven miles per hour). You decide whether or not to change your behaviour as a result of the feedback (you lower your speed to twenty-five miles per hour).You get instant feedback for that decision too (the sign tells you you’re driving at twenty-five miles per hour now, and some signs flash up a smiley-face emoticon to congratulate you). And it all happens in the flash of an eye-in the few moments it takes you to drive past the Your Speed sign…”

Feedback loops. You exhibit some type of behaviour… You get instant real-time feedback for it…  You decide whether or not to change your behaviour as a result of the feedback…

So You’ve Been Publicly Shamed by Jon Ronson

What’s this got to do with development projects?

This made me think about how feedback loops are important to our work too. We often practice agile development in our projects, and feedback is an essential part of that.

In agile projects we break the work down into small bitesize chunks (commonly known as sprints). We check in daily on how things are going, and we come together regularly as a team with our stakeholders to review what we’re doing and how we’re doing it. We also come together after a project is completed, to review how we did it and how we can improve going forward.

Our feedback loops of varying sizes help to adjust our behaviour. In particular, the retrospective meetings we hold at the end of each sprint serve the same purpose as the Your Speed sign.

So does that mean agile projects are perfect? No.

Feedback is limited in value if it’s not coming from the right places. We need to be working in the open.

In his story, Ronson goes on to talk about how social media facilitates echo chambers. Agile projects can fall into the same trap as social media trolls in their echo chambers.

Echo chambers – another excerpt from the book

“…in other ways feedback loops are leading to a world we only think we want. Maybe… they’re turning social media into a giant echo chamber where what we believe is constantly reinforced by people who believe the same thing.

We express our opinion… [and] we are instantly congratulated for this… We make the on-the-spot decision to carry on believing it.

The tech-utopians like the people in Wired present this as a new kind of democracy. It isn’t. It’s the opposite. It locks people off in the world they started with and prevents them from finding out anything different. They got trapped in the system of feedback reinforcement. The idea that there is another world of other people who have other ideas is marginalized…”

So what is an echo chamber? In social media terms, it’s a situation where you end up expressing your views to a group who already agree with you, validate your opinions and encourage your behaviour.

Avoiding the agile project echo chamber

In agile projects, it can be much the same.

If we don’t actively engage and involve stakeholders outside the team, if we don’t prioritise testing our assumptions and work-in-progress development with end users, and if we don’t play back what we’ve learned from research with users, we essentially operate in an echo chamber.

If we don’t actively engage and involve stakeholders outside the team… we essentially operate in an echo chamber.

Being in the echo chamber makes a project easier. There are fewer (if any) dissenting voices, there’s less pressure to reflect and potentially change tack, and so projects typically run more closely to what was originally envisioned. A lot like a waterfall methodology project, actually.

In our team we try to escape our echo chamber by:

• Having regular check-ins with project stakeholders so they know what we’re working on and why on a daily or at least weekly basis. This depends on the availability of our collaborators, of course, but we bend our schedules to try and fit theirs.
• Making sure we execute usability testing of our work-in-progress. Ideally this is with end users but we don’t allow difficulty in recruitment get in the way. We will as a minimum test with anyone unfamiliar with what we’re doing, who is able to play a role for us. (“Recruit loosely and grade on a curve” as Steve Krug says).
• Running open-invite playbacks of our usability testing sessions to let stakeholders see how users are interacting with our work-in-progress and contribute feedback on the usability issues they’ve seen.

Avoiding challenging feedback and living in echo chambers is more comfortable, no doubt. You can build software and services that you’re happy with. But are your collaborators, your customers and your end users?

We prefer to operate in the open, and improve what we do and how we do it as often and as quickly as possible.

In the end, it leads to better end results and better outcomes for our colleagues and students.

Read posts about some of our projects

• Future state for the degree finders
• Student Immigration Service enhancements
• Tuition Fees Service enhancements
• Student payments process enhancements
• Design sprints

Jon Ronson’s book

About So You’ve Been Publicly Shamed on the author’s website

Listen to the abridged reading of So You’ve Been Publicly Shamed by Jon Ronson on BBC Sounds

(If you’re outside the UK, the BBC have also published this to other podcast platforms like Apple and Rephonic).

Speed signs and echo chambers – a warning for software projects / Future student online experiences by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0