I’ve had dozens of conversations over the last year alone with people who are wondering how to split up the work within a Developer Relations team. Whether you’re trying to figure out what type of Developer Relations professional to hire (someone with a developer background? someone who has experience running a community forum? someone who thrives when faced with the creative challenge of how to make people aware of your new product?) or trying to decide which of your team members is responsible for which tasks (as I’m doing at Camunda right now!), having a clear framework with which to divide the responsibilities and focus our work is important.

In a previous blogpost, I mentioned that supporting your company's empowerment of the technical community is the cornerstone of what we do as Developer Relations professionals. This foundational understanding can then be divided into a few categories: awareness, enablement, and engagement.

Let’s start with definitions. What do I mean by “empowerment”?

To give someone confidence or strength to do something.

The Path to Empowerment

In order for a technical individual to succeed with your product, they need to be confident that they have the ability to use your product, or at least the confidence that they can find the resources which will make them successful.

In order for them to have this confidence, they first need to be aware that your product exists and is capable of meeting their needs.

Next, the resources that exist need to be capable of enabling them to use your product. This could be your documentation, best practices guides, tutorials, client libraries… the list goes on. But this experience of onboarding with your product, and understanding that they’re capable of easily using your product to solve their problems, is a huge step toward adoption.

Lastly, once a community member has adopted your product, it’s time for them to engage with your community.

At Camunda, the DevRel team’s mission is to “provide opportunities for developers to be more successful by making them aware of our solutions, enabling them through great experiences, and fostering a culture of collaboration.”

We empower developers and other technical professionals to be successful by making them aware of our products and projects, enabling them through the content and excellent experiences we produce, and inviting them to engage and collaborate with us as well as other Camunda community members.

3 Functions of Developer Relations

Our team has three distinct functions: Developer Advocacy, Developer Experience, and Community Management. These three segments loosely map to the path to success that we set up for our community members: Awareness, Enablement, and Engagement.

Broadly speaking, our Developer Advocates are responsible for making sure our community is aware of the solutions we provide. They do this through producing content (blogposts, speaking engagements, livestreams, etc.), building sample applications and integrations, and building relationships in the broader tech industry. They also make our Product Managers, Engineering Leads, and other stakeholders throughout the company aware of relevant, actionable feedback from our community of users as well as the broader technical community. This product feedback coupled with information about the broader tech industry (what are the trends that they’re noticing? how are other open source communities handling certain issues? what’s the latest framework or extension that we should look into?) is incredibly valuable information and plays an important role in the enablement of our community members.

Our Developer Experience team is the team primarily responsible for this developer enablement. From the standardization, accessibility, and readability of our documentation to the initial experience a developer has when they first encounter our product to the contributor experience, this function is what puts the finishing touches on a fantastic talk from a Developer Advocate at a technical conference. The Developer Advocate makes people aware of the fact that our products exist. The Developer Experience team gives people the confidence to know that they can easily solve their problems by using our fantastic guides and resources. It also reassures them that if they do happen to find an area that they’d like to contribute to, we’re not only prepared for them but are willing and able to support and engage with them. This is where the bridge to engagement starts. As we focus on the experience of an engaged community member, we start asking questions about how we can engage with them further, keep them engaged, and move them further down the path to becoming a Camunda Champion.

Community Management is where the engagement function really starts to take shape. Our Community team works with our most engaged community members - those who run meetups, speak at events on our behalf, and continually give back to the broader community of potential Camunda users. From our Camunda Champions to our conference attendees and forum contributors, our goal is to build a strong community of people as well as connections -- connecting members of the community with different functions at Camunda, as well as feeding useful tools and information back into the community.

Don’t Forget About Your Internal Community

As you can see, Developer Relations isn’t only externally-facing. There are places where the concepts of awareness, enablement, and engagement apply internally as well. How much time should you spend focused on internal engagement versus external? That’s a topic for another blogpost, but in the meantime, I’ll leave you with a list of ways my team fulfills this “Awareness, Enablement, Engagement” trio, both internally at Camunda and externally with our communities.

Internally to our coworkers: 

• Awareness of our team’s existence

• Awareness of the feedback that the community is willing to provide

• Awareness of the processes we can facilitate (feedback loops, documentation standards, etc.)

• Awareness of the way that the community members can serve the company (DevRel Qualified Leads)

• Enabling our coworkers to better serve the community (Enterprise customers as well as Open Source contributors)

• Enabling our coworkers to better communicate with our customers as we provide additional data about who those people are (e.g. patterns, general demographics, etc.)

• Enabling our coworkers to write, speak, and code in a public fashion in front of our audience.

• Engaging our coworkers with the community through DQLs, conferences, forums, social media, and more.

Externally to our community:

• Awareness of the existence of our various products and projects

• Awareness of our team & our mission

• Awareness of the resources we provide

• Awareness of our willingness to hear and transmit feedback internally

• Awareness of the solutions we offer (open source as well as enterprise)

• Enabling them to get up and running quickly and easily

• Enabling them to be successful in their company / role

• Enabling them to progress in their career through training opportunities, resume building skills, and more

• Enabling them to try new things (guest blogposts, guests on the podcast, etc.) as well as for them to experience a larger reach due to our amplification of their work

• Engaging them with each other as well as with our employees (cruise director analogy)

  • Forum/Slack

  • Social Media

  • Conferences

  • Meetups

• Engaging them in small, specific groups for knowledge sharing & community building (e.g. meetup organizers)

• Engaging folks to not only use our software, but contribute, collaborate, and give back (moving them up the pyramid of engagement)

A note for those of you who find yourselves pursuing all of these functions as a one- or two-person team, I recognize that we’re in an incredibly lucky position at Camunda to have a relatively large team and an executive team that understands the value we bring. If you’re responsible for awareness, enablement, and engagement and struggling to find the balance between them, I can empathize! I’d encourage you to read First, Understand the Company Goals to help you prioritize your goals and find a way to make the value of your work clear to your stakeholders. 

Secondly, find allies throughout your company. You’ll likely find others interested in Awareness in the marketing department. Look for your Enablement friends in the product and engineering divisions. Lastly, make friends with the support and customer success teams to help out with engagement gaps. By being smart about how you prioritize your tasks and working across teams to accomplish goals, you’ll find yourself making progress in all three areas.

Interested in more information about how to reach across all three of these functions as a small team? Let me know in the comments below and I’ll work toward a blogpost about the topic in the future.