In our last thrilling episode, we talked about the importance of setting strong foundations to enable your team's success.
In this episode, let's actually start by talking about failure instead. 😢
Imminent Threats to DevRel Teams Everywhere
What are some of the things that cause well-intentioned DevRel teams to fail? (These are from the companion No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) series.)
Misaligned expectations, with your organization's goals, and especially with your boss.
Trapping yourself in a silo, neglecting to form collaborative partnerships with others from across your organization.
Saying "yes" to everything, in a misguided attempt to be "helpful," and in the process both burning yourself out and missing out on opportunities to have a higher impact because you're stretched too thin.
In this new role, I wanted to create a framework to help safeguard not just our immediate team, but our entire DevRel function, against these sorts of pitfalls. That means:
Equipping all members of the team with a consistent and agreed-upon way to reason about the myriad of requests flying at us every day.
Ensure we are able to guard our 'yes' so we can focus on the things that are the most impactful use of our brilliant peoples' extremely valuable and limited time and energy.
Provide transparency to the rest of the organization on how we reason about request prioritization, both to set expectations upfront, but also to equip them with knowledge of how to increase the priority of their request.
Without further ado...
The DevRel Impact Factors™ Framework
Note: These are our DevRel Impact Factors, because they make sense for our company and our team. Yours may be similar, but will most likely be different. The process of how we arrived here is down below, in case you want to try this out at "home." :)
Here's what we ultimately came up with: a set of 10 DevRel Impact Factors in priority sequence. The intent is for these to be used in sort of the same way as the Agile Manifesto: there is value in ALL of these items, but the ones closer to the top are valued more.
Unblocks Another Team From Their Critical Priorities: DevRel is a critical member of various cross-functional teams that are working on “Priority 0” items for other departments, as well as the company as a whole. Making sure those initiatives make it over the finish line is one of our most important responsibilities. (Examples: Product launch documentation, staffing “top-tier” Strategic Events)
Customer, Prospect, or Partner Collaboration: When we do activities in concert with external entities that Temporal has (or wants) a relationship with, it’s always a win/win. We help the company, our product gains exposure in their developer communities, AND we get two Marketing teams driving views and attendance in concert with one another. 🤝 (Examples: Building invincible applications with Temporal and MongoDB (on MongoDB’s Developer Center, not our own website), Live Customer Trainings)
Exposes Product to "Net New" Target Developers (aka "Brand Awareness"): Does this activity get Temporal in front of a new developer audience who’s never been exposed to it before? (Or at least not in a good while?) Amazing! This in turn will help grow our product adoption in both Open Source and Cloud. (Example: Meetup in a Box, which enables folks to speak about Temporal at other peoples' meetups)
Community Growth: Will this activity cause more people to sign up and engage in Temporal’s Community channels, such as Slack and Luma? Great! This in turn grows the audience of people we can talk with, and announce future things to (and also makes for nice hockey stick graphs that VCs like! ;)) (Example: Code Exchange, where community members can showcase open source code they've built around Temporal)
Quick Experiment to Learn Fast: Is this something we can spin up an “MVP” of quickly, measure its effectiveness, learn something new, and use those learnings so future things we try are even better? ROCK ON! 🤘 (Example: Community Live sessions)
Aligned with Company Priorities: Does this activity drive meaningful (and ideally measurable) Temporal awareness in one or more of our target communities? HUGE win. (Examples: Temporal workshops @ PlatformCon, Temporal x AI technical content effort)
Improves First 48 Hours Of The Product Experience: We’re DevRel, and we care about overall Temporal adoption. Part of our job is to make sure that not just our current customers are happy, but also developers long-term. (Examples: Temporal Helm Chart, Docs IA improvements, Live Workshops Program)
Drive Revenue / Expand Cloud Usage Is Sales explicitly asking us to do this? Is this activity being done in concert with a key account or prospect? Is this activity around a use case wth a large transaction volume? Does it get people onto Temporal Cloud? All of these are great things we should heavily consider collaborating on. (Examples: Self Sign Up Onboarding, Self-Hosted-to-Cloud Migration)
Cross-Functional Collaboration: Is this something we can do that partners with other parts of Temporal? Marketing? Product / Engineering? Temporal Leadership? Amazing! Also something we should heavily consider. (Examples: Temporal Survey)
Low Cost (both Opportunity and $): Is this a quick win that can be banged out in a day or two? Is this an event that’s right in your town, or a short drive/train ride away? The less “expensive” it is to say yes, the more likely we are to do it! 🙂 (Examples: SCaLE (free open source community booth), Austin Python Meetup (Dev Advocate based in same city))
Why these priorities, in this order?
Wait... Isn’t making / saving money and helping your co-workers important?! YES! Absolutely! However... there are certain things that only our team can do / are focused on, and therefore those things tend to be rated higher in priority in this list. (Also, our #1 of unblocking “Priority 0” items from other teams already covers most of those. 🙂)
And some of the things in this list—for example, “Quick Experiment to Learn Fast”—we rank artificially high, because we have a need right now to break a historic pattern of long delivery cycles, which is critical to increasing our team’s velocity and impact.
We intend to revisit this list as a team quarterly and evaluate if it needs adjusting.
How does this framework play out in practice?
Let’s talk through an actual scenario:
Should we partner with Big Customer on a virtual Office Hours session, or should we go on a tour of Florida developer meetups?
We’ve been asked to do both. Which one should we prioritize?
With the first opportunity:
✅ Customer, Prospect, or Partner Collaboration Yep. Big Customer! Next?
✅ Exposes Product to "Net New" Target Developers Big Customer also has a BIG developer community, only a small fraction of whom have likely heard about Temporal.
✅ Aligned with FY26 Company Priorities Both Big Customer and the AI Demo we're planning intersect with our company's target segments.
✅ Drive Revenue / Expand Cloud Usage We're talking about our product on Big Customer's channel, in concert with their account’s Solutions Architect. This opens up lots of doors for future revenue opportunity.
✅ Low Cost (both Opportunity and $) It’s virtual, so no one needs to hop on a plane. We can also leverage the code and deck from a previous demo for this.
Now let's examine the second opportunity:
❌ Customer, Prospect, or Partner Collaboration This would be more of a local community engagement opportunity.
✅ Exposes Product to "Net New" Target Developers Yep, that’s true!
❓ Aligned with FY26 Company Priorities Possibly... it depends on what talk is given. But presently at least, Florida is not known to be a hotbed of where our target developer audiences are located.
❌ Low Cost (both Opportunity and $) We have no one on our team based in Florida, so this would be a high-cost opportunity: plane tickets and hotel rooms for multiple nights.
The first request is not just a yes, it's a HELL YES! :D
For the second, we would be more likely to seek partnership with either a local Temporal engineer or a local community member for whom the "Low cost" box is checked, and/or ask the requester if there's an opportunity to "jar pack" this activity along with something else (e.g. a larger regional developer conference, a lunch and learn with a key customer in the area, etc.) that increases the number of factors it checks.
And if not, the answer is either a polite "no" or "not yet" and we go back to working on all our awesome high impact stuff! :)
How do I put together DevRel Impact Factors for my team?
Here was our approach:
Start with your company and departmental priorities. Incorporating these into your framework at the start will avoid a whole bunch of problems later. :)
Next, mix in your boss's opinion. Especially about the "priority order" part of the list. This is also where "quick experiment, learn fast" was introduced to our list.
Gather and incorporate the rest of the DevRel team's feedback. This adjusted the priority of some items, added "first 48 hours" and moved "unblock other teams" to the very top.
Test it out on a couple of sample requests and tweak accordingly. For example: "Low cost" got added as the final factor when we tried using this framework for evaluating which events to attend and speak at.
Send to cross-functional stakeholders for feedback. It's important to break out of your silo and gain perspectives from folks elsewhere in the company as well, and address any of their concerns/questions upfront (also, the better they understand these factors, the more impactful requests they'll make!). However, since one of the problems you're trying to solve with a framework like this is not having your team running around constantly doing only what other people want ;) you may want to table some of that feedback for the next iteration.
What are YOUR Team's DevRel Impact Factors? 👀
Would you say there a Venn diagram with most of these or no? What factors do you think might be missing or tweaked? And more broadly, how does your team tackle the same ongoing challenge of prioritizing incoming requests?
