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.<p>While DevRel may include aspects of marketing, and it may indeed result in more sales, it's an oversimplification to classify it as such.<p>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.<p>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.<p>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.<p>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.<p>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.