Why Wiki Isn’t New to Government

In government, where change is recurring and often stressful to the employees affected, Web 2.0 can be a tough sell. One of the biggest hurdles in implementing technology in the workplace is not resistance to technology per se, but the cultural shift that the new software represents. But when a technology is introduced which replicates an existing work process in a more efficient way, is it really “new”?

When I joined the public service I often heard it said, “In Government, everyone is an editor.” For recent graduates — or others just accustomed to the experience of creating polished work and having it accepted verbatim and with full attribution — this is a warning about the process of government.

You write a document. Several peers or senior colleagues will review it and add suggestions and changes. After this initial round of development, your manager will likely wish to take out their own red pen for additional quality control. Once you’ve folded these in, your document (or rather, “the” document) will be ready to make its way up the chain to your director, who will likely make other edit requests for you to include before returning it for final approval. Depending on who or what the document is for, the document may continue to morph for some time even after its left your workgroup.

For people who are either protective of their product or simply used to creating something “final” by themselves, the whole experience can be a bit unnerving. Some edits will feel legitimately useful: significant additions of important information, corrections of errors, or re-ordering of content to make the ideas flow more effectively. Other changes may sit less well: wholesale deletion of entire paragraphs, wordsmithing, or comma moving.

But this is the way we work in government. What you create is a draft, which may ultimately be returned to you several times covered with sticky notes and red ink, or, in the case of electronic documents, with multicoloured strikeouts and comment bubbles detailing the tracked changes. It can be initially painful and occasionally still frustrating, but more often than not the resulting product is superior to what any one person could have created alone.

If this is any different to what a wiki accomplishes, the distinction is lost on me. Wiki is more than just a software platform, wiki is a process of collaboration.

You create a wiki document. Several peers or senior colleagues review it and add suggestions and changes. After this initial round of development, you advise your manager that you’ve got a draft posted. The manager logs in and makes their own contributions to quality control. Now there’s something online for your director to have a look at when they have some time.

The process is completely transparent. Everyone’s edits, major and minor, are captured in the wiki’s history tab. There are no multiple copies of the document floating around through email, nor any misplaced hard copies with edits yet to be added. Everyone is editing the master copy of the document in real time. None of the deleted text is ever really lost: it exists in a previous version. Any content deleted from a previous version of a document can be copied forward into the current version, if someone decides it was worth including after all (as-is, or as draft text to be re-worked).

A wiki isn’t useful for every document — sensitive information requires sensitive handling, and you probably don’t want employees making wish-list alterations to official policies — but for fast and efficient building of unclassified documents, why not wiki?