5 Biggest DevRel Challenges—and How to Mitigate Them
If you’re involved in community building, it’s no surprise to you that while it’s rewarding, it’s also incredibly difficult. As CodeNewbie Founder and CEO, Saron Yitbarek said in an interview,
Community building is hard. It can look warm & fuzzy from outside, but you’re taking on a lot of emotional labor & there’s invisible work that no one will ever see. It’s ok to be frustrated, fed up, & lonely sometimes. Find those who understand.
In addition to the emotional labor and invisible work she refers to, there are other challenges that community builders face, particularly those who fall into the realm of Developer Relations, or DevRel. But what’s the difference between DevRel and Community Management? Honestly, it’s not all that different. It’s basically community management for a technical audience, which has existed for decades through Open Source Community Management.
These days, Developer Relations is the umbrella term for the team whose primary responsibility is building a technical community both online and offline. At its foundation, the purpose of DevRel is to build relationships with the developer community. DevRel professionals act as a liaison between their company and the developer audience who are typically the end users of the product.
I like this little mantra to explain this complex relationship:
To the community, I represent the company.
To the company, I represent the community.
I must have both of their interests in mind at all times.
But as this idea has spread throughout the tech industry, its run into resistance along the way. It’s not a traditional practice and it’s still finding its way when it comes to defining roles, metrics, and goals within companies. As a result, many DevRel professionals struggle to grow in their career and feel like they’re making an impact in their company as well as the community. In this blogpost, I’ll cover 5 of the most common challenges in DevRel and how to mitigate them.
Challenge 1: “What is DevRel?”
If you’re still asking this question, rest assured, you’re not the only one! As any DevRel Professional will tell you, this is a question that we get from our parents and friends, as well as our coworkers and even the developers we’re attempting to empower.
But even with this simplified explanation, there’s still confusion, even within the DevRel industry. What does each of these titles mean? What does the division of responsibilities look like and where do we overlap with each of the other departments, including Marketing, Product, Engineering, Support, and even Sales?
As we continue to mature as an industry, it’s important to have common definitions to help us differentiate these roles, both for those in the community as well as those who are pursuing a DevRel career. Here are my working definitions:
A Developer Advocate is someone who likely has some sort of coding experience, whether that’s an official CS degree, code school experience, or a full-time developer. They’re often building sample apps, live coding, or giving demos, engaging with the community on a technical level.
A Technical Community Manager, on the other hand, may not have this coding background — thought they could! — but they will absolutely be tech-savvy. They need to be able to carry on conversations that take a fairly deep dive into where your product fits within the broader technology market as well as answer questions about the technical aspects of your product.
Lastly, Technical Ambassadors, aka Developer Evangelists. These are the folks who excel at selling the importance of this particular product within the larger technology industry.
The person leading this team is ideally a director level or above, capable of engaging with stakeholders so that the community can be represented at the decision process. They’re usually able to have technical conversations but also able to see the bigger picture, and are responsible to build out an overarching community strategy that relates back to the company goals.
Challenge 2: Learning to Say “No” to Projects, People, and Plans
Jennifer Riggins opened a blogpost with this line:
A developer, a marketer, a branding manager, an integrations manager, a business development partner, a domain expert, an event manager, and a technical writer walk into a bar. She orders a glass of wine. After all, it’s been a long day of jet-setting and hand-holding as a developer advocate.
A Developer Relations professional can hit all of these buckets and more, which is one of the reasons why companies have such a hard time deciding where a Developer Relations team fits within the org chart. After all, many DevRel professionals are capable of writing technical content, speaking at conferences, connecting community members, collecting feedback for the product team, putting together sample applications, and more.
But this list of things that we’re capable of can lead to never-ending requests from colleagues who are working on projects that are outside of our purview. Learning to say “no” to these projects can be difficult.
Having a clearly defined team mission can be beneficial here, as each request can be evaluated against the mission and goals. When there are questions of prioritization or whether a particular goal is a good fit, it provides a “North Star” for you to refer back to. It’s also useful for your colleagues, as it helps delineate what is (and isn’t!) your responsibility.
Challenge 3: Traditional Metrics for a Non-Traditional Team
As I mentioned above, many companies have difficulty defining where the best place is for a DevRel team within the organization. Part of this struggle comes from the fact that DevRel is a non-traditional team made up of developers, marketers, and product folks, many of whom have non-traditional backgrounds (I have a background in journalism, for instance).
Given the various backgrounds and unique tasks that DevRel is given, it can be difficult to fit these square pegs into round holes. As SparkPost Technical Product Manager Avi Goldman says,
Developer relations is like product, marketing, and engineering, but they have less control, similar responsibilities, and more empathy.
So how do you find the right metrics for this non-traditional team? And more importantly, how do you convince business stakeholders to let go of traditional metrics that don’t fit a team who takes risks, builds relationships, and is a liaison between the business and the community?
You find the commonalities. What are the traditional metrics that you can use to illustrate your value? What are similar concepts that you can spin in order to help others understand your viewpoint?
DevRel Qualified Leads is one such example — a spin-off of Marketing Qualified Leads, or MQLs, which are the leads that Marketing passes along to Sales. Here’s the key: once they’re handed off to Sales, it’s no longer Marketing’s responsibility whether or not those leads become customers.
Similarly, DevRel Qualified Leads are the connections that the DevRel team makes between community members and the company. This can be a potential hire that they passed off to recruiting, a beta tester who can give product feedback, or a Developer Advocate at another company who’s willing to help build out an integration that will help customers use your products in tandem.
These connections are incredibly valuable and might not have ever happened were it not for the Developer Relations team’s direct involvement in the community who now knows and trusts them.
Challenge 4: We’re Extroverted Introverts
If you talk to most DevRel professionals, you’ll find that building relationships and making connections within communities isn’t just something that they do to pay the bills. It’s their passion.
But there are downsides to being involved in building communities as a full-time job. Being “on” all the time, between conferences, speaking engagements, delivering reports back to our colleagues, and hosting special events, can be draining. Building personal relationships in our own home cities can become difficult as well, given how often we’re on the road and how tired we are when we get home.
The drastic difference between being surrounded by hundreds of acquaintances at a conference and then going “home” to a silent hotel room can be difficult as well, as Samsung Developer Advocate Amy Dickens says:
There’s a difficult introvert/extrovert balance of traveling solo. I’m currently at a conf on my own and whilst the last thing I want is more people around me after a long conference day, I also don’t want to eat alone – it can be such extremes of all day around hundreds to all night with just yourself.
Finding people you know and trust while on the road is key. Whether this means building friendships with the DevRel professionals who tend to travel to the same conferences or reaching out to far-flung friends who happen to live nearby, having a handful of folks who you can call for a quiet night in can make for a nice balance.
Challenge 5: Balancing the Interests of the Company and the Community
At the end of the day, the role of DevRel is to empower developers to be the best that they can be. This empowerment comes through communicating feedback, developing tooling, making connections, and in general building relationships so that we better understand the needs of the technical audience.
While most professionals have the best interests of the business at the front of their minds, driving their day-to-day decisions, DevRel professionals have the best interests of the community as their driving factor. They, of course, care about the success of the business as well—it is, after all, what pays their bills—but they understand that if the community is happy and successful as a result of using the product, the business is far more likely to succeed as well.
Maintaining this balance can be difficult. As the face of the company, we may be asked about company decisions that we may not agree with. We’re often the sounding board for difficult feedback because the community knows and trusts us.
There isn’t a straightforward solution to this challenge. The best scenario is that the team is supported internally, able to communicate clear feedback to the stakeholders and have an impact on upcoming product releases. But if that support doesn’t exist to the fullest extent, it’s up to the DevRel professionals to maintain a balance of professional responses when things with the company aren’t handled as well as they’d hoped, and continue to communicate the valuable feedback they’re receiving from the community.
This is a guest blog by Mary Thengvall.
Curious about a career in Developer Relations? Mary breaks it down in this article for OpenSource.com. From what DevRel is all about to tips for giving it a test-drive, Mary’s insights are a must-read for anyone exploring the field.