[Home]SmallDocument

MeatballWiki | RecentChanges | Random Page | Indices | Categories

During the age of the typewriter and slightly before during the rise of the bureaucracies which motivated the typewriter, organization was based around the construction of reports and documents. Bureaucracies, being a paper-pushing system, were designed around the refinement of information from the leaves of an organization through increasing orders of summarization and resynthesization as one moves further up the chain.

While bureaucracies were prevalent long before the typewriter, this device facilitated the creation of much longer documents and thus much more intensive document production (and therefore a bigger bureaucracy). The wordprocessor and the PersonalComputer? made the creation of documents the primary occupation of much of the knowledge working staff in the world.

However, making decisions with a document is really difficult. First, reading is very difficult. Writing moreso. Thus, people only create documents for big decisions, and--critically--mostly as a visual proof that people are actually doing work. But this is pointless busywork. Formatting documents, garnishing them with the corporate brand, flourishing them with redundancies that fluff up page counts is all irrelevant when no one needs indirect "documented" proof you did work. The pain of formatting a Word document is unnecessary for decisions internal to a team when your team members know how valuable you are. The only thing you need to write down is the bare elements of the decision.

What do people used to a bureaucracy do, however? Make big documents for small decisions. That's very inefficient, and so people don't write anything down, and they have no documentation--which is very dangerous if people leave or forget.

Smart organizations instead make very SmallDocuments. They write down only what's necessary. A sentence or a paragraph may do. But the technology most people use to write, Microsoft Word, is big and bloated. It is not conducive to writing small documents that could quickest written on paper, even though paper's physicality is not ideal in every situation. What's needed are simple, thin technologies that ease writing short things quickly.

Hypertext itself is biased towards small text. In this reader-oriented medium, holding someone's attention is critical. They can click away from you faster than you have to state your main thesis. Thus, it's better to simplify information, and push complexity into small bite-sized chunks that can be individually read only when necessary.

Most decisions are small decisions that are modifications or improvements to existing processes. Writing entire documents for these small ideas is discouraging as the overhead cost exceeds the social value. But if the problem was only as hard as creating a SmallDocument that is related to the others through hyperlinks--or even just modifying the text directly--then the team can move on to more productive tasks like actually carrying out the process.

The word "document" means "instrument of teaching." (document, doctor, doctus, doctrine) The word document is now associated with three-ring binders but "small documents" include things like flipcharts, index cards, even post-it notes (and their electronic counterparts). Facilitating the social construction of meaning requires artifacts that are somehow representations or containers of synthesis, somehow hold decisions over time (in PrintCulture?), but are still manipulatable enough to be in conversation, in OralCulture.

A networked organization with no hierarchy of control does not value flourishness or proof of work. It values efficiency and effectiveness and simplicity. Make writing down only what's necessary easy so people can move on to production. Relate what you write down to what other people are doing so they can read only what they need to. Hypertext is compelled.

The solution now should be obvious.


Don't know. What is the problem? Small documents may be the answer, but not to all questions. There is Wiki:NoSilverBullet. A book as a large document is also an answer to many problems. Bureaucracy is never the answer (except if we fear instability of our social system more). Quantity instead of quality is never the solution (except if we feel that counting is more reliable than evaluation). Page count in a thesis. Number of papers in academic career. Isn't it in a way just FormOverContent? Even design may become a problem. But design is often an answer. Small documents mean a network of documents, a rhizom, the chaos of living structures people in wikis often feel uncomfortable with. The only solution I see is: to look deeper and do the right things according to the situation. But of course, sometimes it's better to act quickly in a WorseIsBetter way. Parallel to WikiIsParadoxical.

I think the obvious disadvantage of having a cloud of SmallDocuments will be a natural EconomicSolution that will drive the production down a reasonable level and compel a more natural information organization that what coarse-grained large documents allow. Sure, for a while people will be chaotic, but it's up to us to show people how to OrderChaos.


Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: