Adding Value as a Technical Writer

Tom Johnson recently reflected on the tension between increasing technical expertise and focusing on other aspects of technical communications, such as the tools and processes around writing and publishing.

Another Frame: Adding Value

In part I found his post intriguing because it has to do with constraints. There’s never enough time for everything. We have to choose. But then something gets neglected. Or at least that’s the way I usually feel. However, a more productive way to frame this problem is to consider how to maximize value added. When framed this way, choices aren’t negative, they’re about selecting the most beneficial path. So the question is: What adds the most value?

An important caveat here is not to over-analyze what constitutes the most beneficial path. I’ve found myself stuck in a loop when I ask, “This is good, but is there something better I could be doing? What is the best option?” At some point, motion is better than analysis, and continuing the analysis is worse than simply selecting a good option. (See also: “The perfect is an enemy of the good.”)

In many cases the value added via one path is sufficiently greater than the value added via another path that the choice is easy. That doesn’t mean path A is bad. It just means path B is superior.

Determining Value Added

If the better path is the one with more value added, how do we determine whether more value is added by increasing technical expertise or by focusing on other aspects of technical communications? I think much depends on the circumstances. Consider the following cases.

When a lone writer authors all the documentation at a small company, it’s probable that deep technical knowledge could only be obtained by diminishing the quantity of docs written. Since there’s a single writer, the effect of fewer docs could be far greater than if that writer were on a team of 20 writers.

Given a team of 20 writers, the quantity of docs written is likely quite large, so someone on that team had better have serious knowledge of authoring/publishing workflows, information architecture, user feedback analysis, search optimization, and the other tools-based or process-oriented emphases Tom mentions in his post.

But is deep technical knowledge really what a writer ought to aim for? I disagree with this claim Tom makes: “without deep technical knowledge, it’s almost impossible to write coherently and intelligently about the product.” Tom’s questions are about emphasis. I think it’s fitting to think about this problem as one of degrees. Writers don’t have to be able to single-handedly produce the technical product in order to explain it.

I wouldn’t aim for deep technical knowledge. I would aim for adequate technical knowledge, recognizing that what constitutes adequacy may vary by project, and that technical knowledge ought to grow over time due to immersion in the documentation and exposure to the technology and the industry.

I speculate that the need for writers to have deep technical knowledge diminishes as Tech Comm teams grow in size and as other skills become more important than they are for smaller Tech Comm teams. I’m not claiming that deep technical knowledge is useless. I’m suggesting that (to frame it negatively) neglecting deep technical knowledge has less severe consequences than neglecting content curation, doc tool set, or workflow considerations.

Example of Adding Value

I’ve been working recently on creating a little tool that, for a given doc article, displays a list of “pages that link to this page”. It is intended to aid writers as we analyze where to make doc updates/additions when a new software feature is introduced. We have quite a few writers in our company, so this tool will be used by several folks.

In addition, its technical availability doesn’t require anyone to build additional functionality into our publishing platform or add new metadata. This information is already available in the publishing platform’s API. I’m just exposing that content to the technical communications team members in a way that is easy to view.

My hope is that this small addition to our doc tool belt will make it easier to understand how the docs fit together. In other words, I’m hoping for a good return on my time investment.


Another consideration is whether the knowledge or skills any given writer possesses are such that others in the company could pick up slack if that particular writer fell ill or was away for an extended time. Our team has a schedule that shows who’s available to help with particular Tech Comm skills during the holidays, including creating new accounts for access to our docs, escalating or resolving bugs/issues with our publishing platform, and responding to doc inquiries. If a task was not accomplishable due to the absence of a single team member, that would be a problem. Can the same be said for a writer’s lack of deep technical knowledge?

It may sound like I’m presuming the answer is “No” but it’s an open question. Perhaps a lack of deep technical knowledge leads to flawed, misleading documentation. That would be a problem. If you work in an industry that requires deep technical knowledge to contribute to the doc set, you should have deep technical knowledge.

My overall point is that there are sometimes diminishing returns on investing time in an area. And we’re always choosing one path over others. The questions are: when or where does that diminishing occur, and what available options maximize the value you can create from where you stand?