Add What We Learned at OSS Europe: A Plan for Measurable DevRel Blog …

src/authors/Cruzn65.md

@@ -0,0 +1,14 @@
+---
+name: 'Stacey Kruczek '
+username: Cruzn65
+avatar: 'https://avatars.githubusercontent.com/u/117698411?v=4'
+bio: ''
+url: 'https://github.com/Cruzn65'
+company: ''
+updated: '2025-09-22'
+---
+
+# Stacey Kruczek 
+
+
+

src/authors/authors.json

@@ -1,26 +1,42 @@
 {
+  "@Cruzn65": {
+    "username": "Cruzn65",
+    "name": "Stacey Kruczek ",
+    "bio": "",
+    "avatar": "https://avatars.githubusercontent.com/u/117698411?v=4",
+    "url": "https://github.com/Cruzn65",
+    "updated": "2025-09-22T10:46:48.395Z"
+  },
   "@anajsana": {
     "username": "anajsana",
     "name": "Ana Jimenez Santamaria",
     "bio": "Senior Project Manager, Linux Foundation",
     "avatar": "https://avatars.githubusercontent.com/u/43671777?v=4",
     "url": "https://github.com/anajsana",
-    "updated": "2025-09-06T16:44:57.658Z"
+    "updated": "2025-09-22T10:46:48.395Z"
   },
   "@devrel-foundation": {
     "username": "devrel-foundation",
     "name": "DevRel Foundation",
     "bio": "",
     "avatar": "https://avatars.githubusercontent.com/u/165706382?v=4",
     "url": "https://github.com/devrel-foundation",
-    "updated": "2025-09-06T16:44:57.658Z"
+    "updated": "2025-09-22T10:46:48.395Z"
   },
   "@j12y": {
     "username": "j12y",
     "name": "Jayson DeLancey",
     "bio": "Head of Security Advocacy, Semgrep\r\nSteering Committee, DevRel Foundation",
     "avatar": "https://avatars.githubusercontent.com/u/4029277?v=4",
     "url": "https://github.com/j12y",
-    "updated": "2025-09-06T16:44:57.658Z"
+    "updated": "2025-09-22T10:46:48.395Z"
+  },
+  "@mplacona": {
+    "username": "mplacona",
+    "name": "Marcos Placona",
+    "bio": "Founder @ DevRel Bridge & LinkIntel\r\nGroup Manager, DevRel Foundation",
+    "avatar": "https://avatars.githubusercontent.com/u/221627?v=4",
+    "url": "https://github.com/mplacona",
+    "updated": "2025-09-22T10:46:48.395Z"
   }
 }

src/authors/mplacona.md

@@ -0,0 +1,16 @@
+---
+name: Marcos Placona
+username: mplacona
+avatar: 'https://avatars.githubusercontent.com/u/221627?v=4'
+bio: "Founder @ DevRel Bridge & LinkIntel\r\nGroup Manager, DevRel Foundation"
+url: 'https://github.com/mplacona'
+company: DevRel Bridge
+updated: '2025-09-19'
+website: 'http://placona.co.uk'
+---
+
+# Marcos Placona
+
+Founder @ DevRel Bridge & LinkIntel
+Group Manager, DevRel Foundation
+

src/blog/2025-09-19-oss-summit-europe-2025.md

