Principle of Shared Responsibility

The DocOps principle of shared responsibility states that everyone in the extended enterprise—including contractors, partners and customers—are responsible for the creation and maintenance of documentation. As noted by Choo (2002):

“Everyone in an intelligent organization participates in learning and contributes to knowledge creation. Front-line employees and lower-level supervisors and managers develop tacit knowledge and specialized know-how. Their knowledge is closely bound up with the intuitions and heuristics that they bring to their tasks. Their knowledge is all the more valuable because it is often impossible to verbalize and hard to transfer. They work at the boundary between the organization and the outside world, and it is through their actions that the organization ultimately attains its purpose.”

There is nothing more elusive in the enterprise today than the ownership of documentation. Either no one is particularly responsible for writing documentation, or there are only selected roles that are responsible for the production of documentation such as business analysts, architects, technical writers, and so on. However, “knowledge creation is everyone’s concern, and not the responsibility of a specialized few”.

This situation arises due to a number of misconceptions, chiefly the notion that documentation, crystalized as monolithic files—and their eventual printouts—are deliverables. Only a tiny fraction of documentation, say, a marketing brochure, are actual deliverables. The DocOps view is that documentation is an extractable property of any, past, current, future, or potential endeavor and object in the enterprise. For this reason, you will see the term document view many times over the course of this text.

Whenever documentation is treated as a deliverable—as a point-in-time event—rather than as an intrinsic property of an enterprise’s objects and processes, it becomes a disembodied component which may or may not be produced subject to shifting priorities, time constraints, and resource availability. In the converse scenario, that of a waterfall enterprise, dedicated documentation producers are appointed, whose main remit is the production of said document deliverables, but who may not be the most qualified individuals to write about the subject at hand.

In all cases, the underlying fallacy is the belief that documents are produced by a set of ‘special’ people—the authors—and passively consumed by others—the readers . The principle of shared responsibility establishes that everyone in the extended enterprise—including its partners and often customers—are the creators and maintainers of content. Senior managers are also “creators of information and knowledge, and it is in this role that they accelerate the organizational learning process” (Choo, 2002).

Bush Vannevar (1945) placed particular emphasis on the value produced by the seemingly passive reader, whereby their navigation paths—traversed as a result pursuing a given line of inquiry—could become part of the documentation body itself, resulting in “a mesh of associative trails”, when linked together:

“The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities. The patent attorney has on call the millions of issued patents, with familiar trails to every point of his client’s interest.”.

In this way, the mere act of consulting and navigating the documentation system, results, even unintentionally, in an act of co-creation. Unfortunately, in most contemporary documentation systems, ‘readers’ interactions are usually at the fringes of author-owned documents; their contributions are often limited to comments and emoji-styled reactions. 

Ted Nelson (1987) referred to such an inclusive approach as pluralism. He was particularly insistent on the principle that works published on his envisioned hypertext system “may be revised by anyone”. What if someone wanted to change the CEO’s mission statement? Nelson already anticipated such an objection:

“Is this chaos? Not at all. Because at any one time, you are within one specific document, the work of a specific author. If this work is windowing to other documents, nevertheless you are not ‘in’ the others, but viewing them through the present author’s filter.” 

What Nelson meant by windowing is that the system always makes explicit the difference between source versions and revisions, without the risk of impersonation. Nelson also understood that many missed collaboration opportunities were due to the use of disconnected communication systems—which is a problem right at the heart of DocOps:

“The initiatives and contributions of many people are assumed to be worthwhile. But there is at present no way to gather, and save, and publish, the many documents and scraps that people are writing on screens and sharing through an immense variety of incompatible systems.”

Douglas Engelbart (1990) was also cognizant that “the tools and methods of computer-supported cooperative work” will be of “benefit to the ongoing, everyday knowledge work within and between larger organizations.”

While the principle of shared responsibility may appear self-evident—if not plain common sense—its observance comes with a number of implications:

1. there are no documentation owners
2. there are no ‘passive readers’ or fringe collaborators
3. gaps in documentation are the fault of ‘doers’, not ‘writers’.

No Documentation Owners

Let us start with the first point by explaining why documentation owners are undesirable. We live in a product-centric era in which most objects in the enterprise are now called ‘products’, and all products have product owners or ‘POs’ for short. However, documentation is a property, not a product.  As Steele (1993) observed, “in the age of distributed information, where everyone is a producer of information, the concept of ‘centralized’ intelligence simply cannot survive”. 

The figure of a documentation owner is problematic because it tilts the balance of accountability and responsibility to one person. Instead, in DocOps, what we have is the role of editors (and chief editors) whose goal is to coach the doers. Who are the doers? Everyone, including the editors themselves, whose role is, we hope, not solely editing. As Choo stated, “The central actors in information management must be the information users themselves”.

Feelings of skepticism about the lack of ownership is natural. Everyone who has been in a management role for a long time knows that orphan things do not get taken care of. The difference is that what is ‘owned’ is not the documentation per se, but the underlying object: a new business strategy, an application, etc. 

In other words, documentation is not the responsibility of a documentation-specific owner. It is the responsibility of everyone who participates in the product or endeavor from which documentation is derived. Thanks to our modern electronic communication, it just takes rambling on Zoom to generate new knowledge: everyone is a content creator.

No Passive Readers

The second point is that there are no passive readers nor fringe collaborators. As Choo suggested, “the separation between information provider and information user should be dissolved”.

The reader may wonder why this principle is not called the ‘principle of collaboration’. The reason why is that collaboration is a weak word especially given for what passes for ‘collaboration tooling’ these days. Collaboration is almost the opposite of ownership; it doesn’t place any accountability or responsibility whatsoever on the collaborator. Co-creation, instead, prompts active involvement.

There are naturally different ‘personas’ when it comes to co-creators depending on their rank (executives, middle management, partners, contractors, suppliers) and their role (domain experts, business analysts, testers, etc.). DocOps’ mission is to facilitate documentation workflows that best align to each persona’s needs.

Doers’ Responsibility

The third and last point is that gaps in documentation are the fault of doers rather than writers. What this means is that, ultimately, anyone who creates, alters, or consumes knowledge, is responsible for keeping documentation fresh and accurate—provided, of course, that DocOps best practices facilitate it by reducing friction to a bare minimum. The principle of generative content, if embraced fully, should leave very little manual work for co-creators to do.

The point of reducing friction is what DocOps is all about. Doers are not alone in front of a forty-five degree high hill with a flag placed on top inscribed with the text ‘complete documentation’. They have a buddy: the DocOps engineer. The role of the DocOps engineer is precisely reducing to zero—if possible—the amount of friction—rework, typing text from scratch, figuring things out, and so on—which may afflict the co-creator.

Reflection

The principle of shared responsibility not only demands all actors in the enterprise to be active creators but it also challenges the notion of enterprise documentation as a process in which the primary goals are management and access control. As Choo noted,

“Organizations are societies of minds. Actions and decisions are not the simple outcome of any single, orderly activity: They emerge from an ecology of information processes. A diversity of participants and points of view collaborate together as well as challenge each other.”

From a DocOps perspective, enterprise documentation’s problem zero is the dire lack of relevant content—authors going unhinged and writing swaths of ‘authorized text’ would be a ‘nice problem to have’. There is, however, a technology side to this principle which has to do with enabling and opening up documentation systems in a safe manner.

Naturally, provided that we do have relevant and sufficient amounts of content in the first place—via property extraction, human authoring, or a combination thereof—we want it to be as fresh and accurate as possible, which takes us to the next principle.