Author’s Note: What follows is Part 5 of a (currently) 5 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.
| Moving Developer Relations Forward (5 Part Series): |
|---|
As we continue in this series, another benefit that DevRel offers is that, as its general definition states, building relationships with Developers is what it’s all about. That means that within your company, you should not be hesitant to be seen as a resource, and even a partner (!!!), to Sales, Marketing, Product, and even Recruiting!
Drawing back from the earlier notes on DRQLs, DevRel has enormous potential within your company because of its close proximity to your target audience: Developers (or Practitioners, Users, etc.). You are their voice back to the company, but you’re also the voice from the company back to them. This ideally positions you to continuously demonstrate your value. Here are some of the ways I have driven this, and seen it played out.
Revenue collaboration
Multiple orgs within the company are pushing the need for “upsell” and “land and expand”, two initiatives which mean essentially the same thing: Grow usage of the Product within a company by selling new services, or getting more people (and teams) within a company to start using the Product. DevRel can be a resource to help these teams get either renewal deals across the line, or to grow usage within the customer, maybe around new or advanced features that the customer isn’t using yet. This can be done in a number of ways, but a couple of the more significant ways are:
- Workshops at the customer for their technical teams to learn about the new feature(s), or to make new teams aware of the Product.
- Webinars, presentations, seminars, etc. that can be repurposed via campaigns to customers around new concepts and features to grow the awareness of the Product with those who can influence the usage.
Marketing collaboration
Marketing wants to grow the awareness of the Product, and is looking for new ways to show how developers can be using it in their normal workflow. The DevRel team can be a great resource to help in some of the following ways:
- Help source case studies, as previously mentioned, from developers in the Community. This is a great way for a Champion program, or a group of highly active community members, to get involved and raise their profile in the community, inside your company, and even within their own job.
- Provide Marketing teams with the different tools that developers use your Product with, and make connections through your network to that other company to do some co-marketing activities. Some of them could be webinars, live-streams, workshops at conferences, meetups, blog posts, etc.
These are just some of the bigger examples of how you can be a resource to other teams in your Company. Let your creativity fly, and see what you come up with! This is another example of how the question-asking exercise comes into play, helping you understand what other organizations have a need for.
“But Jeremy, DevRel isn’t Sales/Marketing!”
I hear this retort/excuse as to why a DevRel team shouldn’t be doing these sorts of things all of the time. It’s usually followed up with:
”Developers don’t like Sales/Marketing, and now you’re telling me that we need to be doing Sales/Marketing things!?!”
Well, Yes. Also, No.
It is a common (and basically true) statement. Traditional marketing is all about the “shots on goal” concept, where you want to get as many views/leads as possible to get your message to them with the hope of getting 2%-5% conversion. If your DevRel team is constantly out there trying to get the 500 scans at a conference; or calling up developers and pitching them to switch from a competitor; or even does a conference talk where it’s a pitch about your Product instead of talking about a concept or principle that would make the audience want to have a conversation, etc. you’re going to be seen as a shill and you’re not going to build the necessary trust. That’s not going to make for a very successful DevRel program.
But yet, devs respond to “marketing” all of the time! It’s all in how the DevRel team builds that relationship, builds that trust. Giving a conference talk about a DevOps concept or principle that aligns with what your Product does, while having your company logo on the slide, and being introduced with where you work, and maybe even mentioning at the end, “I would be glad to chat with you about what my company does, or to learn more about this concept I’ve just shared”, all are ways that build trust while still making people aware of your company. Oh, and also being truthful about what your product can/can’t do when they ask. Don’t force them to use it with wild claims that won’t be backed up, or that they’re not going to use, when another product might actually be better for them in the stage they’re in. Believe me, they will remember. And they will come calling when they need something that better fits what your company does.
So here’s the rub. In business you’re either making the thing, or selling the thing. Whichever one you are, your objectives need to line up accordingly. If they don’t, you’ll be out of a job. DevRel teams must always balance the needs of the customer and the needs of the business. If customers (devs) don’t end up using your product you’ll be out of a job. That’s basic economics.
And I’ll say this now: DevRel as a profession needs to grow the fuck up and recognize that it’s not a bad thing to participate in the marketing/sales process. You can do so and still keep the trust with devs.
##In closing… for now
The point with all of this, is that DevRel needs to wake up and recognize that it must show its value to the Business, and in as many areas as possible, in order to stay ahead of the dreaded “what do you do?” and “what’s the ROI?” questions. Any attempt by DevRel to distance itself from areas of the Business will ultimately result in the Business distancing itself from that DevRel team.
I will continue to add more to this, and likely break it up into an easily consumable series soon. In the meantime, please comment below, or reach out on my socials, to chat more.
And if your company, or even your DevRel team, is in need of some help around these things, let’s chat.
You can find me at:
| Moving Developer Relations Forward (5 Part Series): |
|---|
Cover photo by Vlad Hilitanu on Unsplash