3 ms·

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 mi

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.

CharlesW 3y ago
> 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.
aragilar 3y ago
I feel like you're doing a bit of "othering" on marketing and sales. As https://news.ycombinator.com/item?id=39396436 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.
- haswell 3y ago
  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.

CharlesW 3y ago

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

aragilar 3y ago

I feel like you're doing a bit of "othering" on marketing and sales. As https://news.ycombinator.com/item?id=39396436 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.

haswell 3y ago
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.