Supercharge your career with a tour of duty in DevRel

Jordan M Adler: My name is Jordan Arthur. I'm the head of developer engineering at OneSignal. I look after our SDK engineering and developer relations teams. I'm also an ambassador. And I wanna talk to you about tour of duties in DevRel.

And what that means to me is essentially taking two or four years of your engineering career, spending it in developer relations to really broaden your horizons and skills, and we'll dig in deeper on some of these impacts later. But first, you know, thinking about folks who maybe aren't even really considering DevRel for a career, you know, you're really thinking about, hey. I've got some software skills. What can I do with them? Well, you can be a software engineer.

You can generalize and just be a software generalist. You can specialize in mobile, Android, iOS, some other domain of expertise, perhaps on the back end, particular language that's interesting to you or particular problem space too. I know folks who have dedicated their entire careers to things like hotword detection, you know, artificial intelligence. And by digging really deep in one problem, they can drive the cutting edge. But there are folks early in their career that are not sure what they wanna do.

Software engineering, of course, generalists or specialists is just one of these and often a core branch, of of software practitioner roles. But there's also site reliability engineers. These are the folks who keep things running. QA engineers who, ridicule software to death, torture it, identify all the problems with it, and help us build better software. Sales engineers who go out into the, marketplace and meet with potential customers and help them understand how they might technically integrate or evaluate the solution technically.

Partner engineers who meet with particular partner organizations and ensure that the implementation of certain business processes are working well. Solutions engineers who think about, okay. You know, what are all the different ways sales engineers might want to go out there and get folks using our product? Solutions engineers kind of create a database and manage database of those solutions. Support engineers who help folks, get on board and and follow-up with any particular developer support needs they might have.

Of course, there's technical program managers, folks who run programs like, you know, bug bounties or, beta programs that might have to have some software skill in order to be effective in running those programs. Technical product managers, so these are folks who are product managers, but they manage a a highly technical or perhaps a software product, and so that deep software expertise is necessary. Technical account managers, like partner engineers, have a similar sort of relationship with a particular business, so they manage a relationship between a business on an engineering level, between two businesses, technical writers who focus entirely on or predominantly on the development of technical content and documentation, and developer advocates, aka evangelists, who can often carry a lot of different roles within that title. Many times, especially in startup settings, it's filling in whatever gap that's needed. And so to give you kind of a little bit of context, here's a fairly typical 125 person kind of SaaS org chart.

And this is just to give you an idea of kind of, you know, this this size of organization is, at a good point where functional departments are starting to make themselves clear, but they're not super granular. And you can get an idea of across the board, you know, what are the different places engineers might find themselves in a start up or or software company. And I think you're looking at support engineering. You're looking at sales engineering, solutions engineering, developer relations, software engineering, site reliability engineering, data security. These are all areas in which you can take those core software skills and bring them to bear.

And so, essentially, there are many roles that leverage software experience, sorry, software expertise in a SaaS company. So why why developer relations? What is developer relations? Well, developer relations at its core and kind of the the the core part of the function, you know, within the organization is to develop expertise as a developer, produce content for for marketing purposes, be that content marketing, event marketing, social marketing to developer audience to, you know, hit growth metrics, measure the impact of that work, and through the measuring of the impact of that work and engagement with the community, develop kind of the expertise, and secondhand experience by empathizing with developers. And the consequence of that is your improved product quality and operational efficiency.

And then you take those insights and you build out the next few months of the DevRel road map and use that to build more code samples and more content and so on and so forth. And, you know, this flywheel process of going out there, talking to people, building empathy, understanding use cases, seeing where the gaps are in the resources available to developers, filling in those gaps. And in that process, developing the empathy that enables you to build better content and so on is the core of the developer relations organization. And that will get broken down into different parts depending on the size of the org. And so the context here is really start up size, so we're really talking about dev advocates as a kind of catch all role.

And with that context, I think you, you know, can consider the fact that developer relations, in particular, like, early stage dev advocacy teams, have broad functional competency. So software engineers will leverage that engineering expertise. SREs will leverage that engineering expertise, but also that engineering operations expertise. You know, sales expertise is a core part of what sales engineering does. Marketing expertise is something solutions engineering needs to be cognizant of at all times as you're building out these different profiles and different use cases for particular solutions.

Business operations is really critical to, technical program managers or support engineers and business development and and products and developments kind of within the mindset of partner engineering and solutions engineering as well. But developer advocates developer advocates have the opportunity to kind of contribute to the these core functions across an organization. So you leverage expertise in all these spaces. You interface with with all these these kind of functions. And you also, through your day to day work, identify opportunities.

