In early December, researchers at DeepMind, the artificial-intelligence company owned by Google’s parent corporation, Alphabet Inc., filed a dispatch from the frontiers of chess.
A year earlier, on Dec. 5, 2017, the team had stunned the chess world with its announcement of AlphaZero, a machine-learning algorithm that had mastered not only chess but shogi, or Japanese chess, and Go. The algorithm started with no knowledge of the games beyond their basic rules. It then played against itself millions of times and learned from its mistakes. In a matter of hours, the algorithm became the best player, human or computer, the world has ever seen.“One Giant Step for a Chess-Playing Machine”, Steven Strogatz, New York Times, Dec. 26, 2018
After a week of reading and writing complex technical documentation for sysadmins of virtualization software, the aforementioned article got me wondering about the effects of AI on my profession.
Presently, experts with years if not decades of experience and knowledge are responsible for configuring and running these systems. By definition, their knowledge is partially outdated – new features, patches, and errata come out all the time.
As AI takes on greater responsibility for setting up and managing these systems, the knowledge threshold for an end user to run those systems decreases. This is a well-established pattern of technology decreasing barriers to entry. The same person with the same amount of learning becomes capable of more significant results. For example, in the past, a ship’s navigator required extensive mathematical and navigational training plus years of experience to produce reliable results. Today, an untrained person with limited experience and an inexpensive GPS unit
can achieve outstanding results.
Expertise shifts further up the spectrum. The
As systems become more complex, they impose a greater knowledge burden, until that burden becomes too costly. The competitive advantage goes to organizations and technologies that remove this burden.
I image that AI can be developed to handle those problems and exceptions. Instead of relying on a person to read and apply that information correctly (with a significant loss along the way) make AI that can learn and apply that information correctly all the time, every time, immediately.
So, what does this mean for technical communicators? For one, I believe it points to a shift away from pure writing as a means for delivering critical information: More expertise will be embedded directly in the software.
Technical writers/communicators operate at the information boundaries between new capabilities and the integration of those capabilities into a smooth, software-assisted, user experience. Software only needs documentation to explain functionality that hasn’t become easy to understand and use.
To express this in terms of the four core Agile principles:
Principle 1: Individuals and Interactions over processes and tools
Technical communicators must work as members of each team helping to develop and deliver a new product or capability. Writers much become “Agile-proficient” and assist groups with Agile processes.
Principle 2: Working Software over comprehensive documentation
Although “documentation” in this principle is referring to project documentation (such as detailed specifications), Agile projects rely on User Stories as a vehicle for talking about requirements and expressing desired functionality. Because talking is ephemeral and synchronous, teams need to capture the essence of these conversations in writing. Writers must become experts in understanding and communicating user stories. These stories must include interactions with both the software and all of the technical information/resources that accompany the software.
Principle 3: Customer Collaboration over contract negotiation
Level 1: (Where “customer” = client/end user) Iterating the software and the technical information while it is is being delivered to the end customers/users. You must collaborate with customers to understand their information needs.
Level 2: (Where “customer” = software development team) This is why you, as a technical communicator, must work as an embedded member of the software/product/feature development team.
Principle 4: Responding to Change over following a plan
Because Agile development is inherently fluid and dynamic, you have to contribute information on short rapid cycles (hourly/daily?). The technical information embedded in the product IS part of the product. There is no such thing as starting documentation when a feature/capability is nearly complete.
Postscript: Wow! This post is a lot longer than I expected. I’ve been reading and thinking widely on these topics. I hope this is interesting and useful to you.