It’s not that often, at least in my life, that one has the experience of inventing a thing, only to find out that that thing was already “a thing”.
In this case, it was “Developer Experience”. After a year and a half of leading Developer Relations, Developer Content, Developer Marketing, Community Management and some surface work on SDKs, plug-ins and sample apps, I was frustrated with the lack of forward progress in our core product. We kept optimizing core database and enterprise enablement features over streamlining and improving the self-service experience for developers. Luckily our CEO and Chief Product Officer listened, and invited me to design how we should address the problem.
I advocated carving out a team of four product managers who would work hand in hand with Developer Relations, designing the onboarding experience for technical practitioners. We called the mission and the organization “Developer Experience” or DevX.
We took a soup to nuts approach, viewing the whole progression from initial awareness, through registration, getting started journeys and in-product up-leveling as a single unified experience. We clarified that the purpose of all of our design, outreach, education, event presence, and content was to accelerate and smooth the adoption and use of the product by technical practitioners.
No one had the “job” of bringing new developers to the product.
No one had the “job” of converting new users to becoming repeat users.
No one had the “job” of turning repeat users into enterprise customers.
We worked together on the whole experience, measuring everything and feeding back all of the telemetry into each part of the experience funnel. Anything that was causing friction, witnessed by DevRel during their workshops for example, was put into the product queue for improvement. Anything that could improve our ability to understand and help developers achieve their goals in trying the product went to the top of the cue. Any articles we could produce that answered developer questions and delivered them power got written and promoted.
This was “DevX”.
Imagine how shocked I was to notice that there are others in the industry who have "VP of DevX" or "Director of DevX" as their title. Imagine how chagrined I was when people started sending me articles about the emergence of DevX as a discipline.
I had to step back and be thankful. Thankful that the pattern that I was seeing as transformative for DataStax was being discovered and validated in other organizations. Thankful that others were explaining what my made up job title actually meant. And, thankful that there is a growing community of practitioners in this nascent discipline.
It takes a lot of clarity, and a deep commitment to actually measuring, managing, and making a difference to successfully evolve DevX.
I’ve talked with other DevX folks about the struggles to get away from episodic marketing, to extend telemetry beyond impressions and attendees, and to bring a scientist's discipline to iteration. Traditionally, both Developer Marketing and DevRel suffer from a lack of demonstrable strategic impact. Companies often cycle through investing and disinvesting depending on the beliefs of the C level execs and the available budget.
The only effective way I’ve found to end that episodic oscillation is to invest in data, and really pay attention to what the data is telling you. You have to augment the quantitative data with qualitative input (after all, the “experience” is a subjective goal), but getting both right takes time, patience and clarity.
I guess the moral of this story is that, to remove the X factor of not knowing what impact your DevX efforts are having, you have to invest in measuring and understanding the X factors which actually improve the experience.
You have to understand, quantify and then remove the X factors, to deliver the "X" in DevX.