A fill-in scorecard for developer relations teams. Set a target for each area, record what shipped, attach the evidence, and see at a glance whether you are on track. Download it as a PDF or CSV.
Targets are editable. Status turns "On track" or "Behind" once you set the start and end dates.
Pick the 30-day window and type a target for each area. Use "Load example targets" to start from my own plan, then change what does not fit your team.
Each week, update the done count and paste the link or note that proves it: a repo, a published URL, an analytics report, a session recording.
The status column compares your progress with how much of the period has passed. Download the PDF for the monthly review. Behind on one area? Move next week's work there.
The rules I use so that two people would record the same number.
One record per demo: the repo or deployment, the long-form video, and the short clips. A new clip extends distribution; it is not a new demo.
Record the analytics tool's definition of a unique reader next to the number. Keep page views in a separate field. Give each article its own 30-day window.
Community demos measure work people contributed. New member joins measure people. Report them side by side, never added together.
A message count says little. Record the question, the answer, and whether the developer could continue. Link any docs change it caused.
Show the reports filed and the distinct issues after grouping duplicates. Pair the count with one insights summary for product.
Applications show interest before the event. Projects completed show work at the end. Attendance, teams, and follow-up each need their own record.
Delivery is what the team shipped: demos, tools, articles, livestreams, office hours. A published URL establishes it. These counts change fast, so review them weekly.
Participation is what developers did with it: unique readers, community questions, demos they contributed, partners who joined. These need a full window to settle, so review them monthly.
Feedback is what the team learned and passed on: bug reports with reproduction steps and an insights summary for product and engineering. The count shows the workload. The detail helps the team choose what to fix.
I explain the full reasoning, with my own 30-day targets, in Developer relations metrics: my 30-day goals and event scorecard, part of my Developer Relations hub.
DevRel metrics are the numbers a developer relations team uses to show what it shipped, what developers did with it, and what the team learned. Good ones have a target, a count, and a piece of evidence such as a link or a report.
Split it into three groups: delivery (demos, articles, events), participation (readers, community questions, contributed demos), and feedback (bug reports, insights for product). Set a target for each, record evidence, and review it weekly. This scorecard does exactly that.
The ones tied to a decision. First builds and completed projects show if your content works. Community contributions show if people come back. Bug reports and insight summaries show if product learns from developers. Vanity totals without evidence do not help.
Weekly for delivery counts, so you can change the next week's work. Monthly for readership and community growth, because those need a full window to settle.
Yes. "Download PDF" gives you a one-page report with your targets, counts, evidence, and status. "Download CSV" gives you the same data for a spreadsheet. "Print" uses your browser's print dialog.
Yes, in your own browser (local storage). Nothing is sent to a server. "Copy share link" puts your data in the link itself, so you can send it to a teammate or open it on another device.
See advertised pay bands from 87 US DevRel job listings, filtered by role, level, and city.
DevRel AI Engineer, turning AI infrastructure into stories builders use.
© 2026 Roan Weigert. All rights reserved.
San Francisco, California