// The DevRel randomisation trap (and how to stop it)

There’s a word that came up in my dissertation research that I’m all too familiar with: randomised.

As in, “our DevRel team gets randomised constantly.” As in, whichever stakeholder has the most urgent request this week determines what the team works on. As in, there’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’re in DevRel, you’ll possibly recognise this pattern.

A quick note before I get into this: the patterns I’m describing here come from 13 interviews I ran with DevRel leaders for my MBA dissertation, predominantly at technology companies. It’s a small qualitative sample, so I’d treat this as a useful pattern, not a hard rule. (But if you’ve read one of my earlier posts in the series, you already knew that!)

To me, the randomisation trap is where everything in this series lands. In the first post, I described the underlying problem as the friction between DevRel’s visible work and its less visible strategic contribution. This is the result when it goes unmanaged.

The measurement gap means there’s no external evidence of strategic value to protect team capacity. Unclear scope means the four pillars can be treated like a grab-bag rather than a focused remit, so stakeholders can reasonably argue that anything developer-adjacent is the DevRel team’s job. And when the feedback loop and the developer experience work stay invisible, people default to the visible activity they already understand. The foundation of authentic advocacy gets squeezed first, because the slower trust-building work is easier to deprioritise than the loud visible work. And when that happens, the bidirectional co-creation model starts collapsing into one-way promotion. Put those together and teams get randomised.

You can see it in ordinary DevRel work. Organic / grassroots efforts on documentation improvements to improve the developer experience slip because a launch blog suddenly matters more. Office hours get dropped because an event deadline is louder. Community follow-up waits while the team prepares webinar content. A champions or ambassador program gets treated like a nice-to-have because nobody can point clearly to how it supports the company goals. The work has not become less important, just easier to displace.

Across the earlier posts, I looked at what DevRel is, what it does, what context shapes it, and how teams try to measure it. This final post is really about what protects all of that from disappearing under day-to-day pressure.

Why DevRel teams get randomised: it’s an infrastructure problem

When I talk to folks about this pattern, the typical reaction is that the randomisation happens because the team isn’t pushing back hard enough, isn’t being strategic enough or doesn’t have the right stakeholder relationships.

Chris, isn’t this just a team needing to get better at saying no? I don’t think that’s the right diagnosis.

I think this is mostly a systems problem, not a personal failing. If a team has no clear priorities, no shared scope, and no agreed way to weigh requests, even a thoughtful DevRel leader will get pulled around. You cannot defend priorities nobody can see.

One participant described the external perception that feeds the problem:

When they don’t know where to send something, DevRel can do it. They can do a lot of things. And so, they see us as a content generation machine or a marketing machine, missing the developer experience aspect.

I’ve seen this play out myself and in conversations with practitioners I’ve worked alongside. Consider a week where multiple ‘urgent’ requests land from different stakeholders when there’s no shared framework for choosing between them. By the end of the week, the team has worked on a bit of both and either satisfied neither, or come at the cost of the quieter work that actually matters more, or worse, burn out. The team is exhausted, the stakeholders are frustrated, and the strategic work is left waiting for another week when it can be squeezed in again. Laurie Voss has written a clear breakdown of what DevRel actually is and how to measure it: three tiers of activity, with documentation and engineering at the top, content and events in the middle. I believe that randomised teams tend to end up reorganising that stack, spending more time on the tier-two work (content, events, chasing virality) because it’s louder and gets attention from management, not on the tier-one work because it’s higher leverage.

The problem isn’t just a strategic one, but then becomes a cognitive one. Gloria Mark’s research at UC Irvine on the cost of interrupted work found that it takes an average of over 23 minutes to refocus on a task after an interruption. Dr. Sophie Leroy’s research on attention residue explains why: part of your attention stays on the prior task rather than fully engaging with the new one, and the effect is worse when tasks are left unfinished and when people anticipate being pulled back. While Cal Newport’s framing of deep work captures the broader pattern: shallow, reactive tasks crowd out the high-leverage work that requires sustained concentration.

Documentation rewrites, DX audits, feedback synthesis, community program design: this is all deep work. It cannot survive constant interruption. The cost accumulates, and it compounds. So how can we start building the infrastructure to stop it?

The DevRel golden thread

The most important part of this is the golden thread: a visible link between the company’s goals and the DevRel team’s day-to-day work. In practice, this looks something like:

Company OKRs (or whichever strategic framework your company uses) → DevRel mission statement → Developer funnel (by stage and developer type) → Tactical activity metrics

Each level exists to serve the one above it. The tactical metrics make sense in the context of the funnel stage they’re serving. The funnel stages are relevant because they connect to the DevRel mission. And then the mission holds up because it clearly supports the company’s goals.

