4 tips for a better developer experience

Recently, our SVP of Cloud Transformation at A Cloud Guru, a Pluralsight company, sat down for an interview with Jason Valentino, Sr. Director of Developer Experience and Member Identity at Peloton, to discuss the developer experience that powers the home exercise and media company. 

When it comes to developer experience, Jason believes that setting the tone at your organization has a multitude of benefits—including developer happiness, which drives better code and, ultimately, a better customer experience. 

We asked Jason which operating principles he considers to be the basic tenets for the team’s developer experience, and he offered four key tips for creating a better one at your organization. Each of these continues to help establish the tone of the developer experience at Peloton, too. 

 

Align your team to the company at large

“If you find out you’re a group of SREs who are managing Jenkins that everyone else in the company dreads talking to, you’ve failed. To avoid that from happening, you should be using the same technologies and development processes as the rest of the company. As a leader, you’re there to make developers happy. Shape your team like the rest of the developers.” 

 

Have a clear understanding of your measurements that matter 

“I call it not weaponizing the DevEx org. If DevEx becomes a tool of getting compliant stuff done left, right, and center—which sometimes it needs to—you’re focusing on the wrong thing. Tech leaders should measure how fast developers are moving, building tools, and analyzing areas to be improved. For example, every encounter with a human-reviewed process, like a help ticket, is a testament to a previous failure. In order to understand these failures, we need to find, measure, and log them before figuring out how to eliminate them.”

 

Develop prescripted onboarding processes. 

“At Peloton, we have a saying, “Don’t let perfection be the enemy of good.” For [us] it's easy to strategize the perfect onboarding. But we’re not at “the perfect onboarding” yet. So how do you combat that? You create an onboarding class. Pull in the resources necessary to jump over some of these onboarding hurdles. 

For example, when our new hires sit down, they have a couple classes on Life at Peloton. They also have a global Peloton program that the L&D team created called The Warm-Up. After that, they begin Engineering at Peloton. Then, they learn the overall architecture of how the bike works. After these classes are finished, individual leaders come into the room to solve a problem within the team. The global IT team is also in the room to ensure all engineers have access to the things they need. So, while it’s not this beautiful automated Swan Lake production, the developers are putting their first PR in by day three. Which is amazing.” 

 

Friction = opportunity  

Drew Firment jumped in the conversation with his take on why friction “sucks” but ultimately can provide invaluable learning experiences for those involved. 

“In Julian Simon’s recent blog, Technical Evangelism from the Trenches, he says to “embrace the suck” because “technical evangelism is an uncomfortable job by design.” 

I love this sentiment because everything is not going to be perfect. But don’t push it under a carpet. That friction represents an opportunity for you to learn, and for the developers to learn. And ultimately, that “suck” could be what’s preventing the ultimate customer experience. 

It’s uncomfortable. 

And it’s embracing that level of being uncomfortable and listening to a developer say, “This part of the process sucks.” That’s something you, as a leader, can lean into as an opportunity to improve the developer experience.”