DevRelCon London 2017 retrospective

Author

Leslie Hawthorn DevRelCon London 2017

Leslie Hawthorn DevRelCon London 2017

On December 6th, the third iteration of DevRelCon London took place at London landmark the Barbican Centre. With 20 speakers, 235 registered attendees and 10 sponsors, the conference offered a deep-dive into the latest developments and problems to solve in the evolving dev rel space.

Where the ‘squishy human parts’ converge

The day opened with remarks from GitHub Student Program Manager Joe Nash. With 26 million users, 1.3 million of them students, GitHub touches the work of everyone in the developer space in some way. It’s a place where open source comes to life. It’s also where ‘community’ begins to form. Just like GitHub, the concept of community touches just about every part of the tech industry – but, as keynoter Leslie Hawthorn, Developer Strategist at Red Hat cautioned, the term has become so widely applied, it risks being denuded of meaning.

In open source, Leslie said, dev rel people are often doing the work of the traditional product manager, augmented with the responsibility of dealing with ‘squishy human parts’. Navigating the fact that a dev rel role can encompass any number of things was a common theme throughout. And, by extension, the tendency of businesses to view the work of dev rel as a wider extension of the sales funnel, rather than the people doing the groundwork to build a sustainable trajectory for a technology.

Google Senior Staff Developer Advocate Ade Oshineye, who has seen a lot of dev rel cycles come and go, had some interesting thoughts in both of these areas. Google is prolific in its product release, and has been a pioneer of embedding dev rel in product teams. However, Ade too has witnessed many different permutations of the role. A big responsibility when leading a dev rel team, he said, was ensuring that you remained vigilant in articulating, and re-articulating, the purpose of the team.

“You have to be able to explain to your team, and all other teams, why your team exists, and why it matters. If you stop doing this, your team will stop existing. You need to map your organisation and your ecosystem. You need to have a map of all these things, and how your purpose fits in.” And, he commented, you need to be aware of any points of leverage where your team could make a difference.

Finding perspective

Ade suggested dev rel should be viewed as “Bi-directional advocacy; bridging between the developer community and the product teams, and sometimes, annoying both sides.” .

Looking at things in a wider context also formed a core pillar of the talk by Erin McKean, Developer Advocate for IBM.  Boldly, considering how early in the day it was, Erin plunged the audience into epistemology – “the science of knowledge”. Dev rel, for her, is very much about helping developers to fulfill their epistemic goals –  or in most cases, helping to meet them halfway in their drive to learn all of the things. Supporting them to do this was a recurrent topic.

Developer marketing

DevRelCon London offered multiple opportunities for people in the space to up their dev rel game, split into tracks along the lines of developer marketing and experience. On the marketing side, Melinda Seckington, Technical Manager at Futurelearn, led a beautifully visualised session on the art of slide design, offering ways for the audience to make sure their signal beamed far stronger than any noise.

In a similarly practical vein, Tristan Sokol, Developer Advocate for Square, gave concrete tips for ‘winning’ at StackOverflow.

As conference organiser Matthew Revell noted in his closing address, over the years, DevRelCon has expanded its catalogue of speakers from just practitioners of dev rel to incorporate the people that need to work with, and understand, dev rel teams. A wider range of perspectives are, he said, essential for dev rel teams in 2017. In this respect, Matt Bernier, Developer Experience Product Manager at SendGrid, led a session focusing on the intersection of dev rel and product management, and how to overcome the disconnect between the two.

As Matt explained, there are common objectives on both sides; both want to create products and experiences that customers love and value, but whereas dev rel might talk to customers on an almost daily basis, product simply doesn’t get that opportunity. Working in closer alignment, with better communication can help speed up product delivery and make for better outcomes on both sides.

Martin Gontovikas, VP of Marketing and Analytics at Auth0, echoed Erin’s remarks about appealing to developers with things that touch wider subjects by publishing ‘green field’ resources that would be universally useful to developers, with perhaps just a small nod to product. Being a company that acted in the best interests of developers, had, he said, ultimately been directly instrumental in the success of the company’s dev rel strategy.

Developer experience

Openness (with a side of bravery) was the order of the day for Hoopy Developer Experience Consultant Cristiano Betta, who led a live teardown of Sendgrid’s API. As he probed the API from a developer perspective, Cristiano was able to throw up several useful take-homes for the audience for thinking about the developer experience beyond the first integration. Moongift CEO Atsushi Nakatsugawa also had some clear-cut best practices in his talk on the art of DX messaging.

Scott Stroud, Lead UX strategist at National Public Radio (NPR) offered a look at how the redesign of the NPR developer centre had enabled his team to create something that catered just as well for developer needs as the radio did for its listeners.

Nexmo’s Adam Butler, Technical Lead for Nexmo Developer, had further tips on this front is his talk, ‘DocOps: engineering great documentation’, explaining how Nexmo was finding its way towards writing “consistently great” documentation at scale.

As several presenters noted, dev rel teams need to have explicit metrics in place to ensure their team is protected within their company. Helpfully, Platformable Analyst Mark Boyd offered a series of learnings for the sometimes frustrating process of demonstrating the value of an API strategy.

Shaping the build; shaping the world

Anil Dash, CEO of Fog Creek Software, closed out the event with a powerful reminder of how far dev rel has come over the past few decades. From the early days of his career, when developers were often an afterthought, to the current era, when organisations will go out of their way to provide all the support (and snacks) a coder might need.

Programmers, and the decisions they make in the software they build, are shaping culture in the 21st century. As Ade Oshineye remarked in his opening address, dev rel teams have a responsibility to encourage companies to think about the implications of what they are building. Creating, “not just from a bits and features perspective, but from a making a better world perspective.”

But, to be successful in this, Anil demonstrated, they need access to investment, resources, support and strategic focus. He’s put together ten core community sourced principles to help dev rel people to advocate for these things, which come together to form what he terms ‘The developer relations bill of rights’ (depicted, helpfully, in the Tweet below):

Whatever you envision when you think of ‘community,’ DevRelCon London clearly demonstrated the need for evangelists, advocates, epistemologists, and all the people who might place themselves within their orbit, to come together and share their ideas, problems, and thoughts. And, if the stream of social media posts and enthusiastic ‘hallway track’ chatter was anything to go by, DevRelCon London proved once again the ideal platform for this exchange.

Videos from DevRelCon London will be published here soon. Your next opportunity to join the international dev rel conversation will take place on April 22nd 2018 in Suzhou, China. Sign-up to the newsletter to get the latest on all things dev rel, and for future event announcements.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.