What DevRel means to me | Hacker News Reader

What DevRel means to me

christine.website

72 pointssea-gold18 comments

Author of the article here. Surprised to see this one landing on Hacker News instead of the short story I wrote last night (https://xeiaso.net/blog/2024/the-layoff/).

I wrote this to summarize a conversation I had with the CEO of the company I now work for while I was getting hired there. Apparently it had the effect I want, because I now work there doing devrel.

Excellent! Nice work!

> Even if you aren't trying to sell something, people will see you as if you are.

But…you are. Earlier in the article it even claims one of the two main roles is to advocate on behalf of the company.

In the end, I think it all boils down to what the company measures DevRel on. Sign ups, GitHub Stars, and leads are all marketing metrics. Renewals and satisfaction are success metrics. Revenue makes you sales.

That was an interesting read, thank you for sharing your perspective somewhat transparently.

I wonder how other industries with "producers" handle these kind of marketing efforts. How do you advertise/ market to a mechanic or farmer? I see some on YouTube but that obviously can't be everything.

It kinda gets a bit door-to-door sales-ish-esq in those industries. Trade shows, publishing reports driving out to the farm and hand delivering them, shaking hands with the farmers. If you distill this article down to 1 tenant, its sales isn't sales, it's relationship building. I built devrel team at DigitalOcean when it started, and I'd be damned if I let anyone onto my team who was a seller. When I hired Mikeal Rogers I said something along the lines of: "You go make the js community happy, do whatever will help them grow, tell them what we're doing, ask them what they need, and spend your budget on helping them" - he crushed it, one of the best people I've ever hired in my career, never sold once, not even a whiff of it. I almost lost my job every quarter running things how I did... till the day I didn't, and that was the day I got promoted. Most people are scared to do community building the right way, but when you do, it works extremely well.

I enjoy community building as well and it’s why I organize the python Atlanta (pyATL) group. It is all about the community but also the individual. Having the goal of getting to know each person and working to align what we offer with what they want. People mostly want a place to belong and grow. Where they feel nurtured and supported. Without the pressure of constantly having to buy shit. When you put people first great things happen.

I think this person's role is directly comparable to the traditional "applications engineer" at chip companies who sell to electrical engineers. It is really exactly like this where apps engineers are both technical support and marketing at the same time. Maybe less conference talks and more webinars.

Great write-up, your take on honesty is very accurate. I appreciate a member of a community who is well-intentioned, and transparent about any biases they're bringing in. I write a lot about my devtool, but I try to be transparent that I work on it, and also try to share learnings beyond just what I build.

I feel like this article suffers a bit from a lack of perspective. The way DevRel works is nearly identical to marketing in other sectors where the consumer is sophisticated and technical.

For example, scientific instruments companies also sponsor technical innovation, they also have scientists in marketing / education roles going to conferences, etc. If you are selling NMR instruments for 10 M$ each, you also invest in good relations with the community, because you want the person who has just received a massive grant to think of you and your great work and call your sales dept. You aren't going to get anywhere cold-calling random academics who mostly aren't in the market for a NMR right now.

I don’t get the impression that Christine is saying software DevRel is the only role that looks like this — just that standard “consumer” marketing tactics don’t really work on developers.

I wouldn’t say it’s necessarily based in a “lack of perspective”, but perhaps more just choosing to not expand the thesis to encompass the broader world of technical marketing in non-software industries. I think that’s fair, given that the author’s experience is centered on the software world, and not every blog post needs to begin with a cross-disciplinary literature review.

yeah, while reading it what popped into my head is that people just love to label things to help them feel different.

what they're doing is marketing.

The pretense that their role doesn't exist because of the sales pipeline they generate is slightly crazy.

DevRel are in sales and marketing.

Are engineers writing code for the core product in sales and marketing? What about product management?

Many non-sales/non-marketing roles primarily exist for the purpose of generating or enabling the generation of a sales pipeline. This doesn’t make them automatically equivalent to marketing and sales roles. One look at “a day in the life of” across these functions shows that they’re quite different.

> 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.

Fancy words for: "tricking people into buying shit"

A lot of the comments here are dismissing DevRel as just "marketing", or "tricking people" or "they just exist to sell stuff". And I think these comments are missing the point.

While DevRel may include aspects of marketing, and it may indeed result in more sales, it's an oversimplification to classify it as such.

Twilio was a pioneer in this category, and one way they framed this was: "Good API documentation is marketing for developers". Good API documentation is a good thing. A good DevRel team (among many other things) makes sure documentation is rock solid, and does everything they can to make it easier for developers to onboard and succeed.

Contrast this against pure marketing approaches that are more focused on attracting attention from the C-suite and leave devs to pick up the pieces and determine what's actually real/possible. Pure marketing is often hard to distinguish from bullshit and sells stories and aspirational outcomes. DevRel "marketing" is about making sure the people implementing the tech are able to successfully do so with what is actually real and possible in the product.

While it's true that the role may exist for the purpose of selling more product, it's also true that the output of a good DevRel program involves real value to everyone involved. If you're a developer who needs to work with the product, the fact that you're more likely to prefer <Product with a good DevRel program> over <Other Service> is based on the fact that the product is just better. And it's better because they pay attention to the things that matter to developers, and a developer-focused product that doesn't pay attention to developers is worse than one that does.

Pure marketing benefits the company trying to make money and often papers over reality. DevRel focuses on ensuring actual success, which is a meaningfully different approach and outcome to a typical product marketing team. Good DevRel often reports to the engineering org, and may be at odds with the things that marketing says.

Disclaimer: during a career mostly spent writing software, I spent a year or so in a DevRel role. My job mostly consisted of acknowledging the parts of the product that sucked, and not pulling any punches when discussing options and solutions to problems. Over time, I came to see the role as a kind of liaison between engineering, customer developers, and marketing/sales. The #1 goal of the role is to establish developer trust. And establishing trust means telling the truth, and trying to solve real problems. I was often the one telling marketing to stop the bullshit, because it made everyone else's jobs (including our customer's) much harder.

> Over time, I came to see the role as a kind of liaison between engineering, customer developers, and marketing/sales.

This is my experience as well. DevRel folks are the voice of the developer inside the organization's product, engineering, marketing, and GTM groups, and their success is aligned with their developers' success with the product.

I feel like you're doing a bit of "othering" on marketing and sales. As https://news.ycombinator.com/item?id=39396436 puts it, this is common outside software (you'll find hardware purchases are similar), and is all about being the preferred vendor of choice (for both current and future purchases). That maybe it doesn't exactly match the archetype people think of as sales, I suspect there's a lot of lessons in looking at adjacent fields to see what they do.

I don't understand the "othering" comment. My point was that within software, DevRel generally serves a very different purpose and function than marketing or sales, and that comments equating DevRel to "just sales/marketing" are missing the clear distinctions between these functions.

It's interesting if marketing in other industries covers some of the functions that DevRel addresses in software. But that says more about how different industries divide functions across departments, and to me that underscores the DevRel vs. marketing/sales distinction in the context of software.

If you're a one person shop, you're doing all of the above.

I also don't agree that the examples provide are analogous to software or software sales. Scientists courting scientists and making sure their company is visible enough to be thought about is really not at all like what the Dev Advocate does. I understand the temptation to compare them, but beyond the vague notions of visibility and preferred status, the analogy breaks down pretty quickly.

Showing up at conferences or meetups and running hackathons does provide visibility, but in a large number of cases, DevRel is there to serve the existing customer base and to ensure their success. This can also be a positive signal for prospective customers, which is one of the reasons such programs are considered valuable.

Reply on news.ycombinator.com