This is Part 6 of my 6-part series on business literacy for DevRel. Start with Part 1 if you missed it.
We've covered a lot of ground in this series. Sales pipelines and forecast accuracy. Marketing funnels and MQLs. P&Ls and CapEx vs OpEx. Product-Led Growth and how it changes the game for developer tools companies. If your brain feels a little full right now, that's normal. This is a lot of new vocabulary and new ways of thinking.
But you now have the foundation. You understand the basics of how the key parts of your business operate, what they care about, and what language they speak. You understand how modern go-to-market models work and where DevRel fits in.
Now let's talk about what you actually do with all this knowledge.
Where DevRel Sits in the Business Landscape
If you think about your company as an ecosystem, DevRel occupies a unique position. You're not sales, but you influence deals. You're not marketing, but you create awareness and demand. You're not product, but you deeply understand user needs. You're not support, but you help developers be successful.
I often say "DevRel rhymes with lots of different parts of the business"
You're the bridge. You're the translator. You're uniquely positioned to connect the technical world of developers with the commercial world of business.
And that's actually a superpower, not a weakness. The question is, are you using it?
The DevRel Translation Guide
Let's get practical. Here's how you translate common DevRel activities into language that resonates with different stakeholders:
Example 1: Conference Talks
What you do: Give a technical talk at a conference about solving a real problem using your technology
How different stakeholders hear it:
To Sales: "This is TOFU content that builds awareness and credibility in a target market. Prospects who attend or watch this talk are more likely to trust us when we're in their consideration set."
To Marketing: "This creates thought leadership content at the top of the funnel, reaching developers in our target persona. The recorded talk becomes an asset we can promote for months."
To Finance: "For a $5K investment (travel, event costs), we reach 200 in-person developers and potentially 10K+ via the recorded talk. Compared to paid advertising costs of $50-100 per qualified lead, this is highly efficient awareness generation."
To Your CEO: "This positions our company as a technical leader in [space], increases brand awareness with our target audience, and creates trust that accelerates the sales cycle."
Example 2: Office Hours Program
What you do: Run weekly office hours where developers can get help with technical challenges
How different stakeholders hear it:
To Sales: "This is MOFU activity that helps prospects overcome technical blockers that might prevent deals from closing. Sales can invite prospects to office hours as a value-add during the evaluation phase."
To Marketing: "This creates ongoing touchpoints with developers in the consideration phase, moving them down the funnel. It also generates insights about common pain points we can address in our content."
To Finance: "This program costs approximately $X per quarter (staff time) and supports Y developers, reducing the load on our paid support team (saving $Z) while accelerating deal velocity."
To Product: "This is a direct line to user feedback. We're hearing real problems from real users, which informs our product roadmap and helps prioritize features."
Example 3: Documentation Improvements
What you do: Rewrite documentation to make it clearer and more accessible for developers
How different stakeholders hear it:
To Sales: "Better docs reduce technical objections during the sales cycle. When prospects can self-serve and get quick answers, it reduces friction in the buying process."
To Marketing: "Great docs are a conversion tool. When someone is evaluating our product, comprehensive docs signal quality and reduce perceived risk."
To Finance: "Improved docs reduce support ticket volume by X%, which translates to $Y in reduced support costs. It also improves trial-to-paid conversion, impacting revenue."
To Product: "Quality documentation improves user experience and product adoption, which reduces churn and improves LTV."
Example 4: Community Building
What you do: Build and nurture an active community where developers help each other
How different stakeholders hear it:
To Sales: "An active community is social proof. When prospects see thousands of engaged developers, it reduces perceived risk and speeds up the sales cycle."
To Marketing: "Community creates network effects that reduce our CAC over time. Developers in the community become advocates who bring in new users organically."
To Finance: "The community provides peer-to-peer support that would otherwise require paid support resources. If 70% of questions are answered by community members, that's saving us $X in support costs annually."
To Your CEO: "Our community is a competitive moat. It's relationship capital that competitors can't easily replicate, and it creates switching costs that improve retention."
Having Better Conversations With Stakeholders
The key to using your business literacy isn't just knowing the vocabulary. It's understanding what different stakeholders care about and framing your work in those terms.
With Sales
Talk about: pipeline influence, deal velocity, technical credibility, competitive positioning, removing buying blockers
Example: "I'd like to pilot a program where DevRel joins strategic deals for technical deep dives. Based on what I've seen, this could reduce time-to-close by 2-3 weeks by addressing technical concerns earlier in the cycle. Want to try this with three opportunities next quarter and measure the impact?"
With Marketing
Talk about: funnel stages, campaign support, content performance, lead quality, brand awareness
Example: "I noticed the marketing team is planning a campaign around [topic]. DevRel can support this by creating technical deep-dive content that serves the MOFU stage. We'll own the technical accuracy and authentic voice, which should improve conversion from awareness to consideration."
With Finance
Talk about: budget allocation, ROI, cost efficiency, strategic investment, measurable outcomes
Example: "I'm requesting $30K for three conference sponsorships next quarter. Based on last year's data, this typically generates 150 qualified conversations, with 10-15 entering our pipeline. At our average deal size, if just two deals close, that's $200K in revenue from a $30K investment."
With Executives
Talk about: business objectives, market position, competitive advantage, growth levers, strategic priorities
Example: "Our community strategy supports three key company objectives: it reduces CAC through organic growth, it creates customer stickiness that improves retention, and it provides product insights that help us build what developers actually need. This quarter we'll focus on [specific initiative] to accelerate growth in [target segment]."
Common Pitfalls to Avoid
As you develop your business literacy and start speaking this language, watch out for these traps:
Over-rotating to business speak: Don't become so focused on business outcomes that you lose sight of serving developers. If developers don't genuinely benefit from what you're doing, it's not sustainable DevRel work.
Claiming direct attribution when it's influence: Be honest about what you can and can't directly attribute to DevRel. Influence is still valuable, but don't claim you "closed the deal" when you participated in one discovery call.
Using business literacy to justify work that doesn't serve developers: Business literacy should help you advocate for developer-serving work, not rationalize doing things that only benefit the business.
Becoming a "mini-marketer": You're not marketing. You can use marketing language to communicate, but don't let that change what you actually do or how you do it.
Overpromising to get budget: It's tempting to make big claims to secure resources, but if you can't deliver, you damage your credibility for future asks.
Business Literacy ≠ Selling Out
Let's address this head-on one more time: learning to speak business language doesn't mean you're selling out.
You're still serving developers first. You're still advocating for their needs. You're still building authentic relationships and creating genuine value.
What you're doing is making sure the people who control resources understand why that work matters to the business. You're ensuring that the work you believe in gets funded. You're protecting your team and your programs by being able to articulate their value.
The alternative - being "too pure" to speak business language - often ends with your team getting cut and your programs getting defunded. And then who does that serve?
Some of the most authentic, developer-focused DevRel professionals I know are also fluent in business language. They use that fluency to advocate more effectively for developers. They're bilingual, not sell-outs.
Now You're Ready for the Next Level
With the foundation of business literacy, you can now tackle the more advanced challenges:
- Developing meaningful DevRel metrics that map to business objectives
- Building attribution models that give you credit for influence without overclaiming
- Creating business cases for new DevRel initiatives
- Demonstrating ROI in ways that are credible to finance teams
- Advocating for budget and headcount using compelling business logic
These advanced topics deserve their own deep dives (and there are good resources out there on these topics). But without the foundation we've built in this series, those advanced topics don't make sense. You'd be trying to build a measurement framework without understanding what matters to the business. You'd be creating attribution models without understanding how marketing thinks about attribution. You'd be requesting budget without speaking the language of finance.
Work as Imagined vs Work as Done
There's this concept from safety science: "work as imagined" vs "work as done." Work as imagined is how things are supposed to work in theory. Work as done is the messy reality of how things actually work.
A lot of the DevRel discourse happens in "work as imagined" territory. In theory, we should just be able to show our impact through beautiful metrics. In theory, executives should just trust that DevRel is valuable. In theory, we shouldn't have to speak business language because our work should speak for itself.
But that's not work as done. In reality, we operate in companies with finite resources, competing priorities, and stakeholders who think in different frameworks. In reality, business literacy is table stakes for being taken seriously.
Focus on work as done. Learn the language. Have the conversations. Bridge the gaps.
Your Network Is Vast: DevRel as BizDev
Here's one more thing to consider: your network is one of your most valuable assets, both personally and for your company.
You know people at other companies. You have relationships in the developer community. You're connected to potential partners, customers, and advocates.
This makes you valuable in ways that go beyond traditional DevRel metrics. Want to explore a partnership with another company? You probably know someone there. Need to get into a strategic account? Your network can probably help with an introduction.
I'm not saying you should become a business development person. But I am saying that leveraging your network thoughtfully (and with appropriate boundaries) is another way DevRel creates business value.
Show Value But Set Boundaries
As you become more business-literate and better at articulating your value, you'll likely get more requests. Sales will want you on more calls. Marketing will want you to support more campaigns. Executives will want you to do more things that "require less imagination to show value."
This is where boundaries matter:
- "I'll call in a favor from my network - once."
- "I'll share company news on social media, but in my own words and only if I genuinely think it's interesting."
- "I'll meet with prospects for technical discussions, but I won't do sales demos or pitch."
- "I'll write about new features after I've used them, and I'll share my honest impression."
Your boundaries might be different. The key is being intentional about what you will and won't do. And remember: boundaries can be flexible and situational. But they should be conscious choices, not things that happen to you.
Final Thoughts
Business literacy is power. It's the power to advocate effectively. The power to protect your team. The power to fund the programs that serve developers. The power to have a seat at the strategic table.
You don't need to become a finance expert or a sales leader or a marketing strategist. But you need to understand enough about how these functions work to translate between their world and yours.
The cognitive dissonance a lot of DevRel folks feel - between "DevRel is good and pure and unsullied by capitalism" and "the company has to generate revenue and DevRel is part of that" - that dissonance is real. But it's also false tension.
You can serve developers AND contribute to business success. You can be authentic AND speak business language. You can maintain your integrity AND work effectively with sales and marketing.
In fact, you kind of have to. Because if you're not connected in a measurable way to either building the thing or selling the thing, it's going to be really hard to stick around for the encore.
Get over yourself. Learn the language. Bridge the gap. And go be awesome...together with the rest of your company.
Resources for Continued Learning
Want to deepen your business literacy? Here are some places to start:
- Take a basic business finance course (lots of free options on Coursera, edX)
- Read your company's financial statements (if public) to understand how they talk about the business
- Ask to shadow someone in sales/marketing/finance for a day
- Read business books focused on SaaS/tech companies (I recommend "Crossing the Chasm" by Geoffrey Moore as a starting point)
- Follow finance and business leaders on social media to absorb how they think
And most importantly: ask questions. The folks in sales, marketing, and finance usually love explaining their world to people who are genuinely curious.
Jeremy Meiss has written some great next step posts for you to consider:
- DevRel and the Customer Journey
- Positioning DevRel as a Resource
- Measuring the impact of Developer Relations on Revenue
What's Next For You?
So here's my question for you: what's one thing you're going to do differently based on this series?
Maybe you're going to schedule coffee with someone from your sales team to understand their pipeline better. Maybe you're going to reframe how you talk about your work in your next stakeholder meeting. Maybe you're going to actually read through your company's budget process documentation (I know, thrilling stuff).
Whatever it is, don't let this just be information you consumed. Make it actionable.
If you want to continue this conversation, I'm always available on Mastodon, LinkedIn, and BlueSky. Share your experiences, your questions, your disagreements. This is work in progress for all of us.
Thanks for sticking with this series. Now go forth and speak business fluently while never forgetting who you're really here to serve: the developers.
Build the thing. Sell the thing. But most importantly, make developers' lives better. That's the job.
Top comments (0)