Over the past few years since I began actively tracking trends and conversations about Developer Relations, it’s clear that Developer Relations is gaining steam in the tech industry and starting to be “normalized” in a number of ways. However, there’s still a knowledge gap when it comes to career advancement.

Unlike “Engineering Career Path,” which turns up 300 million results on Google, “Developer Relations Career Path” has a lot of questions but only one valid result: an amazing blogpost by Bear Douglas, Director of Developer Relations at Slack.

As a result, it’s common to find job descriptions for Senior Developer Advocate or Principal Technical Community Manager that look the same as an entry-level Associate or Junior Developer Relations role.

While we’ve made progress toward defining what each of the various roles means, we still have a long way to go with regard to career progression. I recently rolled out a Career Path with my team at Camunda, and in the spirit of driving the DevRel industry forward, thought I’d share the process of creating it as well as the final result.

Here only for a link to the path? I won’t make you wait…
Click through to see the full path as well as a summary for each level.

Why a Career Path?

Let’s start with the basics: why is a career path necessary?

As a Manager, a career path signals to your employees that you’re willing to work with them to accelerate their careers. While coaching and mentoring your staff in order to help them progress sounds like an obvious thing to do as a manager, this step is missed far too often in the tech industry. When the status quo is that tech professionals switch jobs every two years, retaining or promoting employees becomes a lower priority, which only perpetuates the issue. A manager equipped with a career path that gives direct and explicit guidance on how to move from one level to the next offers a clear way forward and indicates that the company values the career growth of its employees.

Note: When a small functional team is led by a caring and supportive manager, it’s possible to exist without an explicit or formal career path for the first few years. However, a career path becomes more important as the team scales beyond a few individuals in order to establish a clear progression of growth and mentorship.

As an Individual Contributor (IC), without a clear path showing a way forward, it’s difficult to understand where you should be in your career. What skills should you be still developing? What should innately characterize your day-to-day work? If you’ve been in Developer Relations for 10+ years but still have the generic title of Developer Advocate or Community Manager, how do you distinguish yourself from someone else who’s brand new to the industry?

A career path also assists in creating job descriptions. While the general day-to-day work might look the same for a Community Manager and a Principal Community Manager, there are different expectations for how that person will act, from the amount of responsibility that they’ll take on to their leadership and mentorship qualities. Having a specific definition of what makes a Senior teammate “Senior” makes it easier to decide exactly who you need to add to your team next as you can easily identify which gaps need to be filled and what skillsets those gaps require.

Lastly, establishing a career path for Developer Relations is one more step forward in creating a mature industry. It makes a bold statement that we know our value, we’re here to stay, and here’s our plan on how to move forward in our careers!

One quick note about the usage of “path” instead of “ladder.” While I’ve seen both terms used often, I see a “path” as a journey. While you’re joined by your coworkers, there’s no competition. There aren’t limited spots that people are fighting over. It’s professional development, pure and simple. You commit yourself to the journey ahead, checking your “path” to see where you are and making adjustments along the way in order to reach where you’re going.

A “ladder” on the other hand is more difficult to navigate as a group. It’s a single file, with one person reaching the top before the others. If someone does pass up other people along the way, there’s a good chance someone has gotten hurt or stepped on in order for that leader to reach their goal at the expense of those around them.

So what does this look like on a practical basis? At Camunda, the career path serves two purposes:

1. It helps me as a manager ensure that I’m taking an active part in working with each employee to advance their specific career. I believe people should be rewarded for their progress and a clearly defined path allows me to do that more objectively.

2. It helps my employees know where they stand. The career path offers them a transparent view of what’s expected of them in order to progress their career at Camunda. By measuring each teammate’s work against the career path, we can work together to quickly identify the gaps that need to be filled if they want to move to the next step and form goals to help them fill those gaps in the days, weeks, and months to come.

The Specifics for Camunda’s Career Path

Before we get into the nitty-gritty of what this career path actually looks like and how it works at Camunda, there are a few facts I should present upfront.

First, this path encompasses all three pillars of Developer Relations: Developer Advocacy, Developer Experience, and Developer Community, as well as the supporting functions of the team (e.g. Program Manager). No matter which specific role an individual occupies on the team, they should be able to find themselves represented in this path.

