What do you wish you knew about Developer Relations?

No worries at all! Being blunt or straightforward is rarely a bad thing in my book :)

• When did Developer Relations (aka DevRel) appear as a role? This is a highly contested question ;) The first time someone called themselves a Software Evangelist was Mike Murray at Apple. Alain Rossmann, Mike Boich, and Guy Kawasaki were all Evangelists in the *Macintosh (edited) division. However, the term "Developer Relations" is a little harder to pin down. People were doing searches on LinkedIn for the term as early as 2012. Brandon West (@bwest on Twitter) has actually been doing a fair amount of research into the history if you want more information specifically on that!

However... Community Management and specifically Open Source or Technical Community Management has been around for decades, basically since Open Source became a "thing" in the 1950s and 60s. I tend to believe that Developer Relations is, at its core, community management for a technical audience, which of course has some nuance to it and a few more technical roles, but at the end of the day, we're not reinventing the wheel... we're at best trying to improve it. There's a great article about that here: together.is/community-building-is-...

• Is developer relations just trying to sell/promote a 'product'?
  DevRel is not about selling or promoting a product. In fact, while DevRel can fall under Engineering, Marketing, Product, or even Customer Success at many companies, I have no problem drawing a line in the sand and saying it should never fall under Sales. DevRel at its core is about empowering developers and ops folks to do their best work. Sometimes that means using the product that the DevRel professional works for; sometimes it means recommending a different alternative! It always means advocating for the technical audience internally at the company, creating resources (such as written as well as video content, documentation, sample applications, tutorials), and being the hub of the wheel -- connecting people, both community members to each other and community members to your coworkers.

• How did you come to work in developer relations?
  This answer is different for all of us! I explained a bit of my history here: dev.to/mary_grace/comment/9p20 but there are some folks who have theater backgrounds, others who have been developers in the past, still others who have taken coding courses and decided they loved the people aspect of technology more than the actual coding. I strongly believe that these various backgrounds give us a different perspective and the ability to empathize with our technical audience on a unique level.

• What's a typical day/week for you?
  This is different for everyone as well! Developer Advocates tend to focus more on technical content, sample applications, and speaking engagements. Technical Evangelists or Ambassadors focus a lot on in-person engagements as well as helping to frame the product in perspective of the rest of the tech industry. Technical Community Managers are often responsible for community forums as well as connecting community members to each other or to internal people.

• Why is developer relations necessary?
  DevRel actually isn't necessary at every company! It tends to be helpful at places where technical folks are the end users (for example, API companies (specifically PaaS and SaaS companies), gaming platforms, open source companies, etc.). DevRel professionals are the liaisions between the community and the company. They're the ones who have the community's interests in mind constantly, rather than having their interests split between community and company. There's mantra I like to use to describe this dicotomy:
  To the company, I represent the community.
  To the community, I represent the company.
  I must have both of their interests in mind at all times.

This is a difficult balance to keep, but by advocating internally for the technical audience's needs, the Developer Relations team can reduce customer churn, improve the overall customer experience, build lasting relationships with the community, and overall help to empower their technical audience in a way that not only improves the product, but improves the community's job and experience.

Absolutely! Here's the TL;DR:

• Developer Relations (or DevRel) is the umbrella term for all things community building and developer advocacy. Basically, it's like saying "developers" to encompass all front-end and back-end devs as well as ops folks. This is also the typical name for a team that focuses on community building and advocacy at a company.

• Developer Advocacy can be seen 2 different ways: It's another name for "Developer Relations" as a broad term, but when viewed specifically, "Developer Advocate" is a role within the Developer Relations umbrella. This role tends to be someone who's got a developer or coding background but also enjoys writing, speaking, and generally empowering the technical audience to better understand a product. They advocate internally for the technical audience's needs.

• Developer Evangelism typically has a slightly more sales slant to it. I view the Developer Evangelist role as someone who frames the importance of the product within the broader technical landscape. They help you (and your leadership team) understand why this particular product is important at this time.

• Technical Community Managers aren't always developers (I'm not!) but they're tech savvy. They can have technical conversations about the product, but more importantly, they know who the right person is to pass the conversation is once they're out of their element. They're the connectors -- keeping an eye out for the technical community and making connections between community members as well as back into the company (finding beta testers, external ppl who might be willing to write content, etc.).

Does that help?

