How to write DevRel emails that don’t sound like marketing

The term ‘feature creep’ goes back at least as far as a Usenet recap of MacWorld Expo 1990. After a Richard Bretscheider bemoaned being blinded by “the blazing searchlights of industry,” a Paul Campbell replied, saying “Yes!! too many suits!!...fewer really wonderfully new and striking products…Everyone ends up playing ‘feature creep’ with competitors.” As true for the times of harddisks as it is for today’s tacked-on LLMs.

It’s hard to play the long game when there are so many easy wins and short-term gains available. So teams take a quick detour from the roadmap to ship a low-lift generative AI something-or-other. Then build a better version of an update a competitor just released. Eventually, it becomes what the Jargon File defined in 1999 as “a systematic tendency to load more chrome and features onto systems at the expense of whatever elegance they may have possessed when originally designed.” No less of an issue now, but increasingly overshadowed in dev communities by a different kind of creep. Marketing creep.

On a long enough timeline, everyone works for Marketing

In responses to Xe Iaso's What DevRel means to me, Hacker News commenters called it “nearly identical to marketing” and “tricking people into buying shit.” Org charts seemingly aren’t to blame, though, with a 2023 survey finding only 33% of DevRel teams reported to Marketing or Sales while 55% fell under Engineering or Product teams or the CTO.

DevRel managers are quick to double down on keeping Marketing at arms length. One former lead at DigitalOcean wrote “I'd be damned if I let anyone onto my team who was a seller…not even a whiff of it.” That’s an easy stance to take on Day 1. But it gets harder as time goes on.

Eventually, someone with revenue goals is bound to ask for evidence that DevRel is helping the bottom line. So advocates slip in a soft sell here or turn up the evangelism a smidge there, just to have something concrete to point to. Marketing joins the chat.

Other DevRel teams get off a bit easier. They never have to fend off pleas to adopt “engagement KPIs” or “conversion rate optimization.” Instead, their marketing creep might simply be attributed to being surrounded at all times by people with a vision for the best possible product. Through no fault of their own, advocates can’t help but eventually sip the Kool Aid. The longer their tenure, the higher the chance that they ignore the broader, more varied landscape of solutions that devs are interested in.

Or, in the darkest timeline, DevRel has free reign only until it’s a fat enough cow to swallowed whole by Marketing (a la Twilio updating its infamous billboard from “Ask your developer” to “Reduce acquisition costs by 65%”). More of an ambush than a creep but the same idea.

To build a DevRel program that developers love, one that they would never describe as “tricking people into buying shit,” there need to be lines in the sand. Lines that advocates never cross. Even if that means creating an openly adversarial relationship between DevRel and Marketing.

Hacking back the creep

If DevRel is a bridge between engineering/product and external devs, there needs to be more information traveling inbound than content moving outbound. Hacker News user haswell wrote “My [DevRel] job mostly consisted of acknowledging the parts of the product that sucked, and not pulling any punches when discussing options and solutions to 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.” It’s hard to imagine developers not fawning over that take on DevRel.

Showcasing community posts in developer newsletters is one way to dilute the Kool Aid. Stripe, for instance, always includes a Community subheading with at least three bullets in their monthly Developer Digests. Coda’s The Docket emails have “our version of the staff-picks shelf at your local bookstore.” Docs their team have read, loved, and then shared. Sharing community content forces internal teams to search for interesting ideas and break out of the Not Invented Here bubble.

Another way to push back on marketing creep is to make a habit out of writing about what your feature/update/API/etc cannot do. When GitHub was pushing Copilot in its April and May 2024 Insider newsletters, the latter included a bullet list of the limitations and the former was an entire issue devoted to when not to use Copilot. Similarly, Stripe’s Shipped lists almost always dedicate a section to outlining what still needs to be done on a project. These send clear signals to developers that DevRel puts clarity above conversions.

You might even want to create multiple newsletters, with some lists for editorializing and others for straightforward product announcements. Plaid lets developers opt into changelog updates and beta invites and opt out of marketing emails that include customer stories and thought leadership articles. Or you can go whole hog like DevRel darling Stytch, which as of this writing seemingly only sends feature releases and bug fix updates. Unambiguous promises to keep the Suits out of the conversation go a long way with the Hacker News crowd.

When forces outside of DevRel’s control blur the lines between developer advocacy and product advocacy, accountability partners can help (a popular arrangement among a whole other brand of evangelists. Here, an impartial person (or tool) holds the team accountable to the sales avoidance ambitions laid out on Day 1.

Accountability might start out as simple as a RegEx pattern for salesy language like “upgrade,” “register,” “only option,” or “best way.” Or a function that highlights banned URLs like sign up pages, Book a Demo forms, or gated eBooks.

Developers hate marketing so much that they might even be willing to hold their noses and use an LLM to classify preachy or promotional language in DevRel content. Anything that’s directionally similar to Gmail’s checkpoints when you don’t attach a file to an email that contains the word “attach.” A backstop that asks “Are you sure you want to say…” before you hit Send on a newsletter that might generate backlash.

One DevRel engineer at Flutter tweeted that “Developer Relations is akin to a red team or aggressor squadron, charged with upskilling an API engineering team by showing them how customer engineers actually think.” By that same logic, a human Hacker News comment might be your number one ally in defeating marketing creep. A cynical developer outside of your DevRel team. Hell, maybe even someone from your community who’s willing to Red Team your newsletters. Encourage them to call out not just “marketing bullshit” but anything that ignores worthwhile alternatives to your product.

Fewer Suits in the room

Devs have been complaining about the “blazing searchlights of industry” since 20Mb external harddisks were the most exciting hardware on the showroom floor. The fact that those lights haven’t faded is only partly due to the direct efforts of marketing.

We’re all predisposed to think that the projects and people we invest our time in are better than all the others. DevRel emails and newsletters, with their coveted keys to developer inboxes, need to be wary of letting that subtle brand of marketing creep in. Annoy developers too much and they can do far worse than boot you out of their inbox. When Adobe updated its ToS to access user content for “automated review,” the front page of Hacker News read “Cancel Adobe” with 649 upvotes (and millions of impressions on X).

Don’t put sellers on DevRel teams. Do give those teams lines in the sand. Don’t publish more to your community than you absorb from it. Do write about the limitations of what you’re working on. Don’t lump developer updates and thought leadership into the same newsletters. And do, for the love of avocados, invite outside devs to hold DevRel accountable for marketing creep.