Second, while there are only 4 stages (DR1-DR4), there is room for growth within each of these. Within each stage, there is the understanding of a junior, mid, and senior-level salary range. Someone new to the role is expected to fall into the "junior" category, whereas someone who's been in the role for some time and is making progress toward the next stage on the career path will be mid-level. An individual who falls into the senior salary range for their role is expected to be at least 70% of the way toward the next stage.

Lastly, we aim to avoid the Peter Principle, which allows people to be promoted into failure because they're allowed to advance quickly without having proved their full competence and abilities. Because of that, I expect employees to be exhibiting the full qualities of the stage they wish to move into before they can apply for promotion.

Definitions

The path is based around two basic ideas: topics and complexity. Thanks to Daniel Meyer, Cornelius Suermann, and Roman Smirnov for laying the groundwork for this with the Camunda Engineering Career Path.

• A topic is a project, program, or general work output.

• The complexity of a project progresses from linear to structural and foundational.

  • A topic of linear complexity is one that builds on top of or uses already-existing structures and processes. This could include being a guest on Camunda Question Corner, creating an Airtable filter to view our events in a different way, or running a demo that someone else built. These topics can be handled by anyone on the team.

  • A topic of structural complexity builds on top of already-existing principles/projects but is either the expansion of the current scope of a project or a significant addition to the current program. This could include adding a client library or SDK for an additional language (we already have an example of one, so you’re building on top of the already-existing library of extensions and expanding it to include a new language). It also applies to the Camunda Cloud Documentation and tutorials - they already existed, but needed care and nurturing. There was a multi-phased approach that took teamwork and collaboration. Lastly, it includes projects like the DevRel CRM. We're using a framework that already exists (HubSpot) but adapting it to work for our purposes and collaborating with another team to make it happen. These topics are typically handled by DR2-DR4.

  • A topic of foundational complexity is a broader project that needs to be scoped from “soup to nuts” - ideation to execution. This might be a brand-new topic or it may be the refactoring of a current project. This includes projects like Hacktoberfest, which is brand new to Camunda and requires significant coordination and collaboration across teams. The Camunda Question Corner falls into this category as well – it's a new project that needed to be scoped, implemented, and measured to determine success. These topics are typically handled by DR3-DR4.

One concrete way to represent this came out of a conversation with Nathen Harvey:

TL;DR: With increasing seniority, DevRel professionals are able to complete topics of growing complexity in an increasingly autonomous way, expanding their impact beyond the scope of their own work.

Attributes/Values

There are 4 key areas that contain various attributes or values:

• Functional Skills: How knowledgeable are you in your particular focus area, with regard to the product, project, or program as well as the other stakeholders?

• Delivery: Are you able to deliver topics of an appropriate level of complexity in an autonomous way?

• Teamwork: Do you know how and when to ask for and offer assistance? Are you able to clearly communicate decisions and status updates?

• Leadership: How are you using your influence, both internally at Camunda and also in the broader technical community?

Within each of these key areas is a set of specific attributes and values that are measured.

• Functional Skills:

  • Product Knowledge

  • Feedback

• Delivery

  • Implementation

  • Transparency

• Teamwork

  • Communication

  • Collaboration

• Leadership

  • Mentoring

  • Empathy

  • Influence

You’ll notice I don’t call out specific technical skills here, or require that a DR3 also have the communications abilities of a Stage 2 Marketing professional. Don’t get me wrong -- I firmly believe that Developer Advocates have to have coding experience and all Developer Relations professionals should be able to have a high-level conversation about the technology their company creates.

However, I don’t need my Developer Advocates to prove that they’re up to speed on all the latest bells and whistles of Python 3.7, for instance. Here’s what I do expect:

1. They’re able to relate to the folks in our community on a deep technical level

2. They can provide valuable content that meets the needs of our customers (e.g. blogposts, sample applications, conference talks, etc.)

3. They know how to connect technical community members within the communities they participate in

4. They stay up-to-date on the relevant technical components for the products, projects, or programs they’re responsible for

Some attributes (e.g. transparency) are foundational attributes that won't need to progress much, if at all, beyond DR2. Others will build on top of the previous stages’ attributes and add additional success metrics or expectations. Holistically, each of the categories come together to illustrate the qualities, skills, and character traits that are expected from an individual in a particular role.

