I was flattered that my post Technical Communication is not a Commodity was used as a catalyst for Scott Abel’s discussion with Val Swisher, Jack Molisani and Sarah O’Keefe on The Changing Face of Technical Communications, What’s Next? I had a fair amount to say in the comment stream that followed to defend my assertion that Tech Comm is indeed not a commodity, but since then a few other interactions have convinced me that there is another important trend in tech comm that should be recognized: the growing segmentation of the field.
It would be an exaggeration to say that the field had ever been entirely homogeneous. There have always been pockets where special knowledge and experience has been necessary, and pockets were special kinds of output were required, but these were on the fringes of the field. The broad base of technical communication, at least from the 90s through to the middle of the last decade, consisted of generalist technical writers using desktop tools to produce long paper documents and online help. That picture has changed radically over the last few years, and I suspect the change will continue. Technical communication is becoming a highly segmented profession.
Segmentation of qualifications
The demand for technical writers to demonstrate specific subject matter expertise is clearly on the rise. In the 90s, the fact that I had a fair amount of programming experience counted for a lot, and enabled me to make a specialty of doing technical writing for programmers, covering programming languages, APIs, and operating systems. When I worked for OmniMark Technologies, a programming language vendor, I had a very difficult time hiring technical writers with any kind of programming background. In those days, for a tech writer, programming experience, of any kind, was a ticket to ride.
Today, I don’t qualify for a lot of the tech writing jobs I see advertised in the programming space because I don’t have the specific experience they are now demanding — for instance, experience programming in C++ in an embedded systems environment. And it is like this across the board. More and more employers are demanding highly specific technical backgrounds for technical writing positions. The result is that you can be highly qualified and highly in demand for one very narrow vertical and be virtually unemployable for almost every other tech writing job that pays any reasonable amount of money.
(Where are the people coming from to fill those highly specific positions? From what I can see, it is experienced tech writers whose careers or personal interests happen to have led them into mastery of a particular specialty, and engineers in their 50s who can’t hack 20-hour caffeine-fueled coding jags anymore and whose interest have turned, as our interests often do in mid life, from doing to teaching.)
Segmentation of tools
Tool-based job requirement have been the bane of the profession for a long time, but the range of tools, not just different brands, but entirely different types of tools, is growing ever broader, reflecting a growing diversity of business requirements.
- Companies who are still producing long documents, and particularly those outputting to paper, are sticking the FrameMaker for its long document handling and typographic prowess.
- Companies who are trying to maximize highly-granular reuse, either because their product line includes many variations on the same base technology, or because they translate into many languages, are flocking to DITA.
- Companies who are trying to crowd-source content, both within and outside their organization, are flocking to wikis.
- Companies who are looking to increase their level of customer involvement and social media integration are focusing on social media tools and forums more than traditional docs.
- Companies serving specialized customers with specialized requirements, such as the aerospace industry, may be doing things like S1000D.
- Companies that are looking to produce richly linked content or to generate complex references or extract content from diverse sources may be doing custom XML based solutions (and might benefit from something like the SPFE Architecture).
Segmentation of channels
It would be tempting to assume that as far as channels go, everything is going to the web, and that is the end of it. But actually, not everything is going to the web, and for good reason.
- Security considerations mean that some organizations do not allow web access for their employees. This may mean anything from blocking particular sites to being physically disconnected from the Internet.
- In some cases, help is being directly coded into the product, not through callable on-line help, but at a much deeper level of integration.
- In some cases the whole emphasis is shifting from pushing documentation out to building and working in living communities where people respond directly to help requests and where the documentation is essentially an accumulated record of these interactions. (In other words, we are seeing mashups of the tech support and tech comm functions).
- While social outreach to the community of users works for many companies, it does not work for all. Some companies, particularly in the business to business space, have customers who are all fierce competitors of each other. Rather than contributing community content that could help their competitors, these customers guard their knowledge and experience with the product jealously, while seeking to build a closer channel to the vendor in the hope of getting one up on their competitors. Individualized channels for specific customers exist in a number of organizations. (I am indebted to Richard S for this point, from a discussion on Technical Writing World.)
- Mobile devices, and content specifically designed for mobile, remains a nascent area, but could be very significant going forward. (I’ve yet to be convinced that an interactive e-book offers any advantages over and interactive web site, but we will see.)
Segmentation of scope
As I discussed in my post Are Docs a Responsibility or a Business Asset, the scope of technical documentation used to be very well defined. We knew exactly what our responsibilities were and where they ended. Now, however, the scope can be very different from one product to another.
- As discussed in that post, the move towards task orientation has blurred the lines about where docs responsibilities end. Now the emphasis is on the user’s total experience with highly networked products and systems, and if that means we have to write about areas outside the boundaries of our own product in order to allow the user to use it successfully, that is what we have to do.
- On the other hand, there are products today for which the documentation strategy appears to be to send pre-release copies of the product to a handful of key tech bloggers and let them produce the basic how to information, then rely on the web to generate additional content and/or provide tech support through forums.
- For products with wide distribution, customer generated content often covers task and troubleshooting information in a far more comprehensive and specific way than the documentation team ever could. Increasingly I think we can expect to see companies questioning why they pay people to do what the community is doing better, and for free. It seems reasonable to suppose that, if tech writers are retained at all, they may be re-tasked to cover other more neglected areas (many many products have deep deficits in core reference material, for instance).
In short, the set of deliverables that tech docs are being asked to produced, which used to be virtually identical from one company to another, is more and more being customized to meet specific business requirements.
Where will we be in 10 years?
What will the profession look like in 10 years? Will it have emerged from what is undoubtedly a time of great disruption at the present into a more stable and homogeneous form, where people of similar qualifications deliver information of similar scope through similar channels using similar tools? Or will the segmentation continue and deepen? The question has profound implications for anyone trying to chart a career course in technical communications today.
My bet: segmentation will continue and deepen over the next 10 years.
What’s your bet?