This couplet of joint analysis pieces is written in full by Quinton Wall in his role as head of developer relations at ThoughtSpot.
As a company, ThoughtSpot likes to call itself a modern analytics cloud specialist that works in the ‘modern data stack’ space – it has core competencies in delivering natural language search and AI to perform data analytics and enable customers to automate entire business processes.
This series will discuss what software would constitute the best dev relations stack. From community management tools such as Orbit and Common room, how to use GitHub and NPM to track developer activity, mapping user journeys to tie it all together and more.
Choosing the right dev rel stack can make or break the success of developer engagement in your company.
Wall writes as follows…
I’ve been fortunate to work in developer relations for more than 10 years. I’ve experienced a wide range of roles; from being one of the first developer advocates at Salesforce, to leading developer marketing at Twilio, to running my own business helping tech companies to build their developer relations practice.
I’m a developer first and always an advocate for a great developer experience.
What is developer relations?
To me, developer relations is a discipline focused on two interrelated activities: increasing developer adoption of a company’s technology and ensuring developers have a good experience using this technology. You can’t have one without the other. If a developer can use another technology better, faster, easier than using tools they already know and love, they will. One of my early mentors in developer relations had a pirate flag hanging above his desk to always remind us that we are championing for the voice of the developer within the company.
I will never forget that.
Just like technology, how we track and measure developer relations changes rapidly. Over the past few years, I’ve been looking at what I like to call the Modern Developer Relations Stack. This technology stack spans all the activities a developer relations team needs to gather insights into and improve the developer experience.
In this two-part series, I will describe the goals of each layer and provide examples of vendors whom I believe provide products and features that can achieve the goals.
I always advocate establishing product milestones to measure developer touchpoints as early as possible. Define these milestones based on KPIs you want to measure and report back to the business. This may include KPIs to measure logins, API calls, user-agents to determine programming language, connecting to an external system, SDK downloads and more.
When I was at Twilio, we focused heavily on how long it would take for a developer to send their first SMS. We knew that the easier this process was, the better the developer experience is — and it is directly impacted how likely a developer would upgrade their account from free trial to a paid account.
User journey maps give you a clearer picture of how developers use your solution from initial sign-up to deployment. They can quickly highlight points of friction in products or gaps in documentation.
For example, many years ago at Salesforce/Heroku, Ruby was a massively popular language for developers using the platform APIs. Once we began looking at the user journey of Ruby developers, it appeared they were using Ruby and Salesforce APIs for large data loads. At that point, we had not designed the APIs to support bulk data. The result was a poor developer experience – things would time out, developers would have to write retry logic and more.
By mapping the user journey, the developer relations team was able to work with product management to release official bulk APIs.
Look at products such as Pendo and Appcues for in-app journeys and connect this to HubSpot or ActiveCampaign to proactively send email nurtures at different stages of the journey. Watch click-through-rates of nurture emails and adjust or create content to continuously improve activation.
Tutorials & documentation
It’s amazing how many companies forget about how important well-crafted documentation is for developer enablement. Developer documentation should be well structured, making it easy to get started and provide a clear navigation structure and access to global search. It should contain plenty of code examples in different programming languages, be constantly up-to-date and also allow community members to contribute feedback.
Use CLAAT for tutorial generation, along with Stoplight, Gitbook and Swagger to generate great API docs. Share collections on marketplaces like Postman and RapidAPI for easy discovery and consumption. If you can make snippets in docs interactive, this dramatically improves the developer experience – they don’t need to cut and paste just to try something out.
Hand in hand with interactivity goes the importance of a free trial. This year’s Stack Overflow developer survey indicated that 72% of developers use free trial environments to reach and discover new tools. Whilst I wouldn’t specifically include free trials as part of the developer relations stack, however, you should ensure that tutorials and documentation funnels developers towards free trials.
Summary & author bio
In this article, I introduced a framework for the modern developer relations stack and dove into the first three layers of the stack.
These initial layers are predominantly designed to learn more about the developer. With that foundation, you can begin to write documentation, code samples and better inform the product teams what developers need to be successful.
In part 2 of this series, I will discuss the remaining layers with an eye on delivering a great developer experience by focusing activities on what resonates with your community and helps achieve company goals.
Having spent nearly 20 years in developer relations and mobile app development, Wall brings his experience building vibrant developer communities and great developer experiences for companies like Twilio, Salesforce and Heroku — and onwards to ThoughtSpot, where he now leads the developer relations team.