I am a connector of people at heart, personally and professionally. I love digging into the strategy of how to build and foster developer communities and have been doing so for 10+ years.
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.
I am a connector of people at heart, personally and professionally. I love digging into the strategy of how to build and foster developer communities and have been doing so for 10+ years.
No worries at all! Being blunt or straightforward is rarely a bad thing in my book :)
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.
Small correction on this :-) Guy was at Apple!
ahhh YES! All 3 of them were. I meant to type Macintosh, but got distracted and my brain took over halfway through. I'll change it now :)
😂
I LOVE that mantra!! I've now quoted you on my linkedin profile :D