Developer Relations (DevRel) is an interdisciplinary role that sits in a border space between product, engineering, and marketing. The daily work looks very different from company to company, and because DevRel is often rolled into other organizations like product or marketing, it may not have its own separate career path – a document that describes expectations for your work at varying levels of seniority.
In recent months, more and more DevRel managers and ICs (individual contributors, meaning you don’t manage people) have been talking about how to write job descriptions and define career paths for Developer Relations. Today I want to help move the conversation forward in a more transparent way by sharing the career path I use for Developer Relations at Slack.
Writing the path for Slack
Developer Relations at Slack is currently a 12-person-strong team, and at this size, we’re generalists by preference and by necessity. Everyone writes docs, everyone builds tools and sample code, everyone gathers and shares developer feedback, and everyone works on events. We also come from different backgrounds: people on our team have joined us from core engineering, from developer support, from non-engineering operations roles, and some have been doing DevRel their entire careers. For our whole team, we have a single path.
Even for us, this path is imprecise, designed to be a set of guidelines rather than a series of job descriptions. Not everyone’s role will be neatly outlined by the content of the path, and, in my opinion, that’s not the point.
A good career path is general enough that it doesn’t box you in to a set of predefined activities. It’s also specific enough that you’re being held to a fair and clear standard of performance, while being shown a way forward to growth.
In the past, I’ve found paths that described day-to-day work gave people an overly-prescriptive map of what to do to get promoted rather than a holistic understanding of how the organization defines seniority. It’s the latter that helps people create their own route to growth and promotion, which ultimately serves them and the company better.
In one of the first career paths I wrote, I described activities for a mid-level DevRel that included “running community events, like meetups.” As the team grew, the person who had been running our meetups asked me whether they would “lose the checkbox” toward promotion if they handed that responsibility over to someone else. To me, it was obvious that I wouldn’t care if this person gave away their Legos– that was the healthy and correct thing to do in a growing team. To them, it was not so clear, because I had wrongly framed the conversation around activities rather than behaviors.
By contrast, I discussed Slack’s current DevRel path with one of our summer interns who wanted to understand what a full-time role and long-term career on our team might look like. After reading our path, our intern was able to accurately infer the levels of the people on our team he worked with most closely.
I realize that might make some people uncomfortable– shouldn’t that be private information, or something only discussed between you and your manager? But this information isn’t exactly private. Levels are encoded in job titles, and expressed in daily behaviors. If someone you work with casually can figure out what level you’re at, it shouldn’t feel risky, like you’ve been exposed– it’s a sign that your team is on the same page about what levels are.
Enough philosophy, show us the levels
OK, OK. You can jump to reading the full path here, or I’ve excerpted it below for ease of reading.
Here’s what our level description looks like for a new grad:
And here’s what it looks like for someone with a few years’ experience:
We define senior like this:
And staff like this:
You’ll notice that the levels have three components: technical quality, collaboration, and execution (h/t to Ross Harmes, Matt Schweitz, and Lauren Ficklin, who wrote the Slack Engineering path that I adapted the DevRel path from). It’s meant to encompass growth in skills, in scope of work, and systems thinking– contextualizing our daily work in the broader landscape of businesses and technology.
Growing in your DevRel career means honing technical skill; it means being a better internal advocate for your developer customers; it means working to level your team up with you; and it means that you are a trusted communicator on behalf of the company. If you’re a great external communicator but you can’t get anything shipped for developers because you have no credibility with the product team, you aren’t becoming more senior in the organization. The same is true if you’re technically brilliant, but you never mentor anyone around you.
The document describes a path that starts and grows purely in DevRel. But the path in (and out) of DevRel is highly individual, because the role is so interdisciplinary in nature.
You may stay in DevRel for years, or spend some time here as a transition between engineering, marketing, product, sales engineering, business operations, user research, or data science (that’s a run-on on purpose– great DevRellians can come from anywhere).
Perhaps more than in other disciplines with traditional, linear career progressions, it’s important to distinguish between growth within the role and the organization, and growth in the broader context of a person’s career. Many people come to DevRel because they want to hone their technical presentation skills, or they want more exposure to customer developers. People who spend time in DevRel to better understand developer customers as part of a path to product or developer product marketing may care less about growing technically. For others, a role in DevRel may be the first time they’re responsible for production code.
Because people may come in with skill sets at different levels, and because it’s relatively rarer to spend your entire career in DevRel, it’s even more important to treat career paths as the jumping off point for conversations with your manager. Expectations for the role and a plan for growth should be individualized and made concrete in 1:1s.
Ultimately, the point of a career path is to help make sure that both you and your management chain see a path forward for you, as an individual contributor or a manager. It’s a level set, not a checklist, and with any luck, us sharing this detail can help you kick off that transparent conversation.
Does this sound like how you’re interested in growing your career? We’re hiring. Watch this space, and in the meantime, you can find me on Twitter at @beardigsit.
