Ben is speaking at DevRelCon San Francisco 2019. Join us on June 6th and 7th for the developer relations conference.
Prior to his talk, we caught up with him to learn more about his dev rel story.
Tell me about your role at Nexmo
Ben: My work at Nexmo lets me fully express two areas of my professional life that give me a lot of personal satisfaction and fulfilment. At Nexmo I have the opportunity to dedicate a lot of time to thinking about how we can best serve the community that utilizes our services, and I get to work on technical projects and build solutions.
As a Ruby developer advocate at Nexmo, I am focused on making sure that we are serving the Ruby community as best as we can. In that regard, we recently released a Nexmo Rails gem, that works as a wrapper around our Nexmo Ruby gem. This makes integration of Nexmo APIs into a Rails project just a couple of quick steps. I am excited about future enhancements we will be integrating into the Rails gem as time goes on. Additionally, I also wear the hat of a Nexmo Developer Platform engineer, which means that I get to continually iterate on our Nexmo Developer Platform; writing new tests, building new features, addressing bugs and more.
I love that my work intersects the technical and the adaptive, the community building and the coding.
What brought you to this point in your career?
Ben: I am a second career developer and really proud of that. I am proud of the work I did for ten years as a rabbi, community organizer and educator. Those experiences shape a lot of who I am today, and have enabled me to be in in this unique space of developer relations. I came into coding because I always loved technical thinking and critical problem solving, and I have always had a passion for technology. I discovered and pursued developer relations because once I learned about a career that afforded the privilege of being able to blend the work of building and sustaining community with coding I never looked back.
How does dev rel work at Nexmo?
Ben: Dev rel at Nexmo positions us to interface with product and engineering. Our greatest concern is catalyzing our community of developers for success. We are integrated with the development of our products to make sure that community feedback and input are essential factors in the process. We iterate with our colleagues cross-functions and cross-departmentally to continually improve.
Our team is remote-first and we span the globe in time zones and locations, from Seattle to Singapore and Columbus to Tel Aviv. Many of us are responsible for a specific language community, for example, I work with Rubyists. We all strive to feel ownership over the whole project, while being responsible for specific aspects.
Dev rel is one of those fields that is hard to apply metrics to, because so much of what we do is intangible. In that way, it reminds me of the clergy. However, we do work hard to have data and to be driven by data. Therefore, we measure things like self-reported developer satisfaction, brand awareness, click throughs, library installs and the like. Yet, at the end of the day, we remain aware that metrics are only as meaningful as their applicability and effectiveness to push forward improvement and growth.
What’s your dev rel philosophy?
Ben: Dev rel for me is a people centered job. How can I serve the people who rely on our products to so their work and accomplish their objectives? My success is measured by how successful are the people who rely on the documentation we write, the tools we build and the information we provide. It is centering the code on relationships and on people.
My dev rel is not sales. When I am at my best it is about people, technology and the intersection of the two.
What do you see as the big challenges for dev rel right now?
Ben: In an industry marked by specificity and exactitude, dev rel sits at a unique place that straddles the tangible and the intangible. There are real measurements that can be assessed to ascertain success and accomplishment, but they don’t capture the full picture. The full picture also includes items that are challenging to measure. How do you make the developer community feel? Often developers may choose a framework, library, tool, etc. that brings joy when building with it. In the Ruby community we are all about building a language that makes us happy to work with. How do you measure joy and happiness?
This elusiveness to full measurement, I believe make dev rel an area in a company that requires regular explaining and education to the rest of the company. Any thing that sits in a liminal space requires an investment of education to maintain in a larger infrastructure.
What are you hopeful about?
Ben: I am hopeful about so much. The dev rel professional community is speedily developing its own network of development and support that enables professional growth and internal relationship building. The field is growing rapidly with more and more companies understanding innately its value add. With all the growth there are new challenges, yet they are incredibly positive on the whole. This is a fantastic time to occupy a space in this privileged and unique role in the industry.
You can hear more from Ben in his talk, “From the pulpit to developer relations” at DevRelCon San Francisco 2019.
Enterprise and start-up seem like useful shorthand for a whole bunch of assumptions but how useful are they really when thinking about segmentation?
Write for us