Few people grow up thinking about a career in developer relations. Even those that study computer science are rarely exposed to this world. They are typically thinking about a career as a traditional software engineer or perhaps a product manager.
If you’ve found yourself reading this article, I’m willing to bet that you are already working in a technical field as an engineer or an engineer-adjacent role and are perhaps thinking about dipping your toe into the world of developer relations (if not and you somehow stumbled into this article not sure what developer relations is, I suggest you start by first learning about what developer relations is and why it exists).
So, how do you know whether moving into developer relations or DevRel is right for you?
Well, you’ve come to the right place, this article breaks it down for you. I’m going to cover the differences between being a product-based software engineer and an engineer working in DevRel, what the pros and cons of this move might mean, what signals in your own life are strong indicators that you might be successful in DevRel, and what the DevRel mindset is.
Let’s get started.
Software engineering versus developer relations engineering
Developer relations teams often consist of a variety of roles, not all of them are engineering-based, such as technical writing, program management, and community management, but for the purposes of this article, I am going to focus on the engineering side of DevRel.
This role typically has titles like developer relations engineer, developer advocate, technical evangelist, developer program engineer, or perhaps partner engineer. Most people working in these roles had a career as a software engineer in the past, so what’s the difference between being a software engineer on a product and a software engineer in developer relations?
Time spent coding
As a product-based software engineer, the majority of your time is spent working on features, fixing bugs, writing tests, eliminating technical debt, writing design documents, and so on. As an engineer in developer relations, there’s simply a lot less time to do all of this.
Developer relations teams are the connective tissue between 3rd party developers and the internal product and engineering teams. As such, you’re going to spend some of your time creating, building, and connecting with communities. You are also going to be collecting feedback and working with your internal stakeholders to make sure the product is evolving to better serve the developer community. This is going to leave less time to focus purely on coding.
Size of coding projects
This is not going to always be the case, but generally speaking, the size of the coding projects in DevRel are smaller. You’re building a proof of concept, a demo, a code snippet, or perhaps a client library. These projects are typically smaller in scope, can be owned by one or a small number of individuals, and take less time to execute than working on a core product.
Often, the artifacts you are creating is the code itself rather than something like a feature to be used by a consumer. Instead, your code itself is to be used by other developers within their own projects.
Large DevRel projects look different
A large DevRel project might have very little to do with coding. You might be building a community, overhauling documentation, amplifying knowledge about a product through videos and speaking engagements. These tasks will be on-going multi-quarter efforts, but have less to do with producing code.
Broad versus narrow
As a developer relations engineer, you often wear a lot of hats. It’s often good to be a mile wide and an inch deep, whereas being a mile deep and an inch wide can be really great as a pure software engineer.
Everyday in DevRel is different, you might be presenting at an event, followed by meeting 1:1 with high priority companies, speaking directly to C-level executives, meeting with your internal engineering team to provide design feedback on an API, meeting with the product team to relay community feedback, and then finally carving out a little time to put together a demo.
You are going to be part engineer, part product manager, part marketer, and part business development. From a technology stack perspective, you are likely going to encounter a lot of different stacks. Developers in the wild are not going to be locked into the same stack your company is using, so you have to be flexible and learn on the fly.
Focused on people
DevRel at its’ core is about people, while software engineering is often more about the code you produce. You still need to be a great engineer in order to authentically connect with other engineers and have the respect of the internal teams, but you need to care about people and want to make them successful.
Evaluation of contributions is different
With both a pure software engineering and developer relations engineering role your impact will likely be evaluated based on the difficulty and complexity of the problems you work on. However, while a software engineer’s impact is likely focused largely on technical contributions, a developer relations engineer’s impact will be in part based on technical contributions, but also take into account several additional categories of contributions such as
- community growth/support
- growth of product awareness
- product influence
- communication regarding product launches
- delivery of technical content
Now that you understand some of the differences between software engineering and developer relations engineering, let’s take a look at the pros and cons of making a move into DevRel.
Pros and cons of moving into DevRel
While I love working in DevRel, it’s not necessarily for everyone, and there are some trade-offs with moving away from a pure engineering role that you should be aware of prior to making the switch.
Pros:
- Requires being good at a different set of skills, which might be a better fit for you than pure engineering, creating a higher ceiling for your career than you may have with traditional software engineering.
- You have a chance to see the world. Most DevRel jobs involve travel and if you like to travel, it’s one of the best parts of the job.
- You’ll be closer to the people who use the product and be able to see the immediate impact of your work, which can be very rewarding.
Cons:
- There are less DevRel jobs than software engineering jobs, so picking this path may close off future opportunities.
- Most people understand the value a software engineer brings to a company, it’s not as clear in developer relations. You might not be seen as core to a company’s success and you may have to battle misconceptions about the role to prove your value.
- You will have to explain what you do.
DevRel signals
Most people transition into developer relations after already working in a technical role for some period of time. Typically, people that could be a good fit for DevRel have certain experience from their past that are signals that they might thrive in developer relations.
Besides having a strong engineering background, if any of the following is also true about you, perhaps you want to consider a slight career change.
- Actively participated in or organized programming events, contests, hackathons, or workshops.
- Spoke at technical conferences or meetups.
- Founded a company.
- Have a mixed background of engineering and product or project management.
- Academic background or teaching experience of technical subjects.
- Created an open source project or make contributions to open source.
Ideally, besides participating in some or all of these things, you actually enjoyed doing it as well :-).
DevRel mindset
The DevRel mindset is different than that of traditional software engineering. Since DevRel is about people, our mindset has to be one of empathy. We need to care deeply about people, namely developer’s success. Their success is our success.
This doesn’t mean a traditional engineer can’t have empathy, they certainly can, but it’s not necessarily core to their day to day duties and it’s less critical to how they make an impact.
In developer relations, if third-party developers can’t understand how to use your product, understand your documentation, and ultimately be successful, that’s on you. Either you are failing to deliver the tools, education materials, and assets they need, or you are not influencing the product enough to prioritize improving the developer experience. Making your community successful should be your driving force.
Finals thoughts
I feel lucky to have found developer relations or to have it have found me (check out my personal journey here). For me, it’s the best job in the world. It has allowed me to use and expand my breadth of skills well beyond what I would have been able to do in a traditional software engineering role.
Hopefully, if you’re thinking about making the move, this article helped. If you have questions or comments, please hit me up on Twitter — Sean Falconer.