This is a chain you can follow from company goals to day-to-day DevRel work. If you want the formal label, it’s close to what Kaplan and Norton described with the Balanced Scorecard: every metric should link back to a strategic objective. Plenty of organisations talk about this, but from my discussions, I found that few DevRel teams have it in place. Tessa Kriesel’s DevRel strategy breakdown is an example framework for mapping this chain, connecting OKRs through to milestones and team operations. But remember, the exact shape of that chain will vary with company context and lifecycle, because the funnel for an early-stage developer platform shouldn’t look the same as the funnel for an established company with a mature ecosystem.

It’s also the thread that was missing in the measurement post. The RODI framing that I proposed only becomes useful when it sits between funnel stages and tactical investments. Once you can see what it costs to move developers from Discover to Evaluate, or from Learn to Build, the golden thread isn’t just a reporting aid, but a prioritisation tool.

And this is where several earlier threads meet. The funnel cannot be generic. It needs to reflect company context and lifecycle, because a developer-first startup has different priorities from a mature developer-plus platform. It also needs to reflect the distinction between the wider ecosystem and the narrower community that we discussed in my communities post, because not every developer is on the same journey or needs the same level of investment. If those distinctions disappear, the golden thread becomes too abstract to protect anything.

In practice, that can mean very different choices. One team might decide the main priority is getting Evaluate-stage developers to first success, so it focuses on quickstart docs, starter repos, onboarding workshops, and office hours. Another might decide the priority is deeper adoption in an established ecosystem, so it invests more in advanced tutorials, beta feedback sessions, and a champions program. Notice how the overarching goal is similar, and that the same DevRel function is operating with a very different chain?

When the golden thread exists and people can see it, not just inside the team but in stakeholder conversations, prioritisation becomes easier. You can have a principled conversation:

We’d love to support that initiative. Here’s how it connects to our current priorities. If you’d like us to add it, which existing priority would you like us to deprioritise?

When it doesn’t exist, those conversations default to whoever is asking most urgently, or has the most senior title in the room. One participant explained that scenario directly:

Many DevRel teams don’t go to the CEO and say, what’s your North star? We need to look at the top level OKR and ask how we contribute. Because if we’re not, the entire team has no value. And we’ve seen a lot of layoffs in the DevRel space as teams are not justifying their value.

The 11th Annual State of DevRel Report backs this up: 61% of DevRel professionals name demonstrating business impact as one of their hardest challenges.

The DevRel charter

With that, the golden thread needs to show up in something that stakeholders can understand and use. This is what a DevRel charter does.

Now when I say charter, I don’t mean a strategy document. I mean something shorter, more accessible, and more explicit about what the team does and what it doesn’t. It answers a few core questions:

• What does the DevRel team do?
• Which parts of the four-pillar mix matter most in our context?
• Who are we serving, and at what stage of their journey?
• What does success look like at the strategic level?
• And, crucially, what is not in scope?

In practice, the four pillars give you a natural structure for the “in scope” section: how much of the team’s mandate currently sits in education, success, marketing, and programs, and at what depth? The authentic advocacy foundation is worth mentioning too, because it sets the tone for how the work across the pillars gets carried out.

A good charter also needs to make clear whether the team is serving the wider ecosystem, the narrower community, or both as we talked through in the communities post. Those groups need different formats, different depths of investment, and different definitions of success, so if the charter blurs them together, the team will end up promising everything to everyone.

If the charter says the team owns self-serve docs, onboarding content, workshops, and office hours for the broader ecosystem, plus a smaller champions or ambassador program for deeper community work, stakeholders can see the shape of the mandate. If it just says “we support developers”, every request starts sounding like it belongs to DevRel.

The “not in scope” section is often the hardest to write and the most valuable thing on the page. Every DevRel team I’ve spoken to has experienced scope creep: requests from product teams, marketing teams, sales teams, and executive leadership that are developer-adjacent and slowly but surely increase the team’s scope and workload. Angie Jones put it plainly in her guide to developer advocacy: developer advocates are engineers, not marketers, and blurring that distinction erodes the community trust that makes the role work.

One participant described a pattern I’ve thought about a lot since:

When scope isn’t explicitly defined, the team ends up absorbing whatever developer-adjacent work has no other owner.

The implication wasn’t that DevRel should be an empire, but that without clear boundaries, the work just lands where there’s capacity to receive it. And that is what randomises teams. Tim Benniks frames the same point in his DevRel OS piece: DevRel only succeeds when treated as a disciplined operating system with defined scope, not as a catch-all for developer-adjacent work without a home.

The “not in scope” discipline connects to a broader strategic principle. Michael Porter’s “What Is Strategy?” made the canonical case: the essence of strategy is choosing what not to do, because trying to compete on every front means competing effectively on none. Roger Martin and A.G. Lafley’s Playing to Win applied that same logic to operating decisions. A DevRel charter applies it at team level: the “not in scope” section is where you make your priorities visible before everyone else starts making them up for you.

