ThoughtSpot dev lead: The modern developer relations stack - part #2
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…
In part 1 of this series, I described the modern developer relations stack as a technology stack that spans all the activities a developer relations team needs to gather insights into and improve the developer experience. Part 1 focused on usage analytics, user journeys and tutorials and documentation.
Part 2, this article will cover the remainder of the stack: code samples, community management, product feedback and attribution.
Code samples
I’m a huge advocate for as many code samples as possible. Make them complete apps, not just snippets out of context. Put everything in GitHub and promote pull requests from the community. Closely track GitHub stars, forks and NPM downloads to see what is resonating with developers. Use npmtrends.com to keep an eye on how your packages compare to your competitors. And why not try CodeTour for Microsoft VSCode too to add a little extra bling to your in-IDE experience.
Once you have your code samples available, make sure that they are easy to run and discoverable. At ThoughtSpot, we recently moved all of our developer workshop content to run via CodeSandbox to eliminate the need for local configuration saving a huge amount of time helping to debug attendees laptop setup and getting them to build apps much faster. Finally, make sure your samples stand out. Salesforce and Contentful do a fantastic job of highlighting their code in sample galleries.
Community management
At the heart of developer relations is the community of developers you serve. Many of us are familiar with Discourse and Slack for managing discussions, or Twitch for live chat, but where engagement fell between the cracks was what developers were doing across channels.
In recent years, I have seen a massive leap forward in tools to give teams a full picture of community engagement. Commonroom, Orbit and Commsor do a fantastic job of filling in the gaps to let you identify which content is resonating, who is engaging with it and which community members are most active across all channels and assets.
Product feedback
On the other side of community management is the importance of using voices of the community to influence product direction. Community members, especially MVPs and early adopters, have invaluable feedback for product managers.
Use Productboard or Airtable to capture developer feedback and aligning product priorities. Once you identify needs, Canny and Dovetail can help user research teams dig deeper into new market opportunities or developer motivations for a feature.
Attribution
I recently participated in a developer delations roundtable hosted by Sequoia Capital. I had proposed the question of what constitutes the modern developer relations stack? After a lively discussion, one of my peers raised the topic of attribution – how do you attribute developer relations activities to sales and pipeline. In general, I am pretty hesitant to measure developer success with sales as the need to drive pipeline can inadvertently impact developer experience, but I get the importance of it.
Out of all the elements of the modern data stack I have discussed in this article, attribution is by far the weakest from an off-the-shelf product offering.
Things are a little easier with developer-led growth products where a developer can add their credit card to signup for a service, but with sales-led and larger cost product lead growth, it’s tricky.
To measure attribution, I’ve usually had to create custom solutions on top of Salesforce Sales Cloud and mash-up insights from Commonroom or Krunchdata, plus custom event/attendee tracking tools to come up with an approximation of developer influence. Eg: Did a developer attend a workshop in the past x months and did a deal close shortly after?
ThoughtSpot’s Wall: I’m a developer first and always an advocate for a great developer experience.
Developer attribution is certainly not a perfect science and an area I am actively investigating more. What I would suggest is to spend time measuring how much it costs to acquire a new developer (commonly called cost-per-acquisition, or CPA.)
Having a clear understanding of CPA helps you decide where you want to invest the budget to acquire devs and measure the success of such investments. This is much easier to measure and more aligned with the goals of providing a good developer experience, than pipeline or sales attribution.
Closing thoughts
The notion of what constitutes the modern developer relations stack, as described in part 1 and part 2 of this series, has intrigued me for years.
Like so much of the technology I work with, it’s constantly evolving.
The elements of the stack however have stayed consistent ever since I sketched the idea on my iPad. The steel thread that ties all of this together and why I love working in developer relations, is the importance of providing a great developer experience. Without it, no matter how much time you invest in your developer relations stack, your product won’t be successful.
Build great products that developers love to use, then measure it to know how to make it better.