Amidst interviewing for my next developer relations gig I kept asking “What does all this mean to me?" It wasn’t until early in 2020 that I got the answer to this. I was at a launch party for a product and someone clearly in finance asked me what I do. Developer Relations felt too vague and like vomit out of a baby awkwardly I said “I do growth for SaaS startups”. That night was over, thankfully! A few days later I found myself on a quick call with Kelsey Hightower. He does these amazing office hours now and then. During our chat, we went deep into modern software development, tooling and how developer relations ties into everything. As with almost every conversation around developer relations, metrics came up and I was left with so much to think about. This article is a result of that conversation.
I won't lie, even though I was doing so much community work before getting into developer relations. For the most part it only looked appealing to me because everyone made it seem like I would be traveling and speaking all the time. Spoiler alert, most of the time I wasn’t and you probably won’t either. The most people facing of our kind are obviously noticed and it reinforces the idea that really, that is all there is to developer relations. These two tweets sum it up.
I write this because I feel like so many people new to the field, particularly younger, less experienced folk feel they’ll travel the globe and go stage-to-stage - sharing your experiences with the masses or writing killer articles one after the other (I know I did). When I talk to hiring managers for DevRel positions, they all see promising candidates concentrate on a very small part of the job. According to them, that is usually a red flag. So many miss some of the finer more process oriented parts of the job. Funny enough, these have become my favorite part of it all. I was curious to know what effect my activities as a developer relations professional had on the companies I worked for. My professional experience started off with a part-time role at Hasura before shifting into a full-time role at PubNub and eventually into full-time consulting which I do at the moment. I wouldn’t have a short answer for you if you asked me what a day in any of these roles looks like, hopefully you get that out of what I have to say next. My modest and somewhat broad DevRel experience has brought out three key words for me.
Awareness | Adoption | Revenue
Remember when I said I do growth for startups? Bet…
Nothing drives growth like a good and well refined product that people actually want. Getting there however is another story. I think this is where DevRel shines. Done right, collaboration with multiple departments, the ability to advocate for both the community (sometimes customers) and the company creates some of the best products and communities. Most times, if not all - a welcoming and inclusive community is all it takes to put you ahead of the pack. How? Every internet entrepreneur shouts out “Don’t sell a product, sell a solution.” As ubiquitous as that phrase has become it does hold some truth. Now I have to point out that DevRel isn’t all about driving sales. If we’re honest with ourselves, we know that we work for companies that need to make payroll somehow. You can’t run on VC money forever. I’m not telling you to start selling to your open source community - please don’t. More often than not, DevRel does help drive the growth of some sort of metric that is important for the company. If it doesn’t then you might have a problem. Where am I going with this? DevRel gives you the unique ability to refine your product while growing a community of people who will/want to actually use it. How?
Three syllables - stra-te-gy
When coming up with a team strategy, it is important to get a good idea of what stage your products are at. Keeping in mind different products can be in different stages and you will have to tweak your actions to suit them. While also remembering that in everything you do, you must have your communities best interests at heart. Back to those three stages i.e Awareness, Adoption, Revenue Generation. From my experience companies want to drive at least one of these in one way or another.
Awareness is getting people to know about you exist
Adoption is getting people to actually use your product
Revenue Generation is getting your product to make money
Before getting deeper into each and the the actions associated or that represent them. I think it is worth mentioning that the core of developer relations are advocacy and community enablement. Advocacy means you might have to work with a few departments here and there. Departments like marketing, product and yes sometimes sales. The aim here of course being to advocate for your community inside various departments and to do the same for your company and some teams to your community. Community enablement is at least in my opinion, best achieved with some sort of community management. An efficient feedback loop between your community and company better serves the needs of your community. More importantly, it also drives product refinement. I find applying various principles of community management necessary.
To me, initially awareness & adoption sounded very similar. Luckily for me the difference became more apparent as I got deeper into both. Taking a step back, my experience with the different stages of DevRel made me realize that each requires a different skill-set & a different approach.
In awareness we’re trying to get people to know about the company, the product, we’re doing things like event sponsorship, stickers, t-shirts, conference talks, banners, blog posts and the whole lot. The concept of developer personas was a little confusing for me. Driving adoption of a product helped me realize what events make sense in terms of content and approach. I had to adjust for different types of developers and ecosystems whilst trying not to get caught in the ROI trap. I developed my own writing style, built processes around my activities - fun times. I definitely think if you have the resources, keeping these things in mind can really help you get a candidate the speaks to your strategy and what your team or company are trying to achieve. This helped me discover a tonne of cool developer spaces and ecosystems and understand how the dynamics of each are different.
For me, simply put - adoption sees you try and get more developers using your product. This might be getting developers moving from just trying it out to possibly using it in production. Sometimes it might even be trying to find out why people aren’t using your product a certain way & working towards fixing that. In my experience, when driving adoption, people are aware of your product or tool but aren’t really captivated by it. At this stage it makes more sense to add nuance into how you approach content and engagement. I started to do much smaller and more personal meetups/user groups and webinars. If you’re at adoption, your community must have grown quite a bit. Lurking around Slack or StackOverflow answering questions becomes your life. How-to guides, documentation refinement and detailed tutorials make perfect sense for this stage, it's the small things that matter. I loved my experience with driving adoption, I think it was extremely important. It was here that I really started to get feedback to drive product refinement and in hindsight, company growth. I noticed how I grew and became more empathetic to pain points developers face. Trying out non-traditional means of content creation was also very rewarding.
Revenue - when they say DevRel takes time, they mean it. Not to say that revenue is the endgame for everyone, it is for most. People need to be aware, before they can adopt and you can refine, then you can sell. Driving revenue is a little different for different companies. It depends on how they’re getting this revenue. I like to ask things like this because if it’s my job to do it, I must be in the know. Does revenue come from a subscription? Enterprise users? Support? When you know this then you can build a strategy around it. Sometimes it requires less flashy actions & more deliberate actions to even engage individually with specific customers or users. It can be tricky talking about money, pricing and payment plans. Luckily I’ve never had to but nonetheless it is information you must know - thus the revenue question.
I choose to see my experiences with each stage, adjusting to the activities and getting new skills as me growing professionally. The DevRel career path is still being paved. For me doing things like growing and engaging different communities, discovering different ways to look at and approach various customer problems, and reporting to execs all look like things that leave some very nice career doors open for me. So now that you see that developer relations isn’t all talks and stickers, here is what I take it to be.
Awareness is getting eyes and attention. You usually see people work more with the marketing team. Ideally I'd call them evangelists. Adoption is getting users and improving retention. You usually see people work more with the product or developer experience team. Ideally I'd call them advocates Revenue is getting sales, ensuring developer happiness and reducing churn. You see such a person work a little more closely with sales or customer success. Ideally I would call them solutions or happiness engineers.
When you consider these, you don’t really care about the title you have. What matters is getting where you need to go and how you get there. Of course making sure your community is at the core of those plans. That is DevRel to me...
Do say hello on Twitter if you want to keep the discussion going or contact/hire me. I’m more than happy to engage. Stay safe and take care.
Top comments (0)