Getting stakeholders to review the charter and agree to it, not just nod at it, is what makes the document matter. A charter sitting in a shared drive does nothing. It needs to be agreed with the people most likely to throw new requests at the team.

Burden inversion: a simple technique that changes the conversation

One of the most useful things anyone said in the research was this:

I like to ask, “If we’re going to spin up this program, which one would you like me to cut that we’re doing now?” It’s what I like to call burden inversion. You’d be amazed at how many people come with that and leave once you burden them to prioritise it. They never get back to you.

“They never get back to you” is the tell. Burden inversion changes the conversation.

Burden inversion is effectively the day-to-day embodiment of the charter’s “not in scope” discipline. The charter sets the boundary at team level. Burden inversion is what happens when that boundary gets tested in real time, request by request.

Instead of acting as though new work can be added without anything else moving, burden inversion forces the trade-off into the open straight away. The question stops being “will you do this?” and becomes “what should drop if this now matters more?”

It shouldn’t be combative, and it’s not a flat no. Instead, it’s a clear statement of reality: the team has limited capacity, so the stakeholder needs to help decide what matters most.

What burden inversion does in practice is filter requests. Many stakeholders who would happily suggest that DevRel “spin something up” around their initiative will, when asked which existing program they’d like to cut, either withdraw the request or shrink it fast. The urgency was louder than the priority. Think of it like Dependency Injection for prioritisation: instead of the team taking on new work and then trying to figure out how to fit it in, the stakeholder has to inject the new priority into the existing mix and decide what it displaces.

The stakeholders who still push for the work afterwards are often the ones already aligned with what DevRel is there to do, and are the collaborations worth pursuing. The ones who back off are often the ones who would have pulled the team away from its core work, and are the ones worth considering saying no to.

Julien Lengrand has written about a complementary approach at the team level: using the AAARRRP framework to manage expectations upwards. Making your team’s priority areas explicit before stakeholders define them for you is essentially burden inversion applied systematically instead of request by request.

Burden inversion is where the strategy becomes real. If someone wants a last-minute webinar for a product launch, or asks DevRel to spin up a one-off integration demo series, the question is whether that matters more than the fundamental documentation work, the workshop series, closing the feedback loop or growing the community programs already on the plan.

If the golden thread, the charter, and the measurement model cannot survive that conversation, they were never properly embedded.

The DevRel executive visibility problem

There’s a specific form of randomisation that deserves its own attention: the executive visibility problem.

Several participants described the same dynamic. One summed it up:

Some parts of the organisation just think “What are these people doing, giving talks, and travelling and all of that?” […] However, making sure that you have regular syncs with different departments helps you to develop content ideas or activities to promote what they are doing. But it does take a lot of communication, sometimes overcommunication.

The work that matters most (the internal advocacy, the feedback loops, the day-in-day-out insight about what developers are actually struggling with) is the work that executives can’t easily see. This is the invisible work problem from the feedback loop post showing up again, just from the leadership side rather than the product side. And as my developer experience post argued, part of the problem is structural: the docs page that got rewritten because a developer advocate spotted the gap, or the onboarding flow that improved after community feedback reached product, often shows up as a product improvement rather than a DevRel contribution. The work disappears into a better experience. And when executives can’t see it, they can’t value it or protect it. And the stakes are real:

At the end of the day, if I don’t have executives that believe that we’re here providing value, to begin with, […] that’s where your DevRel team gets cut.

When executives only see the visible work, they start to think DevRel is mostly talks, travel, and social posts, not the quieter work that often matters more. That changes how they judge the team, what they protect when budgets get tight, and what they cut first. The DevRel.Agency analysis of DevRel in a downturn documented this shift as it was happening: by 2023, 15% of DevRel professionals were actively looking for work. Given the layoffs and restructuring the field has faced since then, executive visibility matters more than ever.

The answer is to show that work to leaders on purpose, and regularly. Not as a defensive move, but so that the people deciding budget and headcount can actually see the full picture. Metrics tell you the numbers. Executive communication explains where they came from, what changed because of them, and what will never fit neatly in a dashboard. Kim Maida’s Developer Empowerment Flywheel is one approach to that translation: by naming each stage of the developer journey (Inspire, Educate, Activate, Engage, Empower) and attaching metrics at each critical point, it gives executives a way to see the full scope of DevRel’s contribution rather than just the loudest slice. Similarly, Mary Thengvall’s concept of DevRel Qualified Leads tackled the problem from a different angle: define the metrics that reflect what DevRel uniquely does before leadership fills the gap with proxies that don’t fit.

Where DevRel sits matters

Equally, there’s one more part of stakeholder alignment that comes up again and again: where DevRel sits in the organisation.

