In the recent months, I have been working with @calebhailey.com to develop a new kind of workflow for posting to the Internet. Traditional social media has problems with content ownership, but what they get right is the user experience.

It is trivial to open up Twitter or Instagram or Facebook or LinkedIn or any number of other sites using their mobile app and make a quick post hit send and have it go live on a public facing feed somewhere on the Internet that other people can see.

Doing something this basic is unfortunately quite difficult if you own your own website and domain. Caleb and I think that’s a problem, and that you should be able to post to your own website as easily as you post to Twitter or Instagram.

Key Words and Phrases: documentation, knowledge sharing, engineering culture, technical writing, user experience (UX), product culture

Background

For those of you familiar with my community and professional work—as a co-founder and organizer of the Write The Docs conference (2013-2015), as an outspoken advocate for documentation, and as the Technical Lead (TL) of Twitter's internal TechDocs team (2014-current)—this publication may come as a surprise. It is precisely these professional experiences which have led me to the understanding that I have today: that documentation may in fact be more harmful than it is helpful.

Further Discussion

While writing these articles, I asked my coworker Greg Poulos (@gregpoo) to take a pass at proofreading/editing. He had some good feedback and questions, which I thought I should tack onto the end of this series of posts.

NOTE: This is the third article of a three-part series. The first part discusses strategy while the second part explains how to grow a TechDocs team.

How to Grow a TechDocs Team

Getting a handle on technical documentation is an essential part of any software project, yet this fact seems to get forgotten by most companies during their staffing discussions. Rarely does a tech startup co-founder think to hire a technical writer as part of their initial engineering team. Many companies do not even have a single dedicated person on documentation. So, let's start there.

NOTE: This is the second article of a three-part series. The first part discusses strategy while the third part wraps up with some more in depth discussion.

In companies that have large engineering teams, a dedicated technical documentation organization is a necessary function. Our industry's understanding of the role of documentation, both as engineers and technical writers, has shifted its focus over the last decade.

- Troy Howard, Contemporary TechDocs

Yeah, I just quoted myself. That's the least of my worries. My bigger concern is the incredible pile of work awaiting me every time I open my laptop. I long for the day when I finally get approval from upper management for the headcount to hire another documentarian. We could do so much more with just one or two more people.

My boss sometimes asks* me, "I'm not sure if we can get headcount, but it would help if you could tell me exactly what you'd do with more people."

** note to my pedantic readers, I realize that was a statement, not a question, but this is Manager Speak™, not normal English.*

I suspect that many of my peers in the tech-comm world are in a similar situation. This series of articles intends to answer that once and for all. First, I'll describe the strategy that enables this kind of scaling, and then give some suggestions on how to grow a TechDocs team from your first documentarian to your hundredth. Finally, I'll discuss some deeper aspects of our experience trying to implement this at Twitter.