DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary:
  • Scribbles:
  • Dev roles are really diverse.
  • Dev rel roles are connected
  • Measuring acquisition
  • Measuring engagement
  • Developer engagement by software product or project
  • Measuring developer satisfaction

Was this helpful?

Export as PDF

Measuring dev rel programs far beyond marketing activities

Ana Jimenez Santamaria of Bitergia shares metrics and KPIs for dev rel programs that focus on developer engagement, developer acquisition, and developer satisfaction.

PreviousBuild the Platform Your Developers Actually WantNextHow to rock a technical keynote

Last updated 3 years ago

Was this helpful?

Summary:

  • Ways to measure your developer programs in terms of acquisition, engagement and satisfaction, but far away from marketing.

    • More focused on a community perspective.

  • Dev rel is about building relationships.

    • Department you came from but always have in mind the real mission and why you were hired as a dev rel and not as a marketing specialist.

    • ‘Cause dev rel is about building relationships, and it’s about community.

  • It’s really really nice that you track things related to marketing but don’t only do that.

  • Be near your developers and go to the same places with them.

    • Try to get the whole picture.

  • Understanding metrics take a lot of time.

  • Needs to get the domain knowledge

  • DevRels need to interpret numbers to get insight for your community.

Scribbles:

Dev roles are really diverse.

  • A dev rel can be hired by a soft foundation.

  • They can be hired by a company.

  • They can be hired because they want to manage open source projects.

  • Or just proprietary software.

  • Makes it really, really difficult to bring up a standard way of metrics.

  • Dev rel roles can report to many different departments and those departments have different ways, and different KPIs to measure success.

Dev rel roles are connected

  • They’re hired by a foundation.

  • They're hired for a company.

  • They report to marketing

  • They report to engineering.

  • Mission of a dev rel is always to build relationships with developers.

  • Developers can be seen in many different profiles or personas.

  • At the end, everything is related to community issues and ways to measure community.

Measuring acquisition

  • We can measure the developer growth by software product/project.

  • Real examples from the CHAOSS community.

  • Try to analyze the developer retention rate or the developer bounce rate.

  • Example - Software GrimoireLab, Open source

    • Activity -> community -> Attraction and retention.

    • Measure Git, ’cause we are fond of our community, it’s really engaged, it does a lot of Git code, for instance, and that’s a lot of Git commits.

    • You can see the attracted developers and the last committed developers over a period of time.

Measuring engagement

  • Take a look at the data sources about all the different challenges the developer community faces.

  • All the different data sources are aggregated, all the different channels where our community is.

  • We can define if my community is a contributors community, is a user community, is a maintainer community, or any other type of community you would like to profile.

  • Depends on a lot of domain knowledge.

  • Define a personas pattern.

Developer engagement by software product or project

  • See the most active community and the most engaged community project among the other ones.

  • Identify which projects had at some point some activity and then were left like the one on the prospect.

  • What happened then?

  • What did we do wrong?

  • Or what can we do better in order to improve that engagement with the project itself?

Measuring developer satisfaction

  • Uber OPSO use case

  • OPSO - open source program office.

    • Where open source and all the related activities related with open source are centralized and growing inside a company.

  • Uber wanted to know how efficient they were in answering, enclosing, and merging pull requests.

  • They wanted to measure GitHub in this case.

  • They wanted to know how fast they were when measuring Uber developers versus non-Uber developers.

  • Turns out that they tend to merge non-Uber developers took them more time when, rather than when, they wanted to merit a Uber developer pull request.

Video