@@ -0,0 +1,111 @@
+---
+title: "What We Learned at OSS Europe: A Plan for Measurable DevRel"
+excerpt: "How the DevRel Foundation drives measurable outcomes, standard metrics, and practical frameworks for Developer Relations teams and leaders."
+author: "@mplacona, @Cruzn65"
+date: "2025-09-19"
+category: "announce"
+tags: ["community", "events"]
+---
+
+At Open-Source Summit Europe 2025 in Amsterdam, we hosted an Ask Me Anything with leaders from our community and the Linux Foundation. The goal was simple. Surface your biggest questions about DevRel and show practical ways the Foundation can help. 
+
+What we heard was clear. Teams want DevRel to focus less on activity and more on outcomes. Leaders want to invest with confidence, not gut feeling. If you care about making DevRel measurable and strategic, we want your voice in this Foundation.
+
+This post outlines the purpose of the DevRel Foundation, our plans for assistance, the most frequently asked questions, and how you can get involved. None of this is theory for theory’s sake. It is a working plan to help practitioners deliver better work and to help executives understand the business value that this work creates.
+
+## Why the DevRel Foundation exists
+
+Too often, DevRel gets judged by how busy it looks rather than the value it creates. Conference talks. Tweets. Swag. Meetups. These can be useful, but they are not outcomes on their own. Executives care about activation, adoption, retention, and revenue influence, while practitioners focus on unblocking developers and reducing time to value. We need a shared language that connects both perspectives.
+
+The DevRel Foundation exists to build that shared language and the standards that sit behind it. Our focus is on common definitions, practical frameworks, and open resources that any team can adopt. When we say activation, we should mean the same thing. When we say first value, we should measure it consistently. When we report results, they should map to business goals the same way as the product or sales team do.
+
+This is not about gatekeeping. It is about clarity. With clarity, teams can choose the right activities for their goals, stop focusing on those that do not move the needle, and make better cases for investment.
+
+## How we will help
+
+We are doing this work in the open. The Foundation is establishing working groups with clear mandates and visible roadmaps. Two early examples:
+
+* **Persona Library.** Standard, reusable developer personas you can adapt to your product and community. Each persona includes goals, pains, jobs to be done, channels, content preferences, and a default journey. This allows you to direct efforts to the right audience and avoid broadcasting to everyone at once.  
+
+* **Metrics frameworks.** Funnel-aware metrics that map to real outcomes. Think time to first value, activation rate, adoption depth, retention by cohort, and DevRel influence on sales cycles and expansion. Your team can pick a baseline set, tailor a few, and report in a way that makes sense to your leadership.
+
+Everything we create is open. Use it as is or fork and improve it. The point is not to publish a perfect document, but to develop shared scaffolding that teams can build on.
+
+<iframe 
+    width="560" 
+    height="315" 
+    src="https://www.youtube.com/embed/G1lRQCIMUG4" 
+    title="YouTube video player" 
+    frameborder="0" 
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; 
+    picture-in-picture" 
+    allowfullscreen />
+
+## Your questions answered
+
+### How do we secure more investment for DevRel?
+
+If you want investment, own ROI. That starts with translating DevRel results into the language of the company's OKRs. If your company values new logos and expansion, pick DevRel programs that influence evaluation, activation, and product adoption. If your company cares about platform stability and ecosystem growth, build programs that improve developer success and reduce time to unblock.
+
+Move beyond vanity metrics. Report progress against a simple journey that leadership already understands.
+
+* **Time to first value.** How long does it take a new developer to achieve their first success that matters; a successful build, a working webhook, or a deployed integration.  
+* **Activation.** The share of new developers who reach that first value within a defined period. For many products, that is within the first 7 or 14 days.  
+* **Adoption.** Depth of use after activation. Are developers using the next API, the next workflow, or the next feature that increases stickiness?  
+* **Retention.** Do activated developers return and keep building? Track it by cohort.  
+* **Influence on sales cycles.** Where DevRel shortens evaluation, reduces proof of concept time, or helps unblock procurement.
+
+Tie programs to these measures. Show the path from activity to outcome. For example, a tutorial refresh is not the outcome. The outcome is a lower time to first value for the target persona, confirmed by product analytics and user feedback. A community office hours session is not the outcome. The outcome is fewer stalled evaluations and more developers reaching activation in the same quarter.
+
+When you have outcomes, ask for resources to scale the programs that work. Use the business language your leadership uses. You are not asking for a headcount. You are proposing an investment that increases activation by a defined amount at a known cost.
+
+### How do we tie DevRel to revenue?
+
+Revenue is an outcome of successful journeys. DevRel can shorten and strengthen those journeys. The work is to trace developer progress across the community and the product.
+
+* **Connect the dots.** Use community intelligence and product analytics to see who is evaluating, who is unblocked, and who is converting. You do not need perfect attribution. You need a consistent way to see movement across key stages.  
+* **Instrument the handoffs.** Track how DevRel content and support reduce common blockers in proofs of concept. Track time from the first question to unblock. Track how often a successful proof of concept moves to a trial or purchase.  
+* **Capture stories and systematize them.** When you help a team move from evaluation to purchase faster, write the play. Which persona? Which blockers? Which content or support solved it? Turn that into a repeatable motion that anyone in your company can use.
+
+
+The [Metrics Index Project](https://github.com/DevRel-Foundation/wg-resource-aggregation?tab=readme-ov-file#working-group-projects) aggregates metrics you can adopt and adapt. Expect templates for funnel definitions, example dashboards, and sample reports that map DevRel outcomes to pipeline stages and customer health.
+
+### What are the most common challenges?
+
+We heard three over and over again.
+
+* **Perception problem.** DevRel is considered a cost center without clear value. The remedy is consistent language, transparent goals, and outcome reports that map to company OKRs.  
+* **Silos and access.** Teams do not have access to product analytics or cannot connect community signals to product data. The remedy is cross-functional alignment and a minimum shared instrumentation plan. Start small. Agree on the few events and labels everyone will use.  
+* **Unsustainable motions.** Travel-heavy schedules burn people out and waste money. Replace a portion of travel with scalable digital programs, local community partners, and content that compounds over time. When you do travel, tie every trip to a measurable goal.
+
+The Foundation is working on a [DevRel Maturity Model](https://github.com/DevRel-Foundation/wg-resource-aggregation?tab=readme-ov-file#working-group-projects) to publish playbooks for facilitating cross-function collaboration and promote sustainable operating models. These will include checklists, templates for shared dashboards, and example rhythms for data reviews involving product, marketing, and sales teams.
+
+### Which skills matter most now?
+
+This is where the craft of DevRel meets the discipline of product.
+
+* **Authentic, developer-first communication.** Speak to the problems developers actually have. Show how to solve them with real code, real examples, and real constraints.  
+* **Empathy and persona awareness.** Know who you are helping. A senior platform engineer has different constraints than a startup founder. Route your work accordingly.  
+* **Technical advocacy or strong routing to technical owners.** You do not need to be the deepest expert in every stack. You do need to get developers unblocked quickly. Either do it yourself or build the internal routing that makes it happen.  
+* **Data literacy.** You do not need to be a data scientist. You do need to choose the right metrics, interpret what they mean, and tell a clear business story. Learn enough SQL or analytics tooling to answer basic questions yourself. Pair with data partners for the rest.
+
+These skills are learnable. The [Resources Working Group](https://github.com/DevRel-Foundation/wg-resource-aggregation) will gather examples and training paths into a [Career Manual](https://github.com/DevRel-Foundation/wg-resource-aggregation) you can use to level up your team.
+
+## How you can participate
+
+Foundations are only as strong as the people who shape them. Here is how to plug in.
+
+1. [**Join our Discord community**](https://discord.gg/G7CSTKZcuT) **and introduce yourself.** Share what you work on, your product context, and what you want from the Foundation.  
+2. [**Explore working groups**](https://dev-rel.org/about/working-groups)**.** Pick one that fits your skills and goals. Personas, metrics, community operations, or another area you care about.  
+3. **Contribute to the [Persona Library](https://github.com/DevRel-Foundation/persona-library) and [Metrics efforts](https://github.com/DevRel-Foundation/metrics-index).** Bring your real-world examples. If your team already uses a persona or a metric definition that works, contribute it so others can adapt it.  
+4. **Share challenges and wins from your org.** We will not publish anything without your consent, but your experience can become a pattern others can use.  
+
+You do not need permission to start. If you see a gap, propose a contribution. If you have a question, ask it in public. If you can help another team avoid a month of trial and error, share your approach.
+
+## Final word
+
+DevRel gets stronger when we agree on what good looks like and how to measure it. It becomes easier to invest in when leaders can see the path from activity to outcome. That is what the DevRel Foundation is here to build with you. Shared definitions. Practical frameworks. Open resources that anyone can use.
+
+If you want DevRel to be clearer, stronger, and easier to fund, add your perspective. Contribute a persona. Share a metric that works. Tell us how your team moved activation or reduced time to first value. The more we publish together, the faster the whole field matures.
+
+Start at [**dev-rel.org**](http://dev-rel.org) and join us in Discord today.