It really does depend on the role and the company, unfortunately. Most companies these days, for Dev Advocate roles at least, are paying comparable with engineering roles. Community Managers, however, are notoriously underpaid because their technical skills are underestimated, as is their value. I believe Technical Writers are in the same boat as community managers, but Developer Experience professionals tend to be more inline with Engineers.

I do know of some folks who have had their salary doubled or tripled when they talked about leaving a company, simply because their skills were that valued and the company was desperate to not lose them, but those are fairly few and far between.

In general, I’d say if you have an engineering background and are interested in DevRel, you can ask for anywhere between $130-170k and most companies won’t blink an eye. More experienced roles are more likely to make $150-180k and the higher you go up the ladder in either IC or management experience, the more you can ask for.

That being said, I always try to find out how much the company is willing to pay before I name my price. It allows me to get a better gauge of where the industry is at these days and also how much this particular company values Developer Relations.

Sorry to hear that you were made to feel like an idiot for asking that question :( It's a totally valid one, considering it's still a relatively new industry that isn't well understood!

At its core, the purpose of Developer Relations is to empower a technical audience to do their jobs to the best of their ability. Just like a camera manufacturer usually employs photographers to help make their product the best that it can be for the photography community, Developer Relations professionals (primarily Developer Advocates and Technical Community Managers) are the liaisons between the product and engineering teams and the technical community who uses the product. They pass along feedback, create resources, and generally try to make the user's experience as painless as possible.

Their other main task is to make connections. The team makes connections within the community, introducing community members who share common interests or are trying to solve similar problems. They also introduce community members back to the company, whether as beta testers, guest bloggers, potential employees, or potential customers.

I hope that's helpful! Feel free to reply with any other questions you might have.

Andy has very solid advice! There are definitely many different paths that can lead to DevRel. I, for instance, have a journalism background and have never been a developer professionally. Other folks have theater backgrounds, or customer support, marketing, product, or completely unrelated-to-tech backgrounds.

Besides what Andy mentioned, the other thing I encourage folks to do is take DevRel for a "test drive" before they fully commit. In other words... ask your marketing team if they need any technical content for the blog, or if they could use some help staffing the booth at an upcoming conference. Look into upcoming CFPs (conference call for proprosals) to see if there are any conferences that sound interesting, and then brainstorm topics with your team to see if you have a talk that might be interesting to give. Attend local meetups and engage with the organizers -- perhaps they need extra speakers there!

I go a little more indepth on this topic in a recent blogpost for OpenSource.com: opensource.com/article/19/3/develo...

Disclaimer: there’s no “single way” to do that. Here’s my experience.

In my case, after ~15 years as a coder and as a consultant, I was already very active in online communities, in Open Source (pre-GitHub, I should add!), and had been developing as a public speaker. Probably the most valuable attribute for me was being active on social media - I often comment that being on Twitter led to my jobs at both VMware/Pivotal, and at Twitter itself. Both Pat Chanezon (VMware as was), and Jeff Sandquist (Twitter as was) recognised what I was doing through my Twitter presence and reputation, backed up by my blog and YouTube videos of my public speaking gigs. Hiring managers could see what i was writing about, talking about, making videos about, and how I engaged with developer communities.

There really are many ways to move into the space, though! As a hiring manager myself, I’m looking for: passion; communication skills; a level of technical knowledge in one or more coding languages. I want to know that you care, and that you can communicate your love of and interest in a topic (any topic; not necessarily my company or product or platform) in an engaging manner. So, that opens paths in and out from roles such as software engineeering, product management, consulting, marketing, community management, or support.

That's a great question! When I was working as a Community Manager, there was often an assumption that I was "just" a social media marketer (emphasis mine... not to diminish the job, which is actually not easy to do well, but to point out the implication from others that I wasn't qualified to answer technical questions). While I did indeed help with the social media platforms, my main focus was to create a healthy, encouraging, and informative space for our community to gather, both on- and offline.

Some Developer Relations teams run developer-facing social media accounts, but in many cases, they simply work closely with the social media marketer or team to make sure that the content is relevant to developers. In my book I advise larger teams & companies to include a tech-savvy social media marketer on their team who is responsible not only for the social media accounts but also for syndication of content and communication with the community.

TL;DR: Social media is an important way that we connect with our community members, both from personal accounts as well as corporate accounts. If there is a dev-facing social media account, it should be used to promote and amplify the work that the community is doing as well as engage with the community around relevant content. The emphasis should always be on having a conversation with people rather than talking at them.

hey Vincent! Max asked this same question above and both Andy Piper and I answered it there. Let m know if you have other questions after taking a look at those answers!