What is Developer Relations and how do you get started?
Ben Greenberg is Lead DevRel Engineer at New Relic and previously served in developer relations roles at Orbit and Vonage - so he’s been doing developer advocacy/relations work since 2018. Ben made the transition into developer advocacy from serving for years as a community rabbi - and we also discuss why exactly that makes perfect sense!
The following interview has been edited lightly for clarity based on our original interview with Ben Greenberg.
What is developer relations?
(01:52): There isn't one single perspective and a lot of it is actually shaped by the contours and needs of the company that the developer relations team is situated in and their unique circumstances, and what they're hoping to gain out of this discipline embedded in their company.
Essentially, if you are a company that is either developer-first or primarily around a developer audience, you need to have people in your team who are engineers, who understand engineering, who can understand the pain points of being an engineer and what that's like to be working on a product, be part of a team and get it from the inside out so that they can speak to that developer audience, which is so integral to your business and to your community, and can also bring back that feedback.
It's a bilateral relationship, right? On one hand, they are projecting out and building out community for you with a developer audience, whether it's across language or stack or framework. At the same time, they're also bringing back viable feedback, filtering it and presenting it to product engineering teams in a way that's hopefully actionable and reducing a bit of the noise that can often be a bit overwhelming for product teams, and coming down to condensed concise feedback on iteration of the product and development of the overall developer experience.
It's being able to speak to the developers who are external users or customers, or whatever verbiage you want to attach to it. Being able to speak to them as peers and prepare materials, educational materials, learning materials as peers to help them unblock them in their work, using your tools. And at the same time, it's also being able to bring back that feedback, to understand the feedback, first of all, to be able to get what they're saying and then to be able to filter it and condense it and present it in a way that's actionable to product managers and to engineering managers to help in the product roadmap and growth of the product itself.
You started as a rabbi and became a developer along the way. What led you here?
(04:46): There are actually many people who either work professionally as rabbis and are now developers or just have the ordination, and then became developers. It's not a totally unusual path.
I worked as a professional community rabbi throughout a decade in the United States. I've always been a bit of a geek. I was the rabbi, but I was working on the synagogue website, and why was I doing that? It wasn't my job, but because I was just always so interested and passionate about technology and I didn't want to go through my life without a chance to do this work, to exercise that part of my brain to be more technical. And so I took a chance, with my wife's permission, to switch careers, take a big risk, and it kind of worked out. And the point where I am now is I was sitting in my first job as a Full Stack Developer at a financial services company in Long Island in New York, and I was getting a little antsy because I wasn't talking to anyone and I wasn't teaching, and I wasn't interacting. And I was like, "Well, this doesn't feel fully right either. Something is missing here."
Then I went to a conference, just as a developer. I applied to speak at a conference in Germany, JSConf, a JavaScript Conference. I met a developer advocate and that was the first time I heard about the term developer advocacy. And I was like, "Well, that sounds interesting. That sounds like being a rabbi but being technical, presenting and teaching, but about code." And it just felt like a natural transitional point for me.
When you're looking to hire, where are you looking? What should you be aware of? How do you get started?
(07:38): There isn't a single path. There is the trajectory from engineering to DevRel, which is a very standard path. There's also marketing into developer marketing, which kind of turns into developer relations, and which path is right for your company in so many ways depends on what your objectives are.
Are you hiring for this role to help shape developer experience, to help shape the API development? Are you hiring for this role to help shape your tooling around your open source projects? Whether it's your SDKs or helper libraries, or other tools? Are you doing this because you want somebody to be able to go to Python conferences and JavaScript conferences and give technical presentations, or are you doing this to help make sure that when you do general outreach to your developer communities, you don't put them off because they actually understand how to speak to developers? And speaking to developers and marketing to developers is very different than marketing to anyone else.
If you're going to just hire a general marketer to market to developers, you could be successful but you might very well not be successful. So hiring somebody with that rich developer marketing experience into this role is also really important, but you're not going to get the other parts, and hiring somebody with only developer experience perspective, you might not get more of the marketing parts. And so you kind of have to understand there's very few people who have both the developer marketing and the developer experience, who can give technical presentations and also help craft a cadence for a marketing campaign. Those are very different skill sets and it really depends on your priority.
Hopefully once you start scaling the team, you can hire people in their specializations. You get developer experience advocates and developer marketing advocates, and more technical and less technical, and to community folks help shape the meetup approach and the community approach. All of those can be wrapped up in a single person or a couple people, but you're going to have a hard time finding anyone who is equally strong in all those areas. And the different pathways people come up into the field is a bit indicative of where their strengths are and their skillsets.
Being from New Relic, you guys have a ton of people on the team. What is a challenge for managing this role and what are the challenges for the person in the role, seeing as it's so flexible and there's no one way to execute it?
(11:59): It is a challenging role to manage and a challenging role to be managed in because as an individual contributor, your role is not simply taking a task from the Kanban board and moving it to the in-progress and then the completed column. And as a manager, you can't solely measure the success of the person in the role by pure metric output. There is a qualitative aspect to the role that is a bit ephemeral or hard to capture, which has to be counted for. How do you measure the general sentiment of the developer community towards your company, towards your product?
If you can answer that question, you might have a very successful company on your hands, as a consulting firm because no one has done a great job of creating good KPIs that can definitively point the way and tell us, "Oh yes. We have grown our overall developer sentiment by 15% year-over-year." There's no real good way to do that and we use a bunch of substitute metrics instead to try and at least indicate if we're in the right direction, but all of them are substitutes for that, for what is essentially immeasurable.
So you have to be a person who's willing to live a little bit in the ambiguity, and accept that and have clear indicators of objectives. In this quarter, if your goal is content, you'll produce X amount of content pieces, which might produce X amount of engagement points in your engagement points, you may measure them based on level of engagement. An up vote might be less than a comment, which might be less than an organic share.
There are ways to create real successful measurements for people reporting in and for people who feel like they've accomplished something as the people who are reporting in, but you have to live a little bit in the ambiguity of it because it's not like a sales position where I do this thing and it led to this amount of new activations or new increase in usage. You can't, most of the time, point such a clear line between action A to outcome X.
With so much to do in developer relations, how do you start approaching what to work on? How do build a budget when this is all so new?
(15:05): It really depends on your stage. If this is your first time hiring the DevRel person in your team, you have to give them a lot of autonomy in their first task to help shape a budget and to present what their projections are. It should be modest in the timeframe in order to prove concept and to move forward.
So if it's the first half year, this is what I'm projecting for my goals, this is what I would like to see in the first six months and to accomplish that, I'm going to need to execute X number of things, and projecting to cost this amount of money. My budget comes after what I want to accomplish.
First I need to understand what I want to accomplish. Then the budget then helps me to find the cost structure for what I want to accomplish. It's not, "Give me a budget and then I'm going to fit something into the numbers.”
It's not a one-and-done when the person says, "This is what I think." It's a conversation. You can have a back and forth and come to terms, but let them take the lead because they are the professional in that discipline, and then create the budget after you've done the program planning.
You're based in Israel, your company is on the West Coast, your audience and your title is basically EMEA. How do you approach hiring - does it matter where a DevRel sits?
(17:47):
It matters for some things. If you want to implement a regional strategy in a certain place, having somebody with deep familiarity of that region or that community, or that country is very helpful. So let's take for example, EMEA - that's not a region. That's a collection of time zones. That is hundreds of regions. Hundreds of distinct cultures and languages and nationalities and unique circumstances. My official role is I'm the Lead for DevRel in EMEA. That means that I have an entire continent with hundreds of countries in Africa. Europe, every few miles is... every few kilometers I should say, is another country. And of course, the Middle East is it's entirely its own thing. And within the Middle East, there's a bunch of sub varieties of cultures and things like that.
So if I want to implement a regional strategy in a place, I can't just say, "I'm going to hire somebody in San Francisco to be developer advocate in Germany." I need to hire somebody with familiarity with the German developer community, with the nuances, the developer tech ecosystem in Germany, understanding the industry that's there perhaps, and probably most likely with some fluency in German, who can give conversations and have talks and presentations in German.
But if I'm not implementing a unique regional strategy for a place then where the person sits or where they physically live doesn't matter in my mind at all. It's about what they bring to the table and their overall approach and their overall willingness to learn and their interests and excitement and passion for technology and sharing that with other people, that's what's much more important than their physical location with that one exception that if I'm hiring in a regional place, I can't ignore the regionality. I can't say, "Oh, I'm hiring in France. Let me hire a developer advocate in India." You're not going to yield as much success if you're not going to hire somebody who's French for a French role.
Between the travel and the speaking, and everything else that you're doing, how do you manage your calendar?
(20:33): In Israel, they put that little sticker on the back of your passport, once you checked in to go through that security step. The back of my passport is so thick with stickers that every time I hand it to the person that goes through to the metal detector, they give me a bit of a look like, "Who are you? Why does your passport have so many stickers?"
Travel is inescapably a significant part of developer relations. The past couple years during the height of the pandemic, I think I personally really suffered in the role from not being able to engage one-to-one with the communities which I'm engaged to work with. I really benefit from one-to-one, face-to-face, or one-to-many, mainly face-to-face. I find anything else to be a poor substitute for that.
Not being able to have that at all for the past couple years has been really tough. There's nothing like being able to sit in a room with, or at a conference at a booth or engaging over drinks in a pub with other developers and hearing the feedback directly, and being able to then immediately in real time, ask follow-up questions, engage and get real feedback and real conversation and build a real relationship.
And I've been to all the iterations of remote virtual events. I've seen the ones where you're an avatar and you go through different game rooms and I've been to the Zoom conferences and all the different SaaS companies that've been created to create virtual experiences. They all are subpar, all of them. None of them come close to it. And at this point, I have to be really convinced to engage and participate in a virtual event at this point.
I'm so burned out from them and the return on them has been so sparse, both from a sponsoring perspective, the financial investment in the virtual event, but also from a speaker perspective, giving a workshop or giving a presentation. When I'm standing on the stage, a developer event, and I see the faces of people, I feed off of those faces and it changes the whole pace of the conversation, and I can't get that in a Zoom.
You have to do travel intelligently. You have to do it deliberatively, strategically. So there's different ways in which you can think about strategically where you should go, why you should go there, how often you should go? Initially for a new developer advocate or even a not new developer advocate in a new role, they get very excited.
So [let’s say] I got accepted to speak at a conference in Indianapolis. I may live in Tel Aviv… Let me fly to Indianapolis and speak at this conference for that one time. Your company, your team have to ask the question, does the investment of the cost and time and burn on the person, does that justify the one talk at this conference in Indianapolis? Both with speaking and also with sponsoring. They're different considerations but they're related to each other.
How do you choose where you or your team should be, event-wise?
(24:38): That question's near and dear to my heart because I spent the first couple months in my role here developing a decision matrix strategy for our event engagement in New Relic, in the developer relations team. So we created a scoring chart where every event that we basically asked the entire company to give to us every developer event that they think is interesting. We community-sourced internally, from all the engineers and the rest of the developer relations team, what are all the events globally that you've either been to, you've heard good things about that you would think we should be at? And we created a list - in the few hundreds. And then scored it based on our matrix of values, and we came up with rankings based on that list.
We then used therankings to work with our field marketing team to make outreach to these events, to get cost structure, and then ask what's the cost and what's the possible return? And how many attendees are there? And are the attendees within our range of personas that we wish to speak to? And what's the benefits and the regional priorities? But first, we scored them and ranked them and by doing that, we're able to chop off a huge chunk that were not on our priorities. And I have to tell you, some of those conferences that we chopped off for this year, were ones that I personally really enjoy going to.
And we did that process as a working group and we did it intentionally that way because someone like me or anyone who feels biased towards a certain thing would not unnecessarily leverage it against other things because, "Oh, I really love that conference. I really want us to be there. Let's make sure we spend $85,000 on it even if it doesn't match any of the expectations that we need or goals."
So I lost some of my favorite conferences in this process. I think we all did, but I hope that what we've done so far, and we're in the midst of executing on this year, what we've done so far has been to be really deliberate in where we spend that money and put our time and our people in the conference engagement that we're doing.
What makes a conference really good for you? What are your favorites?
(27:01): I like coding in a variety of languages but I'm very attached and associated with Ruby as a programming language. So I tend to be a bit of a Ruby addict. Any Ruby conference, I love going to them. It's a bit on my dream to go to RubyKaigi, which is one of the best Ruby conferences. It's in Japan. I have not been there yet and it's on my bucket list.
Also conferences that are geared towards people who are new to developer world or new to software development, or are more open on the human side of things, tend to also attract me personally.
I love documentation. I don't do a lot of docs right now in my current role, but in my role at Vonage, I was the maintainer for our docs platform. And so I'm very attached to the notion of docs and the importance of docs. I've spoken to a few of them and I've yet to attend one in-person because of COVID, but it's been on my bucket list to attend the one in Prague and the one in Portland.
That's why it's important to have that balance with other people in a working group so that you make sure that your decisions are not entirely privileged by your own personal interest. Otherwise New Relic could be at every single Ruby conference in the world and I would be at all of them, which does not make sense for us as a company.
Within DevRel culture, there's a lot of talk of burnout, mental health, and sticking with it vs knowing when to take a break. Can you shed some light on that?
(29:20): It's a tough job because it's not one thing. It's not a developer and it's not a marketer and it's not a product manager, and it's not a technical writer. It's all of those things in one. So you're constantly juggling. In any single day I could be attending a product meeting, discussing product roadmap, talking to our technical writers and iterating on a piece of content, and then going to talk about our next event strategy and our event engagement, then going to work on a sample app in our open source repositories.
And then from there, having a one-on-one with people reporting to me. And just constantly pivoting. And the day is long because there's so many things to do. When you have a successful DevRel team, everyone wants a piece of them because they bringing skills in all the areas that every other team is interested in, especially at a developer tools company or developer first company,.
Everyone knows that engineers are on the pedestal. That's our customer, that's our user. And we have this team in our company, which is obsessed with the developer. And so your sales, your marketing, your account managers - every single person wants to have a slice of DevRel.
And you want to have those conversations because you want to inform the direction of the company in general, because you know that developers don't only interact with you through your docs and your APIs and your SDKs. They also interact with you through your sales managers and through your account managers and through the marketing they see, and through the booth that they're going to engage in when they go to that conference. And so all of those things, you want to have touches on because all of those things will impact your developer community, but that can be exhausting.
Burnout is definitely real, which is why I encourage people to take healthy vacations. If summer's a downtime, take an entire month and just take it off and just go away. You don't have to physically go somewhere. Turn off your computer and just step out of it. Take breaks throughout the week if you need it. Especially if you're working for an American company and live abroad, your average day could start early in the morning because you're working with people in your region and then end not till 8:00 or 9:00 PM at night.
Don't feel guilty if you want to immerse in an audio book or go to the pool or hang out with your kids or whatever, because you work really hard and give yourself that break. But then also the people that you report to, whether they're in your team as a DevRel manager or they are out of your team and they're part of the reporting line, they need to have that understanding and to give that flexibility and look for work output and not work expenditure.
Don't measure success based on the amount of hours put into something. Measure success based on what was achieved. Don't get caught up in the calculation of days in and days out because that's old school, that's from a different era. It's about work output and it's particularly true if you want to mitigate burnout in the DevRel field.
How can people start out in developer advocacy? What would you tell them?
(33:54): There's a lot of great resources out there.
· There's a newsletter, Developer Avocados, put out by two former colleagues of mine. It's a free newsletter. Get weekly in your inbox with articles and podcast recordings, curated for you essentially.
· There's another newsletter put out by Mary Thengval, Developer Relations Weekly.
· Developer Relations Conference was in-person before COVID and has been experimenting with virtual environments since, called DevRel Con.
Fortunately, they have all their archives online and available accessible. You can watch any of the past workshops and presentations. I have a couple up there. My first one I gave there was in 2019 on from rabbi to DevRel. So the skills from rabbi transitioning to DevRel, then I gave another one about community organizing into dev. There's great content from a lot of advocates across the field on DevRelCon.
In general, you'll notice that developer advocates are everywhere. If you want to meet a DevRel advocate, just go to a developer conference and you'll find many of us there.
