Tell us a bit about yourself.

Hi! I’m Ben and work as a Lead Developer Relations Engineer at New Relic as part of The Relicans. Previously, I was the first Developer Advocate at Orbit, and the Ruby Developer Advocate at Nexmo/Vonage.

My route to this field was a bit unconventional, and I am a strong advocate for people of all backgrounds finding their way into both tech, in general, and developer relations, specifically. I am a fierce believer in the fundamental truth that our teams, our companies and our industry is made more resilient, more representative and simply made better, by having folks from all walks of life involved in every aspect.

I was ordained as a rabbi and spent 10 years working on university campuses, synagogues and non-profits before transitioning to tech several years ago. My first job after bootcamp at Flatiron School was as a developer at a financial company in New York. However, I wasn’t quite content to leave the headphones on all day everyday. I wanted to meet other people, share knowledge and build community.

I discovered the field of DevRel first by meeting Chloe Condon at a conference, and after my family and I relocated and settled in Israel, I was fortunate to land my first role advocating and building tooling for the Ruby community at Nexmo.

What do you feel is the most important part of your job?

There are many ways to define the work that we do in DevRel, and each one of them reflects an aspect of the multi-faceted prism that is this discipline. For me, the most powerful encapsulation of our work is developer empowerment.

I empower developers when I create educational videos that equip them with the knowledge to build their own solutions. I empower developers when I write a tutorial that invites them to learn through application of principles and concepts. I empower developers when I build in public an SDK, a helper library or other open source tool that lets them focus on what is important to their work without needing to be stuck in the weeds of the idiosyncrasies of a particular API.

Most importantly, I empower developers when they know definitively that the feedback they offer is heard and acknowledged. Each and every single developer matters, and my most essential task is to make sure that is true for the company I work at and that it stays true.

What is something you’re struggling with?

The opportunity of DevRel is that it is so diverse in focus areas. This opportunity is also its challenge. Where to put emphasis on any given day, week, quarter or year? How to effectively divide time between the many different possible paths? This is something that I constantly think about and struggle with. Time is a finite resource, and by doing x, I cannot at the same time be doing y.

I am in my first role as a lead in a DevRel team, which means that I am helping to conceive and construct the work objectives going forward into the next year. How to translate the ideas, dreams and plans of an incredibly talented team of people into definitive and scoped items is my current iteration of this challenge.

To scope a project is to by definition limit it, and a collection of scoped objectives is inherently an organizational statement of: We are going to do these things, and strive to do them exceedingly well, but we’ve chosen not to do these things. I struggle with that limitation, wanting to resist the ultimately irresistible reality of time and resource limitation.

What do you look for when building your team?

The specific tasks of any DevRel role can be learned with the right investment of mentorship, training and resources. A person can learn how to write clear documentation, how to produce engaging livestream content, or how to build collaboratively with the community open source tooling.

What I find most important in filling the seats of the bus in a DevRel team is empathy coupled with a curiosity and desire to learn.

Empathy is different from sympathy. When I am sympathetic, I am hurting for you. When I am empathetic, I am hurting with you. That is not just a minor difference, rather it says everything about the kind of developer advocate you will be.

Do I strive to see your – the external developer/user – pain points in working with this API, product or service through your eyes? Can I see myself in your position as someone with perhaps innumerable tickets and tight deadlines just trying to solve a problem and needing the clearest and most helpful path forward?

The ability to do this work most impactfully hinges on the answer to those questions, in my opinion.

Furthermore, this discipline asks a lot of its practitioners in terms of skills and knowledge. I am less interested in what you currently know as a potential member of the team, and more interested in your wanting to know more. A personal practice of learning speaks louder than any existing skill set, because it broadcasts clearly that where you are today is not the end, but another point in your learning journey.

What’s one change you’d like to see in DevRel?

I think one area in particular that could benefit from a deliberative rethink is the way folks enter the discipline. DevRel has grown a lot in the past several years as a more mature field of work. Yet, it still too often sees its only source of new applicants from full-time engineering departments rather than cultivating a career path all of its own.

I have spoken with numerous recruiters and hiring managers working in the developer relations space who share that their primary field for finding entry-level advocates is by identifying charismatic, empathetic career developers who might be looking for a change of pace.

Why don’t we have a more thought out entry-level process that does not almost exclusively rely on poaching from a related but separate area?

To create a DevRel owned entry-level path would mean companies investing the resources to mentor and train new advocates. The training would by definition be different than for someone who comes from years as a developer, and that would not be a bad thing. In the same way, teams have carved paths to welcome and onboard junior developers, I’d like to see us systematically do the same for junior advocates that would be broader and more encompassing than transitioning a full-time senior developer into an advocate role.

The pipeline of developer to advocate will always remain a vital and valuable source of new folks into the field. If we are to become a fully realized and fully mature discipline it must not though be the only one.