I've been a technical writer for 9 years. The last 6 were on Google's Web DevRel team. First off, the title: > Nerds don't respond to marketing; try technical

I've been a technical writer for 9 years. The last 6 were on Google's Web DevRel team. First off, the title: > Nerds don't respond to marketing; try technical documentation I read the full article and I understand what they're getting at. But I know from firsthand experience that some sales and business-side people will see that title and think to themselves "oh, we should put more marketing content within the technical docs site". The goal of the technical docs is to help your users understand your important concepts and get tasks done as quickly and efficiently as possible. Sales and marketing content can quickly interfere with that goal because they are essentially non-actionable statements and therefore create more words to sift through just to find what you actually need. For example, in my docs I don't even allow subjective phrases like "powerful new feature X". I have no idea what you consider "powerful"! > Developer relations professionals are called "tech advocates," "tech community managers," and "technical ambassadors," but their part is essentially the same - to bring software developers through a sales funnel. This is a weird way to look at it but I don't disagree. One key thing it's missing however is the feedback element of DevRel. As technical writers or developer advocates we are usually much closer to your technical users (the external engineers who are building stuff with your API) than your engineers or product team. We try out your APIs and we monitor/interact on Stack Overflow or support forums to find out where your technical users are getting stuck. Sometimes that feedback work results in new documentation or videos. But often we just do a lot of advocating behind the scenes that your product and engineering teams need to prioritize fixing X so we can avoid the need for any new docs or videos. Effective DevRel is constantly trying to put itself out of business by making the product so good that docs and videos aren't even needed. > So when a software engineer stumbles across clear documentation - they are usually pleased and often go to places like Twitter and forums to express their delight. I wouldn't bank on this strategy too much. I was the only TW for Chrome DevTools for a few years. I'm pretty sure that I got the docs to a very solid place for a couple years. I would get thank yous on Twitter, sure. But given the scale of that product (something like 30M MAUs) the ratio of people who would go to Twitter to "express delight" versus the overall user base was probably far below 1%. The only one that has achieved this on a major scale is Stripe. And I'm not even convinced it's solely the docs and videos themselves. I think the slick UI of their technical docs is a non-trivial factor. The market that the product serves might be a huge factor too as to how much your technical users talk about it (e.g. Chrome DevTools was perceived as a sort of "public good" or commons whereas Stripe is solving a much more specific business need). > Ensure that your marketing team has access to developer documentation Absolutely agree that it's useful to get different perspectives on the doc. However, it should be clear from the get-go that the marketing team is a C role (in terms of RACI chart [1]). Your docs team should seriously consider the feedback from the marketing team but the marketing team does not have overriding authority to change the docs. You will quickly and completely demoralize your technical writing team if they no longer have agency over their baby, the technical documentation. > Figure out which part of the sales funnel the documentation is nurturing (TOFU, MOFU, BOFU) I like this framing and have not seen it described in these terms. See also Divio's documentation system. It's another way to think about the need for different types of docs. > Measure the impact of the documentation that you are publishing Measuring documentation impact is a hard problem. For example, pageviews. Does your top viewed page have so many views because it's your most popular feature or because it's a horrifically broken feature? Or maybe there's just a link in your UI to that doc? (You can usually figure out which of the 3 it is, but the point is that you need to be careful with the data). One of my favorite techniques for measuring impact is to monitor support forums, detect a frequently recurring problem, write a doc on it, notify the support team, and then watch the support team just link to the doc in subsequent responses, rather than create an ad hoc answer over and over. No comments about #4 (solicit feedback from QA) and #5 (give content a goal). Solid advice. [1] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix#Key_responsibility_roles_in_RACI_model https://en.wikipedia.org/wiki/Responsibility_assignment_matr... [2] https://documentation.divio.com/ https://documentation.divio.com/