Hey. Here's a new partner that we might wanna develop, an opportunity with or or some kind of solution with. Passing that off to the business development team is a unique opportunity that developer advocacy gets that other kinds of organizations don't necessarily or other teams or or roles within an organization don't have the broad set of opportunities to develop that functional competency. Developer relations also has broad technical competency. So if you're joining a startup and that's built in, you know, Ruby web client using Postgres and Kubernetes and on a on a Linux stack.

Well, that's the depth of your engineering ability that you're gonna be able to develop. The depth of technical skills sorry, the breadth of technical skills that you're gonna be able to develop are really the choices made by that particular system. Whereas in developer relations, your technical competency is as broad as the reach of your developer offering. So if you're targeting folks in in, different back end languages or different front end development systems or kind of cross platform game development tools like Unity, you know, DevRel gives you a a greater opportunity to develop technical competency in a broader set of technical domains than, say, a core engineering role would do. And so, ultimately, the thing to be cognizant of is developer relations activates all of the company's resources against the developer persona, and therefore, as a consequence, gives you a great opportunity to develop skills that are kind of across the company or or evenly distributed throughout the company.

So why join DevRel? Well, broad technical scope, like I said. So if you consider a company like OneSignal or Auth0, you know, you have the opportunity to work kind of on the front and the back end. If you're working on something in Google Cloud or a more granular solution, maybe something that focuses on, you know, observability, right, that might be targeting more of a back end system. So the exact technical scope will vary depending on the type of product that it is, but you have that kind of broad technical scope.

It gives you the opportunity to develop kind of, skills across disciplines, become more of kind a t shaped engineer and and develop the expertise that kind of helps you make your your your particular domain expertise more effective. And in that way, there are three kind of dimensions of skill growth opportunities that DevRel offers and quite broaden all three of these. Those functional skills like software engineering, product analysis, business intelligence, business development, sales, marketing, and jobs, the things that different you know, teams within an organization are ultimately responsible for, you get to be part of the loop in those things and have the opportunity to develop functional skills for those spaces. But you also have technical skills as a domain or dimension of growth opportunities. Right?

We talked about front end and back end development, but there's also kind of understanding CICD is an important part of being able to talk to your customers and getting them to understand how to best maximize the value out of the solution that you're offering is understanding their workflow. And so software configuration management comes into it. Other kinds of skills, software design kind of comes into it. And then you have the opportunity to develop those social skills, those core skills, project management. Right?

Project management is not a skill you have to develop as a software engineer. You have one or two tasks at a time that you're focusing on. But in developer relations, you are constantly juggling many different tasks with many different stakeholders and many different moving parts. And so it really forces you to develop these project management skills in a way that you would not otherwise have to do. Public speaking is another space where this is true as well.

I think for public speaking, there are lots of different, examples of this, but certainly you can imagine there are opportunities to speak publicly. Market research analysis, technical design, measuring the impact of your work, resolving conflicts. So these are all core skills that, being in DevRel will force you to take on in ways that being a core software engineer will not. And, of course, there are lots of networking opportunities. You know, getting out there and talking to developers will give you an opportunity to meet with them.

You'll also get to meet with product managers and designers and folks in lots of different functions that you would not otherwise get the chance to do. And so the important thing to take away here, developer relations affords unrivaled skill and network growth opportunities. So why hire Xdevra? Well, the folks that come out of developer relations teams, they tend to have excellent communication skills. They've had to take broad concepts and, make them comprehensible to multiple different kinds of audiences and multiple different kinds of levels of technical competency and often in areas where they had no domain expertise, you know, months ago.

Right? So you come in, have to learn a lot, and and educate folks in all sorts of spaces, gives you excellent communication skills. Customer empathy is a core characteristics of ex DevRel folks. Right? Developer relations spends a lot of time thinking about that holistic developer experience, understanding what the impact of it is, trying to improve it, and as a consequence, developing empathy for the customer in ways I think that are not necessarily captured well, certainly in any other role in an organization.

Market awareness. Developer relations folks have to be cognizant of, what market they're operating on, who the competitors are, what the problems, you know, that the solutions that they're referring to or working on behalf of solves, other ways to solve those problems. And so being an effective developer relations engineer or developer advocate requires that you have a strong understanding of the market. And, of course, impact orientation. Right?

You're not gonna be successful long term within the context of DevRel without trying to optimize that impact and measuring that impact. And so software engineers coming out of the developer relations organization often have a key understanding of how to, you know, measure and and validate the impact that they're having. And so I would add that savvy having that savvy hiring managers know that ex DevRel SWEEs are well rounded, empathic, customer focused, organized, and impactful. And so with that, I would conclude and share that, you know, a tour of duty in DevRel, two to four years, will make you a t shaped engineer, expose you to many different engineering specialties, develop your cross functional skills, totally explode your professional network, force you to understand market and market forces in ways that you did not before, force you to become a better communicator and develop that broad based empathy, and also cause you to optimize, measure, and articulate your impact. Now the one thing it will not be is it will not be easy.

Thank you so much.