Published on 10/24/2023
In the last few years, I've managed to pivot my career from being a software developer towards the wild world of Developer Relations (DevRel). During this period of transition, I've been doing a lot of thinking about what DevRel really means to me and I think I've got something that I can put into words.
What is DevRel?
DevRel is a very multi-faceted role. It varies a lot depending on the company, but usually focuses around two basic things:
- Advocating for the company's products and technologies
- Building and fostering a community around that product or technology
At some level, it's very easy to see DevRel as a spicy marketing effort targeting a historically untargetable demographic. In some ways, it is, but it's also a lot more than that. It's a lot closer to figuring out how to make developers' lives easier. It's a lot closer to "customer success" than it is to marketing.
DevRel is not a sales role. It's not a marketing role. It's not even a support role. At its heart, when you are DevRel, you are the bridge between the company and the community of developers that may or may not use the company's products.
You're the one that people ask questions to, and also the one that knows who to send those questions to when you don't know the answer. You're the one that knows not only what the product does, but what people can really do with it when they take off the safety wheels and go ham with it. You know the way the product works, and the way the product breaks. And most of all you're able to talk with developers in their native language without all of the synergy of sales or the conversion ratios of marketing.
Why DevRel?
DevRel exists because marketing has failed developers. Developers are in a completely different class of people than marketing usually targets. They're a lot closer to a producer-consumer than anything.
Historically, there's been three basic classes of how people interact with the economy: the producers, the consumers, and the government. Producers are the ones that make things, consumers are the ones that consume things, and the government is the one that makes sure that the producers aren't lying to the consumers and that the consumers aren't lying to the producers.
Normally, a producer will make a good such as a car and then advertise the fact that the car exists to consumers. The government will set standards for how the car should respond to collisions, how much fuel it should use, and how much pollution it should emit. The government gives the producer a sticker that says that the car meets these standards, and the producer puts the sticker on the car. The consumer then buys the car and drives it around.
Assuming spherical cows, everything works out in this system. However, our cows are not spherical, we have air resistance to worry about, and developers simply do not fit into this worldview.
Developers are both producers and consumers. They produce projects that build on top of countless other projects and combine into even more resulting products. Developers know enough about observable fact to know when a statement is misleading. In our world, marketing is all about misleading people in just the right way that they don't aggrivate the government, but still entice people into buying their products.
Developers know when they are being lied to. They also use ad blockers, tracking blockers, deny the use of client-side JavaScript, and generally trust very few statements out of marketing departments. At some level, the developers are in the right here, marketing has failed them because they are not the target demographic; yet they are the ones that are making the purchasing decisions.
This is where DevRel comes in. DevRel bridges this gap between communities and corporate entities. It's a lot of the same fundamental work as marketing, but with a completely different approach. Where marketing focuses on the cloak and dagger, DevRel focuses on the "show, don't tell" approach.
Besides, you can't really tell people anything. You can only show them. You can go on and on about how the Go programming language makes it easy to write concurrent programs, but until you show them how to do it, they won't believe you.
You can tell people statements, not knowledge. Knowledge must be experienced to be understood.
Imagine the impact of using a product to host a HTTP server to the public internet on conference Wi-Fi vs just saying "oh, you can use this product to host websites to the public internet". The difference is staggering and instantly noticeable. This is the power of DevRel.
In the process, you build up trust between the community and the company. It's a lot easier to trust individuals rather than corporations, and DevRel offers those individuals to get to know and trust. This is why DevRel is so important.
The dark side
At some level though, DevRel is very easy to mess up. At some level, you are playing with fire constantly. In the cosmic game of Among Us, you are always the imposter when you enter a community as a developer advocate. Even if you aren't trying to sell something, people will see you as if you are.
This is why it's so important to be genuine and honest when doing DevRel. If you don't; they'll know to ignore you and then your attempts are utterly futile. If you do, then you can build up trust and a community that will last for years.
In the process of advocating to individuals as an individual, it's easy for your own popularity to apex that of the company's. At some level, this means you are doing your job correctly, but it can also be a bad thing depending on the company. Some companies will see this as an abuse of position or power, and will try to reign you in. Others will see this as a good thing and will try to encourage you to do more.
Oh, and if you work at a company that is doing shady things (even if you are wholly unaware of them), you're also the one that will get the brunt of the backlash as a developer advocate.
The way I do DevRel
Sometimes it's easy to want to use DevRel as a vehicle to make people or companies look "invincible" or as "rockstar" developers. I don't like these thoughts because at some level it's a fundamentally incorrect way to view things. The standard way to interpret "rockstar developer" is as a one-man show saving people from their own incompetence. This is not a good way to view things. This ignores the stage manager, the drummer keeping tempo, the bass guitarist keeping the rhythm, and the lead guitarist building the hype. It ignores the sound engineer, the security team, and everything else involved in the logistics of making a concert happen.
I'm not a "guru" or a "rockstar" or even a "10x" developer. I view myself as a developer that likes to find new and interesting ways to do things and then transmute my experiences in ways that inspire others to do the same.
If anything, I'm probably closer to a professional nerd sniper or an artist than a "rockstar", "thought leader", or "guru". I just want to find new ways to do things using the lessons I've learned doing it the ways that things have "always been done".
In the process, I want to uplift others to my level so that I can create more senior developers to help end the "talent shortage". I want to help people find their own ways to do things and then share them with the world. I want to help people find their own voices and then amplify them.
Some people call the work of DevRel "evangelism". I really hate this term, but this may be because of my history in organized religion. I don't like the idea of DevRel being a preacher that proclaims the values of a product on the mountaintop, I want to be the one that meets people where they are at and helps them find their own way to do things.
I also don't really want to be associated with sales, there are people dedicated to that. I can refer people to sales and then give sales all the context they need. I just want to help people find their own way to do things. If any sales happen because of that, it's an added bonus.
So really, a lot of the DevRel activity I do will boil down to talking with developers where they are (I'm a developer myself, so I know where they gather) and finding out what their problems really are. Then when I have some patterns I try to find ways to solve them and write about it. This in turn inspires people to write about their own solutions, and the cycle continues.
The asymptote
The most frustrating part about my way of doing DevRel is that it doesn't have direct association between actions and results. It is a very slow process at first because frankly community building is hard. There's a lot of moving parts and ways things can go wrong. When they do go wrong, they go wrong in very public and spectacular ways.
However, when things go right, they go really right. As you build up trust and the foundations of a community, then you can start to observe (but not count) the results of the work. Your community will start answering questions other people ask, and then those answers will go from merely tersely correct to actually helpful things that transform the way you understand the product. People build tools on top of the product and share them with the community. Your product doesn't just become accepted, it becomes a viral idea. It goes from the early adopters to the pragmatists to the obvious choice.
Then you hit an inflection point and things don't just start to grow, things start to soar. This brings its own host of problems, and all of them are markers of success. Things go from sub-linear to linear to superlinear to exponential to geometric and finally asymptotic.
This is the real power of DevRel, and the most frustrating part is that it's impossible to know when that inflection point will happen. There is no prometheus metric that can measure trust and hype. There is no way to know when you've hit the inflection point until you've already passed it and things you've done months ago are just now starting to pay off.
This is why DevRel is so hard to do. It's a lot of work for very little return at first, but then it starts to pay off in ways that are impossible to measure. It's a lot of work to build up trust, but once you have it, it's a lot easier to maintain than it is to build from scratch.
Conclusion
This is my vision of DevRel as an institute. Now let's see what I can do with it.
Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.
Tags: devrel
