The 3 Cs of Developer Advocacy

Sometimes you put something out into the universe and it finds its way back to you in unexpected ways.

One such thing for me recently has been the concept of the 3 Cs of Developer Advocacy. That the 3 Cs are boomeranging back to me I take to mean that people are finding the concept useful.

But I realize I've never shared the 3 Cs publicly except for when I guested on Stoplight's API Intersection podcast last year (link below). Given that Stoplight has been acquired recently, who knows what will happen with the episode.

So I'm jotting down some points about the 3 Cs and how they've helped me hire Developer Advocates in the past. In the post, we'll cover:

1. What are the 3 Cs?
2. Why the 3 Cs?

Hope you enjoy and I'd love your feedback.

What are the 3 Cs?

The basic concept is this:

All things being equal, when hiring for Developer Advocates, we must look for 3 competencies:
1. Coding ability
2. Community stewardship
3. Content creation

Or: let developerAdvocate === code && (community || content)

Coding ability is a must-have for all candidates.

On the other hand, community stewardship and content creation might be either-or, depending on the role's scope and seniority. Of course, a candidate with a track record in both is a very strong signal.

Let's take a brief look at each.

Coding ability

To restate: Coding ability is a must-have for all candidates. While this can be a controversial topic among Developer Relations practitioners, I've yet to find a situation where I was hiring for a Developer Advocate and coding wasn't essential to the role.

Most Developer Advocate roles I hire for require a live coding assessment. Live coding is, in my view, an extremely realistic aspect of Developer Advocacy work given that they will find themselves in this situation once on the job.

That said, I don't believe that taking your standard Engineering team algorithms-and-data-structures code assessments and applying them here will work. Instead, I like to look for the following:

1. Baseline coding ability in a relevant language
2. An understanding of the relevant language's ecosystem
3. Ability to come up with multiple solutions to a single problem
4. Ability to communicate and keep things light while in the hot seat
5. A light dusting of system design for full stack apps or for the relevant area of the tech stack

Of course, the specifics here are highly variable depending on what your company does.

Community stewardship

Developer Advocates frequently find themselves stewarding (leading, serving, influencing, building, etc) communities.

While the community stewardship aspect of the job is often what draws people towards the role, it can also catch new Developer Advocates off guard. "Community" can sound like fun and games until you've done it for work where you are held accountable to metrics, have to guide communities through changes they don't love (and you may not agree with), and need to ensure a safe space for personalities and goals of all sizes.

What I'm typically looking for are people who have had to stick through the more difficult aspects of community stewardship—times when things weren't just a walk in the park.

Content creation

On my current team at Nylas, we define content as "any output that attracts and enables developers". This is an intentionally broad definition that includes obvious things like blog posts and videos, but also documentation and sample repos on GitHub.

What I'm typically looking for here is (in order of maturity):

1. Some level of process and standards for content creation
2. A track record of continued publishing
3. An ability to take content primitives and package them in different ways
4. An understanding of content success indicators and how to interpret them

The medium and the level of maturity we're looking for will be dependent on the role.

All things may not be equal

I draw your attention back to the "All things being equal..." part of the 3 Cs concept. Frequently, all things are not equal. You may be hiring for a specific type of Developer Advocate role or a specific kind of developer product. In such cases, you will need to tailor your approach.

But the 3 Cs can at minimum be a helpful framework for hiring managers to starting drafting role requirements, for recruiters and interviewers trying to understand how to assess candidates, and for candidates who are curious about how to put their best foot forward.

Why the 3 Cs?

If you're a hiring manager, bringing an understandable set of qualifying criteria to the process helps various stakeholders:

1. Your recruiters
2. Your internal stakeholders
3. The candidates themselves

The Developer Advocate role is frequently misunderstood. Assuming you're a DevRel lead who's hiring, demystifying the role requires proactive effort on your part.

Recruiters

Over the years, I've found that rooting your recruiters' understanding in these 3 core competencies for Developer Advocates is massively appreciated. From their perspective, you're hiring for weird role!

Developer Advocacy is such a niche that some excellent candidates may have never heard of it, making both passive and proactive recruitment motions much more difficult than for, say, "Software Engineer II". How do you pitch the role? How do you screen for potential fit?

