On June 4 and 5, DevXcon returned to San Francisco, taking over three floors of Dogpatch Studios. With 200 dev rel professionals in attendance, we watched 34 speakers share their successes, struggles, and strategies connecting their company with developers. In true dev rel fashion, we were fuelled by caffeine, snacks, and fabulous swag from the 18 DevXcon sponsors. Throughout the event, in sessions and during the hallway track, we discussed our latest approaches and hopes in an ever-evolving discipline. A small fraction of the excellent conversations are highlighted below.
While DevXcon is a sibling event to DevRelCon, there was extra emphasis on user interfaces and experience at this event. Who better to weigh in on experience design for developers than Peter Merholz, who helped create the modern application of the discipline.
Though Peter has never designed developer experiences, he had a clear take on the question. “The basic approach to designing an experience is going to be the same, regardless of the audience,” he said. “The specifics of where the UI lives will change.”
For some developer experiences, Peter reminded the audience that everything old is new again. “Usability testing is rooted in command line interfaces back in the 70s,” he said.
Later, Google’s Tao Dong brought examples of his user research work for developer audiences. Tao shared how you can bring users into your process when designing APIs, building tooling, and writing documentation. Tao recommended building off traditional user research to discover the mental model of how the user thinks the system works. Then you’re able to speak your user’s language, such as when naming API endpoints.
Several speakers shared how they think beyond “developers,” or at least expand who fits that title. At Docker, Mano Marks and his colleagues find themselves with a considerable audience that doesn’t write code for a job. Yet, this community includes individuals who run large systems. Mano uses the term “operator” to cover the various Docker audiences.
Similarly, Oana Mangiurea took on the myth that developers are power users. When we start from that frame of mind, Oana said, we excuse ourselves from creating more useful interfaces. That turns away developers, as well as others we might want to include. For Oana, she expanded her audience to include content operators, young video creators, and media companies.
Finally, Nexmo’s Sam Machin compared approaches when you’re selling directly to developers and partnering with them. The partnership model is more inclusive, but also comes with its own touchy issues. “What happens when developer competes with your product?” he asked. “And how will you handle mis-use and brand damage?”
Despite the downsides of extending the communities we work with, there’s far more upside to knowing our audience clearly. Even the event’s name is notable of the expansion of who is interested in these developer topics.
From both stage and hallway tracks, people were discussing the difference between developer relations and developer experience. Some think they’re essentially the same, though several companies in attendance have separate departments for each. How do we articulate the difference?
For Heroku’s Jeff Dickey and Nahid Samsami, dev rel doesn’t fall on their radar, but DevXcon caught their attention. Jeff has worked on the popular Heroku CLI for four years, so how a developer experiences Heroku is a huge part of his job. While Heroku has a team of talented developer advocates, there are many more who contribute to the developer experience. In this way, developer experience expands beyond developer relations.
You might not think of email newsletters as being a developer experience, but then you’re not Peter Cooper. Peter sends email developers want to receive. His Cooper Press has over 400,000 subscribers across 12 publications. Peter provided a bunch of tactics for clickable topics and staying out of the promotions folder. He also shared an over-arching approach to developer experience he credited to Kathy Sierra: “try to help your readers get better.”
Dropbox’s JJ Kass aimed to help her audience of developers by surveying them. When the results came back, communications like newsletters and email updates were at the bottom of the list. When your job is to keep developers engaged from afar, that makes it tough. JJ’s approach, like Peter’s, is to dig deeper and “only send them stuff they care about,” JJ said.
One way to get them to care came from Sentry’s Chloe Condon: make things fun. Chloe brought her musical theater background to dev rel, starting a camp-themed meet up that partners with new communities each month, and encourages developers to take photos with a human-sized squirrel.
Listening to what your developers want is job one in developer relations. Job two is making sure you share that with the product team. Okta’s Alex Salazar got the lesson in the power of developer feedback while he was CEO of StormPath (later acquired buy Okta). Developer Evangelist Randall Degges told Alex they should support language frameworks (Flask, Rails, etc.) and not just SDKs. Randall had seen developers struggle to connect their authentication platform.
As a CEO often must, Alex said no, imagining both the one-time and recurring costs of maintenance across those frameworks. Over the weekend, Randall did it anyway, and wrote a Flask in 30 minutes tutorial. This resulted in huge user growth for StormPath, which then pivoted their developer experience toward frameworks. Alex had seen the proof he needed to listen to developer feedback.
GitHub’s Brian Douglas shared how he improved developer on-boarding in his previous role at Netlify. Having witnessed developers struggle with their first deploy, Brian improved the process with a clickable template. Now it’s possible to decrease that first interaction down to one minute.
One big reason to look for developer feedback is, as IBM’s Erin McKean reminded the audience, “we aren’t our users.” For example, Erin had shied away from creating videos, because when it comes to learning, she would much rather read. When she asked some developers, she heard a different story. Now video is a major part of her program.
When a product is changing quickly, it’s especially important to seek developer feedback. At Slack, Bear Douglas is making sure every department hears about it. While anyone can be a bullhorn, Bear suggests that dev rel’s job is also to filter and funnel the feedback. “Bring good or neutral news as often as bad news,” Bear said, and seek out multiple ways to share: via email, at team standups, or—yup—in Slack.
DevXcon co-organizer Tamao Nakahara shared a story of internal communication at WeaveWorks. After the company launched a new product, the CEO wondered why people were talking about the old product. Tamao said it’s up to those of us that work in the community to set expectations with executives and other stakeholders. “It takes time and many conversations” to see a shift in product or strategy play out, Tamao said.
Adobe’s Matt Asay said it helps to start communication internally. “Feed internal developers first,” he said of his approach to developer experience. “If internal devs can’t understand the docs, neither will external devs.”
Indeed, so much of developer relations and developer experience comes down to communicating, that magic skill that seems more important than technical chops for most of DevXcon’s attendees and speakers.
The videos from DevXcon 2018 will published here over the coming weeks, along with more of the usual developer relations and developer experience news and insight. And next up? DevRelCon London 2018 takes place on November 7th and 8th.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?