Measuring developer experience: The superpower of today

As a social scientist and Pluralsight’s VP of Research Insights, Cat Hicks examines how employees respond to their work environment, colleagues, managers, and other senior leaders. During this breakout session from Pluralsight’s 2022 Navigate event, she and Mozilla’s Mike Hoye discuss how organizations can strategically and meaningfully improve the developer experience.

If you’re on an engineering team, you’ve likely attended your share of panels on empathy and developer happiness. You’ve probably left the sessions inspired and ready to create a work environment where developers can thrive.

But even the most motivated leader can struggle to turn this inspiration into action. As Mike pointed out, these presentations offer adjectives, not verbs. To create a better developer experience, leaders need an actionable plan.

Look for “magic levers” you can pull to improve the developer experience. Talking to developers about what truly affects their lives will give you the confidence to make positive changes and close the gap between what you think developers need and what they actually want.

Cat reflected on her study of one organization’s code review process. The development team had a good process in place, yet they struggled to get everyone to implement changes. They tried scheduling different times for code review and instituting new targets, but nothing seemed to work.

When her team spoke directly to the junior developers, they found that even when the developers received good feedback, it was framed in a way that made them resistant to implement the changes. Receiving feedback that was unnecessarily harsh, from someone they didn’t know, did not foster trust. 

Essentially, it was the social aspects of the process, not the process itself, that the junior developers resisted. What the team needed was more trust, not poorly timed, negative feedback.

Teams can avoid this type of situation by “moving quality to the left.” Or, as Mike explains, making a series of small course corrections early in the process. Building this change management into the process has a tectonic impact on the overall quality of the product. 

Cat remarked that she’s often asked to offer interventions when it’s too late to have a meaningful impact. Moving measurement to the left allows leaders to actually track the developer experience using metrics over time and make small, strategic adjustments along the way (instead of massive shifts all at once). 

This improves the developer experience by streamlining the process, reducing a collection of errors at the end of a project, and building trust among the team.

To further deepen trust, take a strategic approach to communication between senior and junior team members. During code reviews, for example, developers receive feedback that is often tied to job performance. If they only hear performance-related feedback, they may feel insecure. This can lead to risk-averse developers, which can impact innovation.

Code reviews are often the only time junior developers have one-on-one access to senior developers. Junior engineers need more opportunities to discuss growth and development outside of performance-focused work sessions. Do your junior and senior developers have access to each other outside of feedback sessions? If not, the culture isn’t set up to help junior developers feel supported and encouraged in their work.

To this end, good leaders focus on what Cat and Mike view as productive failure. “One of the things I’ve noticed from those engineers who make an impact is this really accurate understanding of productive failure. This idea that when we fail, we have to take a transformative approach to it. We have to think not just about getting stuck and mired in the moment; we have to be thinking about the future,” Cat said.

Leaders who embrace productive failure help their teams thrive. After all, mistakes are central to how people learn. Experimentation, creativity, and innovation inevitably lead to risk and the potential for failure. People benefit from experimenting and making mistakes along the way because it informs their next step. 

Mike explained, “Our responsibility as leaders is to create a culture that allows for interesting, new mistakes.”

Cat and Mike acknowledge that leaders can’t just start from scratch; they need to find change opportunities within their current culture and adjust from there. To get started, they suggest speaking with your developers to understand their experience, workflow, and culture. 

Change the tone and purpose of these conversations by asking teams what’s going right. One of the panel attendees said that at his organization, developer teams are asked every three months what’s going well, what can be improved, and how every member of the team is doing. Then, the feedback is incorporated into their processes going forward.

Cat applauded this strategy and noted that carrying the data forward over time is another easy win for leaders. If you’re not using developer feedback to enact change, then this type of exercise doesn’t improve anyone’s experience.

Teams need unified incentives and measurements for a cohesive developer experience. As a leader, you need to share clear goals across the organization so everyone can work towards a shared endpoint. Without clear communication, developers won’t understand how their work adds value. Even if they’re meeting targets, developers might not be able to see how they fit into the big picture. 

Unclear goal structures also prevent developers from understanding how their failures can contribute to growth and better products. Developers might be tempted to quickly dismiss their failures to avoid negative feedback. But as Cat explained, “You’re bleeding important, interesting value if you can’t learn from your failures.”

“Organizations struggle to close the circle on quality improvement when they don’t make failure part of the process,” Mike agreed. If your organization wants to improve, then your teams must do post-mortems on projects and record their learnings in issue trackers.

As a leader, it’s your responsibility to create a culture where failure isn’t a dealbreaker. Cat and Mike outlined the following steps to help leaders create a safe space for innovation:

1. Get very specific about what you want to change and how you can measure it, then move what you can to the left.
2. Work to understand the problem and the history around it.
3. Collect the right evidence using good survey tools and proper lead time.
4. Implement your changes. More specifically, implement your changes, then wait. People need the time to experience the change and adapt to their new reality.

“Once people experience work in an environment where [they] have a positive experience of learning from failure, where values and incentives are aligned with [their] own personal values as well as with goals as an organization…people don’t go back to not having that,” Mike said.

Teams that feel safe talking about their successes and failures will ultimately build better software, better teams, and better organizations.