| description |
|---|
Ana Jimenez Santamaria of Bitergia shares metrics and KPIs for dev rel programs that focus on developer engagement, developer acquisition, and developer satisfaction. |
{% embed url="https://youtu.be/M3t09u9ZuC4" caption="Video" %}
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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.