As you take a deeper look at the path, you’ll likely see that as an employee moves from DR1 to DR4, more mentorship and leadership qualities are required, both with coworkers as well as outside of the company. Developer Relations intrinsically has a somewhat unique opportunity to impact the larger technical industry, beyond our specific community members. My hope is that as employees progress in their careers, they’ll have a desire to give back to the larger industry and people outside of Camunda in addition to maintaining relationships with their coworkers and community members.

This expectation led to a fascinating conversation with a member of senior leadership at Camunda who isn’t as familiar with the broader value of Developer Relations. They were curious about this external influence, which gave me an opportunity to explain the need for additional leaders and mentors in the DevRel industry as a whole. As a Senior or Principal Developer Relations professional learns and grows in their own career, I expect them to give back to the broader industry. This can take on many different forms, from speaking at industry events to producing content or mentoring more junior professionals, but this external mentorship is something that I would expect a DR4 (Principal) to be interested in doing as well as capable of executing on.

Note: from a purely opportunistic standpoint, this expectation of a more experienced DevRel Professional giving back to the broader community benefits the company as well. For instance, as a Developer Advocate creates a name for themselves in a relevant adjacent community, they can function as a conduit into that community, creating additional traction or awareness. From a recruiting perspective, it’s common to look for Developer Advocates who already have this reputation for sharing and mentoring others in the broader community, since they already have a strong standing in relevant key communities.

The next question was how this mentorship and external influence differed from that of a thought leader or industry expert. Other than the fact that many DevRel professionals don’t like being called “thought leaders” (that’s a whole other topic for another time!), there’s one main reason why I don’t want to conflate the two. The tech industry as a whole is full of smart people who proclaim their ideas, which are often, without a doubt, brilliant. These people are often seen as industry thought leaders and experts. 

However, there are many of these “industry leaders” who don’t have the desire or drive to actively help others, which is a core tenant of Developer Relations. For this Principal/DR4 role, it’s not enough for someone to be a thought leader. They must also be empathetic and willing to mentor and help those around them.

Looking at it from another perspective, I’m not as concerned about whether someone is viewed as an “influencer” or thought leader by the broader industry, but if they qualify to be a DR4 based on their other qualities, I’d expect them to be willing to share their knowledge and experience with others in the industry.

Camunda’s Developer Relations Career Path

Thanks for sticking with me through all of the background information and important definitions! Now that we’ve covered all of the necessary bases… it’s time to dig into the actual career path. 

Here’s what an Associate DevRel Professional (DR1) looks like at Camunda:

After a few years in the tech industry, most folks will transition into a DR2 role. Many DevRel professionals will transition directly into DR2 from another position outside of Developer Relations based on their prior (relatable) job experience.

A Senior DevRel Professional (DR3) begins to set themselves apart as they are the go-to person for one or more products, projects, or programs, depending on their role. For instance, our DevRel Program Manager is known internally as the go-to person for our participation in Hacktoberfest as well as the DevRel CRM.

The other piece that distinguishes a DR3 is that they have moved beyond doing tasks only when asked and are now proactively engaging. This means they’re taking ownership of their projects, often defining their own quarterly goals, actively looking for opportunities to help teammates as well as other departments, and bringing new ideas to the table to further company goals.

Many Developer Relations professionals will remain at the Senior (DR3) role for the remainder of their career. There is no expectation or requirement that they advance to a Principal (DR4) role, and some individuals may not have a desire to contribute back to the broader technical and DevRel community, as I referenced earlier is required of a DR4.

Others may choose to transition from Developer Relations into another role or into management at this point in their career. To this point, Principal DevRel professionals at Camunda are rare. Here is what’s expected of those who choose to become a Principal Developer Relations professional.

As I mentioned earlier, there is room for growth, both in salary as well as responsibilities, within each of these stages. The growth potential within these stages is an individualized journey and offers a perfect opportunity for mentorship and concrete guidance from management.

I’d love to hear what you think! Do you have any questions? Are there characteristics that you disagree with? What would you do differently? 

If it resonates with you, keep an eye out for Developer Relations jobs at Camunda -- I have a few openings coming soon!

Special thanks to Bear Douglas, Greg Wilson, Felix Kreger, Nathen Harvey, Jeremy Meiss, Ash Ryan Arnwine, Peter Van de Voorde, and Daniel Meyer for their advice, mentorship, and comments on this post.