Reporting lines shape what DevRel gets asked to do and how success gets judged. Teams in marketing often get pulled towards marketing metrics. Teams in product often lean hard into feedback at the expense of grass roots community work. If DevRel is genuinely about value co-creation rather than one-way promotion, that org design question matters a lot, because it determines how much room the team has for inward advocacy as well as outward work.

You can usually see the difference in the work that gets emphasised. A team measured like marketing may get pushed towards launch blogs, campaign webinars, event reach, and social reporting. A team measured like product may spend more time on DX audits, feedback synthesis, onboarding friction, and roadmap influence.

One participant set out the dynamic clearly:

Understanding who developer relations report to, is it reporting directly to the CEO as a whole business function? Or is it falling under the product or marketing? That also helps drive the strategy of developer relations. If I’m reporting to someone in product, I’ll be influenced by their metrics. If I’m reporting to someone in marketing, I’ll be influenced by their metrics. If I report directly to the CEO, I feel I’m on an equal footing with product and marketing and can coordinate directly between both.

Now I’m not saying every DevRel team should report to the CEO. Laura’s DevRel org structure piece is worth reading as a counterpoint: what actually matters is cross-functional trust and the ability to speak different teams’ languages, not the org chart itself. The right setup depends on the company, its stage, and what the team is there to do.

What I am saying is that the reporting line is never neutral, as it changes the work, the measures, and the influence. Where DevRel sits matters.

Putting it all together: the three moves that stop randomisation

If I had to boil this down, I’d focus on three things:

1. Build the DevRel golden thread. Map from company OKRs to DevRel mission to funnel to tactics. Make it explicit. Make it visible. Revisit it when company strategy changes.

2. Write the charter and get stakeholder agreement. Define the scope, including what sits outside it. Talk it through with the people most likely to send new work your way. Review it annually or when the team’s mandate changes.

3. Invert the burden consistently. When new work is proposed, make the capacity trade-off explicit. “Which existing priority would you like us to deprioritise?” is a question that changes the quality of prioritisation conversations.

Those three moves are where the rest of the series converges:

1. The golden thread turns the measurement gap, the funnel, and the company context questions into a usable strategic chain.
2. The charter turns the four pillars and the community-versus-ecosystem distinction into an agreed mandate.
3. Burden inversion protects the feedback loop, the DX advocacy, and the trust-building work from being crowded out by whatever arrived most urgently this morning.

And that’s also why I’ve kept this series strategic rather than tactical: it’s been about the layer above, the strategy that makes those tactics coherent in the first place.

This takes discipline:

• The golden thread goes stale if you stop updating it.
• The charter loses its weight if nobody uses it.
• Burden inversion stops working the moment you take on new work without asking the question.

Expectations reset quickly.

Closing the series

This is the final post in the series. I started the dissertation with a question: what does value creation in Developer Relations actually look like? Nine posts later, I think the answer is clearer than when I started.

DevRel creates value when developers genuinely get to value, when teams listen closely enough to surface friction and feed it back into the company, and when that work is connected to strategy clearly enough to protect time and focus. Every topic in this series turned out to be a different part of that same system, not separate side-quests.

DX is probably the clearest proof. It doesn’t sit cleanly in one box of the model I set out in the first post. It constrains what teams can achieve before the work starts, shows up in the daily practice of every pillar, compounds through adoption when things go well, and is the first thing to lose protection when teams get randomised. The audit that didn’t happen, the feedback conversation that got bumped, the friction that stayed invisible because nobody had capacity to go looking for it: that is the cost of this missing infrastructure. When those conditions are weak, teams get randomised. When they are strong, the whole model can flourish.

Good DevRel work doesn’t happen by accident. It needs the right conditions, the right operating model, and enough clarity to stay focused when pressure arrives. Build those conditions and the value follows. Skip them and teams end up randomised, under-resourced and their true value unrealised.

The developer-plus context is still underrepresented in my research, and I suspect DX’s role looks meaningfully different there. RODI is a framing, not a finished method. And attributing DevRel’s contribution to developer experience still feels like one of the harder problems in the field, because the best work often disappears into a better product. Those feel like the start of the next chapter: what good DX audits look like in practice, how to design community programs, how to instrument the funnel, and how to report invisible work in a way leadership can actually understand.

I did this research because I’m fascinated by the power of community and the potential of DevRel to create value for companies and developers alike. But equally, because I’m well aware of how much of that potential goes unrealised when the right conditions aren’t in place with teams being pulled in opposing directions by competing priorities.

I wanted to explore whether there was a better answer. I think there is. And I hope that my dissertation (and this series) has been part of working towards that.

If you’ve been following along, I’d genuinely love to hear your reaction, whether you found it useful, whether you disagree with anything, or whether there’s a dimension you feel I’ve missed entirely. Drop a comment on the BlueSky post below, or find me on LinkedIn to have a more private conversation.

Until the next blog post (maybe? 👀), bye for now!