Most people think that developer relations (DevRel) means your job title is either Developer Advocate or Developer Evangelist. Is this the case or is there anything more? At Codemotion Amsterdam in 2019 we assembled a panel of developer relations folks who shared their perspectives:
- Thiago de Faria, Head of Solutions Engineering, LINKIT (moderator)
- K Rain Leander (at the time) technical program management and open stack community liaison, RedHat
- Don Goodman-Wilson (at the time) Developer Advocate. GitHub
- Floor Drees, Senior Developer Relations Program Manager, Microsoft
- Jason Yee (at the time) Developer evangelist, Data dog
How did you get into developer relations and what does it involve?
People’s journey into DevRel is wide and varied, indicated by the speakers. According to Jason: “I’ve always said that past Jason is much smarter than presenter Jason, I am an idiot. But apparently past me found the solutions to a lot of technical problems and was smart enough to document them either in blog posts or random things like. For a while, I had the number one Google result if you look for how to do a software raid in OpenBSD, which was kind of cool. Because past me was super smart, current me has no idea how to do that. So don’t ask me how to do like software raid arrays, but that led me to leading communities and the combination of writing documentation and reaching out to other developers and teaching people.”
Floor shared that her role involves product marketing: ” I would be basically be doing marketing towards developers and writing blog posts, like a technical blog post about the challenges that our engineers would face. And then make sure that they would find a developer audience and make it into an abstract for USP for a conference, make sure that there’ll be on stage representing the company that we’re working for, mostly for our open source projects.”
How do you see your DevRel role inside a company?
In developer advocacy, a lot of people think it’s just marketing. Or it’s trying to push people to do presentations that look like sales pitches. Panelists were asked if they were part of marketing, where they were positioned and how they see their role inside a company.
According to Floor, “officially, within Microsoft, I don’t do much with marketing unless it’s for these type of events (conferences) where I make sure that these events are sponsored and there are stickers and stuff. But otherwise, I don’t report to marketing.”
Within RedHat, DevRel is officially within the engineering department according to Rain, “but we work closely with marketing. I think though it’s important to take a second and define marketing in today’s world, marketing is now just information that you put out there.”
At Github, Jason is under marketing in a team called developer marketing. “And there’s two teams under that Developer Relations and our education team. When I think of marketing, I think of lead generation, right. So our field marketing team, for example, is responsible for going to conferences, collecting leads, passing them onto sales for validation.
But we don’t do that in our team, Nevertheless, we are in marketing because we are responsible for crafting the message that we want to pass to developers, right? We want to shape the way that our company is perceived. We want to shape the way that our company perceives our audience.”
At Data dog, DelRel is under product. As Jason notes, “Actually product is an interesting sort of place because it’s not quite engineering, our siblings are product owners, which is a nice place because product owners talk to our customers and get feedback about our product. When I was at O’Reilly, I was under marketing. And I feel like that’s a great place as an engineer, you learn more about what marketing does, and you get these skills.”
Do you still write code?
A lot of people that may be considering to go into this field may see it as a step away from engineering. How do you cope with not writing production code anymore?
Jason explained “We actually do write some production code. So within my team, I try to everybody on our team tries to maintain at least a little bit of something in production in order to keep our feet in the game.”
Rain notes that as you’re troubleshooting, ideally, you’re writing your documentation. “If even if it’s only in your comments within the code, and you’re you’re in meetings, you’re coordinating with other developers with project managers. Like there’s, there’s always aspects of your job that are not code.”
She still contributes very much to OpenStack. If I didn’t, I wouldn’t be able to keep in touch with the project as well.
Jason offers a different perspective “I don’t write code for production. That is the most liberating thing. As an engineer, I get to code for fun.” He, however, notes that in some ways, that actually raises the bar for your code as it requires understanding both in house and externally.
Good DevRel resources
An experienced devrel in the audience shared the challenge of applying for roles where hirers had no real understanding of the role or what they were aiming to achieve. Despite a decade of experience “I was not hired because I had no marketing degree. But from the other side, I was not the right person because I have no experience in programming for a production project.”
The panel was quick to offer a plethora of suggestions for good resources (watch the video to go through all of them.) These include:
- The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success
- DevRel Weekly and other newsletters
Jason – also suggests, “I think the most useful thing, like from the first interview is to have ready a story. Because this is what we do. We tell stories, right? Have a story about yourself, where you’re the protagonist? And you outline the problem that they face (and you should do the research to understand the problems they face) and how you’re going to solve that problem for them. This allows you to frame the conversation right, not about the skills that they think you ought to have now, but about the skills that you can both agree that you need to achieve the goals that you lay out.
And then, you can maybe even then begin to move the conversation away from like a super heavy technical interview or something like that. So I’ve had to always do technical interviews that just seems to be par for the course. But they were always because I think either I’m interviewing with people who really get Developer Relations or I’ve been persuasive in my storytelling, they find a way to skew these interviews in a way that aligns with what I’m putting on the table for what I canprovide with my skill set. So be proactive. That’s my advice when you go into an interview, take control, right by offering a compelling story.
He also suggested getting involved in an open source project to gain more experience. “But that’s not only writing code, but like a lot of interaction with people. Even more than that you’ve obviously already been doing so that might be a way forward as well.”