Every dev marketing hire should write docs
Three reasons why every new developer marketing hire should write technical docs.
In a prior role I had the good fortune to join the company sponsoring the world's most popular open source rich text editor project.
At the time I didn't know a thing about WYSIWYG editors. Or for that matter much about HTML or CSS. I remember instantiating the editor for the first time and thinking, "wow, this is magic." The a-ha moment as marketers like to say. In truth, I still feel that way.
Yet within 3 months of start I had a better grasp of the product and the product's value to market than any of the non-engineering staff. Without exception. How did I do it? By writing developer documentation.
How writing docs expedites onboarding
The benefits of writing docs – or doing a similar technical task – are numerous for both employee and company.
- Your new hire will get up to speed with the core technical product extremely quickly.
- She will need to play around with the product to confirm that what she wrote actually works, obtaining hands-on experience in the process.
- She will encounter issues or have questions requiring a conversation with the engineering or product teams. Not many people don't want to help a new hire (perhaps except in toxic work cultures). It can literally break down silos before they begin.
This is especially true for product marketers. You must understand your customer's needs intimately. You must also deeply understand the product's technical features and benefits to create revenue generating value proposition.
The onboarding benefits of getting new hires to write docs, technical whitepapers, etc, are numerous. Increased execution speed, product familiarity, and cross-department team engagement are only three of the benefits.
When hiring developer marketing roles, consider including technical writing tasks in the onboarding. I am certain it accelerated my technical understanding of the product and my overall value to the project.
I wrote all general reference docs except the API documentation (which was the domain of the engineering team) for the open source TinyMCE editor.