What is DevRel?

This is a topic I’ve written about before and is one I feel needs further discussion: what exactly is DevRel? I’ve spent the last decade of my career sporting this title in some way or another and per many conversations with customers, developers and colleagues I don’t think anyone actually can definitively define it.

Recursive non-definition

With a few notable exceptions, companies think of DevRel as a catch-all title for “people who talk to/work with outside developers” or something along those lines; most very vague and without much attention to nuance. This lack of clarity about the role is rooted on the lack of clarity on what DevRel means. So companies create roles based on their needs but instead of fleshing them out in detail to find the right person, they bunch it all up with other vague and generic requirements and bundle them up in a DevRel job req. Then, in turn applicants with all sorts of “developer-facing” skills and different professional backgrounds apply. Then, in my experience as both as the new hire and mentor of new hires, there’s a bit of a jarring experience getting acquainted with what the role actually entails. Further, this non-definition loop percolates downstream, to the developers/consumers. If you ask 10 developers what they think DevRel does, you will get 15 different opinions. Some of these opinions are rather unflattering ranging from ‘disguised marketing’ to ‘shill’. And frankly, I don’t think these opinions are wrong or misplaced because many companies do indeed use the ‘DevRel’ title for technical marketing and sales-sy roles. Every step of the chain the role not only continues to be undefined, but also a lot of unspoken characteristics are attributed to it which only makes matters worse.

Org Chart Limbo

Another fundamental and important issue that is both a cause and effect of the non-definition issue above, is the fact that, with a few notable exceptions, most companies do not know where to place the “DevRel” business function. Sometimes it’s entirely under engineering, sometimes under marketing, sometimes under Product and more often than not DevRel ends up in an awkward limbo where it reports to one department but works at the direction of another and working together with yet a different org. And to be clear, this is a problem in companies of any size be it 25 employees or 230,000, so we can’t really attribute this cause and effect on corporate bureaucracy. And the ramifications where DevRel is within the org chart cannot be understated. For example, if you hire highly-technical folks and they are put under marketing with its laser focus on metrics, ROI, etc, you will end up with a lot of friction and pushback. The opposite is also true: hire folks who are marketing/public speaking-forward under engineering and you’ll find a lot of discontent and friction. When placed under product but your talent is outbound content and community growth and again a mismatch will have to be overcome.

So what exactly DevRel does?

So far we have discussed the problem, potential causes and its manifestations and effects. In order to better understand what DevRel is, below is a non-exhaustive list of what is generally believed DevRel encompasses:

• Technical content authoring and review
• Technical documentation
• White papers
• Reference architectures
• Proof-of-Concepts
• Conference talks
• Booth duty at conferences
• Light-weight technical support
• Collaborate with marketing
• Provide user feedback to Product
• Light-weight engineering
• Light-weight Quality Assurance
• On-site customer enablement
• Community building and growth
• Hackathon organizing
• Social media influence/thought leadership
• Local user group meetups
• Developer incentive programs
• Development of SDKs
• Development Public APIs
• Friction logging
• etc.

And to be sure, most companies seem to believe all of those responsibilities are “fair game” for a DevRel hire, but they aren’t. Believing someone who is a social media influencer also has skills in writing white papers or organizing hackathons; someone who is apt at SDK development and light-weight engineering has community growth and management skills; someone who’s apt at marketing is also apt at technical documentation and so on and so forth, will lead to bad outcomes for everyone, the company, the employee and the end users.

Proposed solution

For companies:

1. Make a deliberate decision as where in the org chart will DevRel lives in your company. Place it where it aligns the most and affects directly. If you want this role to serve as the public-speaking, booth rep for the company it makes little sense to have them under engineering or Product, for example. If you want the role to serve as light-weight dev technical support and light-weight engineering, makes little sense for them to be under marketing. In short, DevRel needs to be in full alignment up and down the value chain within the org, otherwise, the mismatch in expectations and duties and the value DevRel brings will result is friction and discontent.
2. Use role titles that match the need and expected work. Instead of plain ‘developer relations’, make it meaningful ‘developer relations: community’, ‘developer advocate: SDKs and APIs’, etc. And then take the time to flesh out the details and duties of that role. Some of the skills that are believed to be of a DevRel candidate are not fungible or easily learned. Public speaking vs. documentation writing. SDK development vs. white paper authoring, etc.
3. Don’t create a DevRel function because of cargo cult. Just because other PLG startups do it, or Google does it, doesn’t mean that you should, too. Maybe what you need is technical marketing wizards or a light-weight support function or tech writing staff or a seasoned community manager. Maybe what you really need is an extroverted QA engineer.

For DevRel job candidates:

1. Details, details, details. Demand details about the job, even if they are expressed in the job posting. Reporting chain, cost center vs. revenue. If it’s a small company or a startup, try to gauge how likely is the company to let DevRel loose if the economics aren’t favorable.
2. Do not assume what your responsibilities will be based on your past experience. Your past experience will be key in getting you the job, but does not mean that’s what the new job will be like.
3. Ask same questions a 1) above to the different people you meet in an interview loop. See how their answers align or diverge. You would be surprised how helpful this is in determining whether the job and the company will be a good fit for you.

Conclusion

DevRel, much to its own detriment, has become an umbrella term for a large number of needs and duties that do not fit neatly any of the ‘standard’ business functions of a company. Because of the large scope of duties, there is a lot of vagueness involved from top to bottom — including end users. For DevRel to be successful, as a discipline, there needs to be clarity. From the very first decision as to whether a company needs DevRel or not, to the specific duties it will need to perform. With more alignment of company needs with employee skills, the higher the chances the investment will be worthwhile and the more benefit attained by all involved.