In small companies, or even in large companies when I’m allocated to a small number of engineers (like 10-20), my role has involved writing most of the documentation for a project. But at my current company, there are many more engineers, with more specializations and diverse product needs.
Additionally, sometimes the content is more technical than I can author myself. For example, to publish an in-depth tutorial in using the audio APIs in Android as they relate to streaming media apps, complete with code samples an even sample apps, I really need the expertise of an engineer who intimately knows the APIs, best practices, and Android code as gathered from real-life experience developing apps.
While I could ramp up on this tech and author the content, it would take me a while. It’s easier to get the media-focused engineer to contribute this knowledge, which I then edit, attempt to test (if possible), and then publish.
In a way, duplicating the engineer’s deep technical knowledge is somewhat inefficient, because now multiple people possess similar knowledge, while other knowledge areas get neglected. For example, the documentation toolset and workflow could potentially suffer. Same with the documentation’s information architecture, search, and discoverability.
If I don’t specialize my knowledge in the product’s tech, how should I focus my knowledge building and time as a technical writer? What value would I bring to the table as a technical writer without deep technical knowledge of the product? Here are a few value areas outside of the deep technical knowledge:
I can do all of the above, but often I don’t simply because I’m focused on creating yet another new documentation article or topic by somewhat replicating the engineer’s technical knowledge (a portion of it anyway). Writing is hard work, and I can easily spend the full day just creating one new doc article.
Rather than burying my head in the technical details of Android APIs and how to build streaming media apps, I might instead spend more time becoming an expert in areas such as the following:
Which is the better approach?
Although it’s easy to say that tech writers should be technical SMEs and doc ninjas at the same time, in reality one has only so much time.
I can’t be a specialist in everything. If I want to build up my Android knowledge, it means doing a worse job with some of the above doc tasks. Conversely, if I spend time digging into doc metrics, information architecture, and search optimization, it means spending less time building my deep technical knowledge (such as with Android and Java).
I do think it’s important to have a basic knowledge of the technical foundation of the product, including familiarity with the right terms and basic functions. But my knowledge is always going to be superficial compared to an engineer’s.
Should I therefore focus my time developing expertise in the unique features of my tech writer role as listed in the points above? Engineers can supply the deep technical knowledge, but they seem to fall short doing all the other documentation functions. Am I being inefficient by trying to write when I should really just pull this information from engineers in the first place?
On the other hand, without deep technical knowledge, it’s almost impossible to write coherently and intelligently about the product.
Many of the doc infrastructure tools, once in place, can fit seamlessly and invisibly into the background. It’s this deeper technical knowledge that empowers me as a writer to shape the actual content in meaningful ways. Content development is surely one of the most important aspects of documentation, because users care primarily about content.
Overall, it can be overwhelming to consider all the types of knowledge a tech writer needs to be successful.
I only have about 2 hrs a day max to soak in new technical knowledge. Sometimes it’s more important to be an expert in the doc/publishing tools and workflows, while other times it’s important to have deeper technical knowledge, and other times it’s important to build up knowledge of users and their interactions.
The problem is that by spreading my time in so many different directions, I dilute my expertise and become a generalist, with a little knowledge of lots of different things.
Being a generalist might be the defining characteristic of technical writing. I often want to be a specialist, but specializing usually entails blocking out other areas that also need my attention.
This dilemma over being a generalist versus a specialist seems to be a recurring theme in my tech writing career that I’ve never been able to resolve.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.