Author’s Note: What follows is Part 4 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

Moving Developer Relations Forward (6 Part Series):
  • Moving Developer Relations Forward
  • The foundations of Developer Relations
  • Asking the right questions for DevRel impact
  • Developer Relations and the customer journey (this post)
  • Positioning DevRel as a resource within your company
  • So let's talk about DevRel Metrics

  • As previously mentioned I’ve spent the last 15 years in DevRel and Community, the first few as a volunteer in online communities and the last 12 in a full-time capacity. During that time, the debate often comes up around DevRel not being Sales or Marketing, and then morphs into a debate of what metrics are, or aren’t, important, and usually ends with everyone throwing their hands up in the air and going away frustrated until their Twitter alert goes off the next time someone asks , “What is DevRel?”

    DevRel is not a revenue-generating organization - it’s a cost center. As a result, it is the first area of the company that gets cut when Finance starts looking for areas to save money. But that is all too often a short-sighted move, because DevRel (and Community) teams are the ones closest to the very audience and customer the company is trying to acquire, get feedback from, retain, etc.

    One of the best ways these teams can avoid the value-oriented questions, is by proving their value long before it gets to that point. The value DevRel adds for a company must be aligned with the needs of the business and its bottomline. It MUST, or else it will be gone. DevRel needs to understand what the inputs are the business has/need and then shape its activities accordingly. But how do you do it?

    One of the first things I have done whenever I join a new company, is start asking questions. I won’t bore you with all of the details, as I already wrote about them here . The purpose of these questions is really threefold:

    1. Get myself in front of as many people within the organization and company as possible. It’s a great way to meet new people, and to make connections for what will come later.
    2. Identify all of the wants, needs, and perceptions of DevRel early on instead of finding out months down the road. Sure, that is bound to still happen, but this helps to limit it early on.
    3. Find out all of the existing business challenges, objectives, and KPIs that these different teams are reporting against. This will help in shaping our own and we know what we can, and sometimes can’t, contribute towards.

    DevRel teams, especially their leadership, should be having regular syncs with other Business units to understand their challenges & objectives/KPIs/goals/OKRs/etc. This is how you’ll identify what activities your team can do with/for those other organizations to support them, thus raising the value of DevRel.

    The next part really can take awhile, but it really is oh, so important.

    Positioning DevRel in the Customer journey

    To be able to position your team in the Customer journey, you need to:

    1. Find out what the Customer journey currently looks like,
    2. Identify what activities your team is currently performing,
    3. Match up the activities with their spot in the Customer journey,
    4. Automate wherever possible,
    5. Build your reporting, and
    6. Rinse. Repeat regularly.

    Let’s break these down.

    Find out the Customer journey at your company

    When you’re first joining the company, or when you’re going back to perform the Q&A steps I mention above, making sure to ask the different groups what the Customer journey looks like, and who owns it. It is not uncommon to get different answers from each department, which is its own exercise later in really nailing down ownership for something very crucial like this.

    In different companies at different stages and sizes, and even customer-base, who you end up talking to will be different. Here are a few that I have chatted with in the past who owned, or at least had some input into, the Customer journey:

    • Marketing Operations
    • Demand Generation
    • Product Marketing
    • Product

    What you are looking for in the Customer journey is to capture all of the touch points, which are moments when the customer interacts with your brand, and all of the stages that have been identified, which are goal-driven actions to take. These have all been put together and (should) drive all of the customer-driven activities taking place.

    Ex. customer journey (source)

    Note: this is also a great opportunity to start to identify what the elusive DevRel Qualified Leads (DRQLs) could look like for your team.

    Identify your team’s activities

    Identifying all of the things that your team does can be a bit of a challenge, but it’s an important one. It’s also good to recognize that the list you create will change, either because you remember some you missed, or your team starts doing new things - and that’s ok. Just get started with the list, being as specific as you can. You don’t need to categorize them yet, as you might find it better to group them into the categories that are identified in the Customer journey at a later date. I would instead start by breaking them down into two groups:

    1. Activities community members perform
    2. Activities the team perform

    If you’re finding it difficult to identify them, here are some that my previous team identified:

    Community activitiesTeam activities
  • Attended company meetup
  • Conversation at a conference
  • Entered raffle
  • Visited booth
  • Gave product feedback
  • Conference talk
  • Workshop
  • Blog post written
  • Sample created
  • Demo given at customer
  • As I mentioned, these are all just a few of the many activities that we identified. One thing that also helped us identify, and track, all of the activities being performed in the community and by the team was by using Orbit and the Orbit Love model . You can read about some of the ways I implemented Orbit at CircleCI here . There are other tools like Common Room which help you achieve the same thing, but it’s important that you have a way to capture all of the activities in order to accurately report on them.

    Match up the activities with their spot in the Customer journey

    You will go through multiple iterations of this, and that’s a good thing. It’s important to consistently revisit all of the activities and the customer journey with the other teams who need input into it. This will help to identify areas or activities you potentially missed, and to even look for ways that you can connect other systems, like HubSpot and Salesforce, into the system(s) you use for tracking your activities to make it even easier to report on what your team is doing and how it all fits together.

    Automate wherever possible

    This will follow very closely with the previous step. With systems like Orbit and Common Room, you can integrate external systems into the platform to make capturing activities much easier. Here are a few examples of what that might look like:

    Inputs into your community platform

    • Integrate your GitHub organization (or specific repos) for capturing those community activities
    • Integrate forums and communities like Discourse, Reddit, and StackOverflow
    • Integrate customer feedback and product ideas
    • Import raffle entries or booth visits

    Outputs from your community platform

    • Daily export into company data warehouse for inclusion in other reporting data
    • Import into Salesforce to show if someone is part of the community, or if they’re a Champion, etc.
    • The ideas are limitless

    All of this should be automated as much as possible, and in the instances where it needs to be manual, make sure you set aside the time to do so. It is important to make sure you capture as many activities that you perform which can be tracked back to making an impact on the Customer journey.


    This step is one that is difficult, but extremely necessary. You can’t prove the value of what you’re doing as a team or organization unless you provide the reports for other departments and the rest of the company to disseminate. To be able to report though, you need to make sure the previous steps are in progress - they don’t need to be done though, because they’re never done. Here are a few thoughts to get you down the road though.

    1. Use the information gathered when you go on [your info-gathering spree] to understand what is important to different business units to identify which areas your team could be contributing towards. Prioritize those within your department first, and use the others as ones you can start to show over time. It is important though to make sure that you align your activities to the overall objectives, KPIs, etc. that YOUR department has first, and then make sure that you track them back also to the overall company OKRs.
    2. If possible, make sure these reports can be accessed at any time, by anyone within the company. I’ve done this with integrations to Confluence, charts and tables housed in Excel or Google Sheets linked to Powerpoint or Google Slides, reports in Looker, etc. It’s also good to regularly post inside your company comms tool, like Slack, general information about some highlight and then link to the report(s). This helps keep your team and what you’re doing top of mind.
    3. Make sure you report on any cross-team / interdepartmental collaboration that you and your team do as well. You should be actively looking for these anyways, and reporting on them will raise the value-prop that DevRel has.
    A quick note on DevRel Qualified Leads

    As I mentioned above, this whole activity can help to unlock DRQLs for your team. These are not “leads” in the traditional sales or marketing sense, but instead are specific developers, or companies even, that your team is able to connect with internal teams to satisfy some need or business requirement. For instance, here’s a quick breakdown of what could be included in these:

    • Marketing: Case studies, guest writers, co-marketing opportunities
    • Product & Engineering: Alpha/Beta testers, product feedback, new feature requests
    • Sales: Direct asks for demos, proof of concepts, etc.
    • Business Development: New partners, collaboration opportunities
    • Recruiting: Diverse candidates, collaboration opportunities

    Making sure to identify these for your team, and to include them in your reporting, will help increase the knowledge of the value your team is bringing in terms and phrases that the business knows well (“X-qualified leads”).

    Rinse. Repeat (regularly).

    Businesses are always changing. One week the focus could be to raise awareness in developer communities about your company and the product and get people trying it out. The next week is that it’s important to target Enterprises, and next month it’s imperative that your team push the limits on what the company could do and/or become with AI. As a result, your activity inputs and outputs will change on a pretty consistent basis, and so it’s imperative that you continually perform these activities.

    Moving Developer Relations Forward (6 Part Series):
  • Moving Developer Relations Forward
  • The foundations of Developer Relations
  • Asking the right questions for DevRel impact
  • Developer Relations and the customer journey (this post)
  • Positioning DevRel as a resource within your company
  • So let's talk about DevRel Metrics

  • Cover Photo by Matt Howard on Unsplash