Tale of two definitions for developer experience
Guest: Luke Kilpatrick
Guest: Luke Kilpatrick
Luke Kilpatrick, developer marketing leader joins us and discusses the importance of building trust with developers. We touch on the two competing definitions of developer experience we see today and some of the tools internal developer experience teams use.
Luke cautions against placing demand generation metrics on your developer relations team and offers advice when joining a new company and building internal relationships.
Note: This is an edited and condensed transcript of the podcast and will differ slightly from the original recording.
Interviewer (Sid Maestre): Hello, and welcome to the podcast. My guest here today is Luke Kilpatrick. Luke, why don’t you tell us about yourself and the journey that’s brought you here today.
Luke Kilpatrick: I started my career in tech as a graphic designer and tech writer for a telescope manufacturer in Rockford, Illinois. Writing manuals helped me understand how people learn. I taught myself how to code for the company, including writing a shopping system, which was much harder back then. I worked as a developer for different companies long before moving to California in 2007. That’s where I met Sid—through the ColdFusion user group in San Francisco, which I later led. I also co-managed Fire on the Bay, a fireworks user group, with Sean Corfield. I eventually founded the Photoshop user group but passed the reins over to Sid so I could focus on Fire on the Bay.
Interviewer (Sid Maestre): It was this community experience that launched us into the world of developer relations. Tell us about some of the places you’ve been since.
Luke Kilpatrick: The Adobe Community Groups marked my transition from being a developer to working in marketing and developer relations. Dev marketing wasn’t really a term yet at the time, and we were creating the space for it. While you joined Xero and Lob, I joined VMware, then later worked with Ted Patrick, one of Adobe’s chief evangelists, at Sencha. From there, I landed at Atlassian, where I worked on the ecosystem team and helped developers build apps and plugins for JIRA Confluence and Bitbucket products. Atlassian was an amazing place to work, and I stayed there from when there were 700 people until there were 4,000.
Interviewer (Sid Maestre): When I joined Xero, I gained a new perspective on developer relations and developer experience. I learned about ecosystems and app partnerships, and how the SaaS product was driving a lot of revenue. I was faced with the challenge of making the product more sticky and creating features for customers without requiring engineers to build everything. The power of the ecosystem was one of the most valuable things I discovered while working at Xero.
Luke Kilpatrick: At Atlassian, stickiness was one of my favorite measurements of a successful developer relations or marketing program. We found that if a customer installed or customized even one aspect of the product, they were 87% less likely to churn, which is a significant number for a SaaS business. This metric was used to justify budgets for developer marketing and relations programs, as adding utility to the core product specific to a business makes it hard for customers to switch to a different product.
Interviewer (Sid Maestre): It’s challenging for customers to make a direct comparison when there’s a complex ecosystem supporting a product. It’s not just about features, but also the other plugins and apps that create the overall experience. So, after Atlassian, did you work in other DevRel positions?
Luke Kilpatrick: After Atlassian, I joined Nutanix and helped organize Dev Days before our annual .NEXT conference, which had around 5,000 attendees before COVID. We invited Gene Kim, the author of the Unicorn Project and the DevOps Handbook, to talk and bring developers and operators together. In the morning, we had lectures and panels, and in the afternoon, we had labs with Nutanix experts helping attendees. The goal was for attendees to leave knowing more than they came in with and be better at their jobs, making the conference worthwhile.
Interviewer (Sid Maestre): It sounds like you provided an in-person developer experience, by building community, and connections which are a critical pillar of developer experience.
Luke Kilpatrick: Building trust is a crucial aspect of developer relations and marketing, but it has become challenging due to the lack of in-person events in recent years. Technology cannot replace the value of meeting someone face-to-face and building a personal connection. Developers are known for having an aversion to marketing, making it challenging to sell developer-focused products. For example, Linear B’s Git stream faced criticism on Reddit for being a corporate tool despite being helpful for enhancing and automating pull requests.
Interviewer (Sid Maestre): Agreed. The same message posted online versus spoken at a conference can be interpreted completely differently, losing all the context and making you seem like a corporate suit trying to push technology someone doesn’t want.
Luke Kilpatrick: Developer relations and marketing aim to endear themselves to developers, who typically enjoy being the smartest in the room and sharing new technology. Marketing generates awareness, while DevRel provides support once the technology is implemented. These two functions are merging into a unified “developer experience” team. Their goal is to provide a cohesive experience for developers interacting with a company’s products. And we wanted that developer experience to come together so that if you’re a developer interacting with Atlassian products, you would have this type of experience.
Interviewer (Sid Maestre): How would you define developer experience?
Luke Kilpatrick: The concept of developer experience has evolved into two different flavors. The first is external-facing, focused on helping external adopters of a company’s API, tool or ecosystem through developer marketing and relations. The second flavor, focused internally, has emerged from companies like Netflix and is aimed at improving the developer’s experience in writing code and getting it into the CI/CD pipeline. This includes onboarding and platform engineering. While this is a positive development, it has caused some confusion about what developer experience is and what directors of developer experience do.
Interviewer (Sid Maestre): Do you believe that the skill sets required for the two different definitions of developer experience will continue to be distinct, or do you think they will overlap and merge in the future?
Luke Kilpatrick: There can be a commonality between these two, and people can come from outside the field as well. They can come into developer experience from various backgrounds, such as SRE or marketing. It’s a diverse role that requires wearing multiple hats and involves both human interaction and technical skills. The focus is on enhancing the developer’s experience with technology and people.
Interviewer (Sid Maestre): You mentioned onboarding and I think when it comes to onboarding, it’s important to consider the audience and communicate effectively, whether internal or external. The objective is to get developers productive quickly. In terms of internal developer experience, what are the tool categories, such as observability and team effectiveness measurement tools like code climate, come to mind?
Luke Kilpatrick: As members of an internal DevEx team, they focus on measuring change and utilize tools such as Code Climate, Jellyfish, and Linear B. It’s important that these tools focus on the team level rather than the individual level, as no one wants to be stack ranked. If a developer is having issues producing for the team, it should be addressed through management rather than metrics.
Other tools that aid developers include GitHub’s Copilot, IDE plugins for Visual Studio and JetBrains, and Swimm.
Having led developer relations teams, one of the biggest challenges I faced was justifying our existence, especially when developers were not our target market and had a history of having no budget. It was important to show the metric of stickiness and justify our investment in this space.
Another challenge was mistaking dev rel or dev marketing as the primary driver of top of the funnel marketing leads. While we do create awareness and brand recognition, our efforts are more focused on making things sticky and preventing churn. Great newsletters and drip feeds can help to maintain a user’s interest and expose them to more features over time. However, getting the initial name in the funnel requires help from growth, corporate marketing, and other teams. You cannot solely rely upon the dev rel team.
Interviewer (Sid Maestre): You’re saying that as developers progress in their journey, dev rel plays a stronger role in identifying and addressing any areas of friction. But once a customer has been sold, how do we know that they’re succeeding?
Luke Kilpatrick: Getting the right tool for the job is crucial. As a member of the dev rel team, I see us as Swiss army knives – we can do a lot of things. However, it’s important for us to focus on what we’re good at, which is providing a technical voice and creating technical content. While we may be capable of building play-for-click ads if we have to, I’m sure there are others who are much better at it.
Interviewer (Sid Maestre): In my experience with developer relations roles across multiple companies, I’ve developed a new approach where I prioritize strategy over tactics. When I’m hired, I’m often asked about my 30-day plan and what I’ll be shipping first to make an impact. However, I believe there’s a crucial period where I need to familiarize myself with the product and customers to create a solid strategy. So, when it comes to making strategic decisions before diving into tactics, what do you consider to be the most important steps to take?
Luke Kilpatrick: There are four main areas of developer relations: ecosystems, developer-required products, large-scale company implementations, and developer tools. It’s important to determine which area your DevRel focus is on because that will determine your actions and strategy. I believe in taking the time to develop a solid strategy before diving into tactics. This includes finding out what assets you have, determining what help you need, and building relationships with key people across the organization.
When I joined Nutanix, I met with 15 people across the organization in my first three weeks. Building relationships with people in marketing, support, engineering, product, and leadership is crucial to success in DevRel. I also like to talk to developers working on the product and salespeople who have closed the biggest and smallest deals to gain a holistic understanding of the organization’s challenges and opportunities. As a DevRel professional, we have an opportunity to be a communicator across silos.
Interviewer (Sid Maestre): Is there anything you think is overlooked when people start their developer experience journey?
Luke Kilpatrick: There’s fear in marketing departments of getting the tech wrong and being seen as foolish, but there’s actually more forgiveness in the marketplace than people expect. People are humans and have become more forgiving and accepting of being wrong. DevRel has a unique position to be a neutral broker and help find the best solution for everyone, even those not in the room, and this is something that should be embraced and done more of.
Interviewer (Sid Maestre): Thank you, Luke, for joining me today. It was a great conversation as always, and wishing you all the best.