The 3 Cs have given me tremendous value in terms of calibrating with the recruiters I partner with. I usually try to start any recruiting cycle with one-on-one time where I show the recruiter what I'm looking for, what the role is, and how candidates will be evaluated.

Since, as a DevRel leader, you generally won't be hiring at massive scale the way engineering teams might, chances are high that you are not working with a dedicated recruiter. It helps to consider the recruiter's background when calibrating with them.

If the recruiter is usually attached to Engineering:

• How much development experience is enough? How much coding will Developer Advocates do day-to-day? What are the nice-to-have technical requirements in your job description? Which are must-haves?
• How do Developer Advocate coding screens differ from what Engineering does?
• What is this whole "community and content" thing and how would you identify that on a resume or on LinkedIn?

If the recruiter is usually attached to Marketing:

• How do you conduct coding interviews? What do your technical requirements mean?
• How do you identify whether a candidate meets the technical expectations based on a resume or LinkedIn profile?
• How deep does their knowledge and experience with traditional marketing need to be?

I'm surprised to hear how little time some hiring managers give to their recruiters. In my experience, treating that relationship as a partnership, including helping them understand the role, pays dividends in terms of higher candidate qualification accuracy, faster recruiting cycles, happier candidates, and more time for me to focus on an excellent candidate pipeline.

Internal stakeholders

Similarly, your internal stakeholders—likely your suite of interviewers—may be coming to the process with an incomplete understanding of what Developer Advocates do. Depending on the context I'm hiring in, my interviewer suite may consist of Product Management, Engineering, Marketing, Partnerships, and/or Documentation.

If you're a DevRel leader, you know that your team serves as connective tissue, not just between external and internal stakeholders, but also across the internal organization. No one of your stakeholder teams has the same input/output relationship with Developer Advocates as the other. This naturally skews their understanding of the role.

Offering the 3 Cs as qualifying criteria helps set a baseline understanding with disparate stakeholders. It anchors an interviewer's expectations about the reality of the role before they begin probing into the aspects that they care about the most given their own role.

Candidates

For candidates specifically, my hope is that the 3 Cs help them put their best foot forward.

If someone has already been doing Developer Advocacy, I would expect to be able to observe some of that track record in the open. I love getting lists of links from candidates: GitHub repos, technical writing, videos, forums interactions, LinkedIn profile, presentations, etc etc. I usually try to have a place in the application process that allows for this and I'll take everything you've got.

But, for earlier career candidates or those transitioning from other roles, I want the door to remain open for those with potential for the role. Not everyone has the luxury of doing Developer Advocate work as a hobby outside of their day job, and some companies outright forbid work-adjacent public engagement, even while off the clock.

In this second scenario, having a strong game plan around the code screen is essential. Hopefully you're doing that for all candidates anyway.

It's the community and content pieces that can be tricky to find evidence of for potential newcomers to the role. I suggest getting creative:

• Has the candidate ever led or organized a sports, educational, or hobby club or meetup?
• Could you have candidates describe their understanding of the content creation process? Or maybe critique an existing piece of content?
• How about a live group exercise where the candidate receives a content prompt and uses your interview panel as SMEs to draft a technical tutorial or the like?

There's no bullet-proof answer: no matter where you set the hurdle for an application, you'll get both applicants who aren't qualified (shrug emoji) and people who have potential but self-filter before applying (sad emoji).

Here, it's important to lean into your partnership with your recruiter to calibrate the balance before and during the recruiting process.

The podcast episode

As I mentioned at the outset, I shared the above concepts and more on Stoplight's API Intersection podcast last year. Huge thanks to host Jason Harmon for having me on!

You can have a listen here:

I'll emphasize at the end that what I have shared in this post in no way describes the full scope of what you need to consider when hiring or applying for Developer Advocate roles. It's also clearly not an interview plan.

The 3 Cs are a high-level framing of core competencies most broadly applicable to Developer Advocate roles—your adventure begins here.

Do you find the 3 Cs useful? Not convinced? Wondering whether other competencies like Presentation Skills should have make the list?

I'd love to hear your thoughts whether you're a DevRel lead, DevRel stakeholder, DevRel practitioner, recruiter, or potential Developer Advocate candidate!