<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Research on Chris Reddington</title><link>https://chrisreddington.com/tags/research/</link><description>Recent content in Research on Chris Reddington</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Tue, 31 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://chrisreddington.com/tags/research/index.xml" rel="self" type="application/rss+xml"/><item><title>The DevRel randomisation trap (and how to stop it)</title><link>https://chrisreddington.com/blog/devrel-randomisation-trap/</link><pubDate>Tue, 31 Mar 2026 00:00:00 +0000</pubDate><guid>https://chrisreddington.com/blog/devrel-randomisation-trap/</guid><description>&lt;p&gt;There&amp;rsquo;s a word that came up in my dissertation research that I&amp;rsquo;m all too familiar with: &lt;em&gt;randomised&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;As in, &amp;ldquo;our DevRel team gets randomised constantly.&amp;rdquo; As in, whichever stakeholder has the most urgent request this week determines what the team works on. As in, there&amp;rsquo;s no clear prioritisation framework that makes it possible to say yes to some things and no to others with a clear rationale, so the team ends up trying to do everything and not fully realising the value of it all. If you&amp;rsquo;re in DevRel, you&amp;rsquo;ll possibly recognise this pattern.&lt;/p&gt;</description></item><item><title>From tactics to strategy: the DevRel measurement gap</title><link>https://chrisreddington.com/blog/devrel-tactics-to-strategy/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://chrisreddington.com/blog/devrel-tactics-to-strategy/</guid><description>&lt;p&gt;A pattern I see across DevRel is that teams can usually tell you what they did by using metrics like video views, blog traffic, event attendance, stars on GitHub repositories, community growth and Net Promoter Scores. The visible metrics are rarely the hard part.&lt;/p&gt;
&lt;p&gt;The harder part is working out whether those metrics tell you anything meaningful about impact (tied back to product adoption and improving the developer experience). Many of us practitioners have known that for a long time. DevRel has plenty of vanity metrics: numbers that are easy to collect, easy to report, and easy to mistake for evidence that something important changed. That doesn&amp;rsquo;t make them useless, but they they don&amp;rsquo;t tell the full story on their own.&lt;/p&gt;</description></item><item><title>Why developer communities are not brand communities</title><link>https://chrisreddington.com/blog/devrel-communities-not-brand-communities/</link><pubDate>Sat, 21 Mar 2026 00:00:00 +0000</pubDate><guid>https://chrisreddington.com/blog/devrel-communities-not-brand-communities/</guid><description>&lt;p&gt;I&amp;rsquo;ve spent a good chunk of my career working with developer communities (whether that&amp;rsquo;s external communities, or internal ones inside companies), and I&amp;rsquo;ve seen this pattern several times. A program would launch with strong company branding, get some early traction, and then eventually decline. Developers were using the technology and showing up. But they were showing up for the product and each other, not because of a deep attachment to the brand behind the program.&lt;/p&gt;</description></item><item><title>The four pillars of DevRel (and the foundation they rest on)</title><link>https://chrisreddington.com/blog/devrel-four-pillars-authentic-foundation/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://chrisreddington.com/blog/devrel-four-pillars-authentic-foundation/</guid><description>&lt;p&gt;When I started reviewing the literature on Developer Relations for my dissertation, I expected to find prior academic research that reflected what DevRel teams do. The field has conferences, frameworks, books, and more opinion pieces than I can count.&lt;/p&gt;
&lt;p&gt;What I found (at least academically) was thinner than I expected. The most structured practitioner account came from &lt;a href="https://doi.org/10.1007/978-1-4842-7164-3"&gt;Lewko and Parton&amp;rsquo;s 2021 book&lt;/a&gt;, which maps DevRel activities across four primary domains: Developer Education, Developer Marketing, Developer Success, and Developer Programs, with Developer Experience at the centre as the goal that the whole system is working towards. In my &lt;a href="https://chrisreddington.com/blog/devrel-developer-experience/"&gt;previous post&lt;/a&gt;, I explored why DX sits at the centre. This post moves one layer out: if DX is the centre, these four pillars are the main ways DevRel teams shape it in practice.&lt;/p&gt;</description></item><item><title>How does Developer Relations (DevRel) create value? What 13 interviews revealed.</title><link>https://chrisreddington.com/blog/devrel-value-creation/</link><pubDate>Wed, 11 Mar 2026 00:00:00 +0000</pubDate><guid>https://chrisreddington.com/blog/devrel-value-creation/</guid><description>&lt;p&gt;What does value creation in Developer Relations actually look like?&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;m not asking what DevRel &lt;em&gt;does&lt;/em&gt;, as there&amp;rsquo;s plenty of descriptions of DevRel activities out there. Nor what it &lt;em&gt;should&lt;/em&gt; do, as there&amp;rsquo;s no shortage of opinion there either. But what does value creation (the specific mechanism by which a DevRel team contributes something meaningful to its organisation and its developer community) actually look like in practice?&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve spent a large part of my career in and around Developer Relations, so I&amp;rsquo;ve been thinking about this question for a while. Back in 2024, I decided to stop thinking about it and actually research it.&lt;/p&gt;</description></item></channel></rss>