In this chapter (Page 239):
In the chapter, the Wiki Workplace we explore the benefits and risks of using collaboration within a company.
This is a chapter hub; please feel free to refactor subtopics to their own pages.
In the twenty-first century, most companies create value and profit from knowledge. The Wikis are among the many tools that enable Mass collaboration - which can increase the amount of knowledge created and retained by an organization. Collaboration also changes workflows - using living documents and social bookmarking an organization's knowledge can be kept more current and less time needs to be spent recreating documentation.
Contents:
Knowledge Production(refactoring in progress, please help. - digesting some very interesting ideas left by other editors!)
In the scientific, academic, professional, cultural and administrative worlds, a shift is occurring where people are changing the way they work, rather than being focused on creating and managing documents, their daily routine is centered around creating knowledge. Perhaps the concept might be better captured as liquid knowledge - where "know-how", "know-why" and "know-what" are created in collaborative melting pots, which, with the assistance of software, can be poured easily into any number or information formats and pushed or pulled to where that information is needed.
An example of a workflow that companies are moving away from is the traditional model of sending files as attachments in email. The problem with email and attachments is two-fold.
1) Email is ephemeral. While it garners a high attentiveness on the day it is received, it is quickly forgotten.
2) Email is an information silo. Information goes from one person to another in a way that is not shared with the wider group, it requires special searching tools (which may or may not be well deployed) in a typical company
3) Email is only collaborative in a bi-lateral sense, and even so it doesn't work very well. For example, when a discussion has ensued using "reply in thread" with >>> marks and indents the format quickly becomes a mess that is difficult to decipher and a pain to transfer to another document.
In non-computing life, folders are used for things that need to be stored indefinitely but mostly ignored. The same natural behavior should be adapted for computers. Suppose, for instance, we stepped back and said 'social collaboration and content creation are the heart of why we use computing' rather than 'running applications is the heart'. Would we have any of the same interface elements? Today, the user experience for a desktop computer is overwhelmingly about files and folders and attachments - little boxes all of them, and we must know all of their names. The Web on the other hand, is all content. Content links to content. On the web, do we even care what a file is called? An early forerunner of this method was Apple's Newton, an early PDA that stored data in object-oriented databases known as "soups". The content in these soups were available to all programs; and programs could operate cross-soup; meaning that the calendar could refer to names in the address book; a note in the notepad could be converted to an appointment, and so forth. The "soup" was a powerful 'anti-file' concept - inherited years later by web based applications - software as a service like wikis that rendered most content from databases rather than file systems.
In the English tradition, the essay has always been dominant form of intellectual analysis bot the essay and its academic equivalent - the "paper" are lengthy documents wherein numerous arguments and facts were marshalled to support a position or hypothesis. Essentially this is a competitive, rather than collaborative effort - papers and essays compete to be read and acknowledged. It is also by nature a "star" system because not all essays receive equal consideration at the start. The same can be said of most strategic and leadership process in the workplace - all opnions count, but some far more than others. In the New Alexandrians wikinomics explores collaborative science, but these activites are relevant in the workplace than they are in the academy. The question is not whether an essay is the proper form for knowledge creation - is it the most efficient? In most cases, no. Participants don't have time to read competing essays before making strategic decisions. Why not have the competitors collaborate instead?
Centuries ago, rabbinic scholars developed a similar method for examining the Talamud: the Brisk, or "conceptual" style of Talmudic analysis has become very popular by rigourously breaking each Talmudic law down into conceptual components. The visual relationship of concepts categories and ideas were a distinguishing feature of mind maps and web 2.0 with a future evolotion toward somthing not unlike the futuristic motion sensitive screens depicted in the movie Minority Report. The most important (supported, criticized and found worthy) pieces reside in the centre of the image. Less-qualified, more transient, disputed pieces are in smaller fonts, and around the edges. As pieces are edited, supported, used, etc. they migrate - the display is not static, but dynamic and reflects a community. Imagine everything you dealt with (on your machine or on the Net) playing this way. A soup with community prioritisation ... now there's an image to play with, and not a file attachment in sight!
The potential for open collaboration to change the way people work is enormous when it takes off in small teams. It takes root with a few people and more join almost under a form of peer pressure. This however does not make them active contributors.
The transparency inherent in the process, that people can see when others are online and what their contributions are is also intimidating to many people unaccustomed to this new approach. Leaders and managers as well as peers can see where people are shaping content and material for the advancement of a project. How management will deal with and reward this is also challenging. People may be spending lots of time contributing changes but having them rejected or turned into something else. Are they still valuable contributors to the team?
Going in the same direction is the fact that many people are still unaccustomed to having their work almost "reviewed while they work". There is still an habit of working on something alone in your corner and presenting it to the team only once it is completed. Getting used to the constant "work in progress" style that comes with wiki-like collaborative edition is by itself some kind of a revolution in some environments.
More pragmatically, I have worked on projects using Google Docs. We were 4 people working at the same table and I thought that giving the possibility to everybody to enrich collaborative content in real time would be a really valuable asset for our team. But it ended up a semi-failure, with two of us saying that they could not get used to the idea of a living document that was moving in front of their eyes while they were typing. The difficult part is not to accept the idea of collaboration in the workspace, but to overcome the fear that the things that we "know" can become rapidly outdated, refactored, or recognized as key insight that can help the group achieve a new level of success.
The Evaporating Cloud
The Evaporating Cloud has been done on the personal crisis of corporate documentation. The paradoxical requirements that documents be both current and comprehensive has created the individual conflict to act or analyze. Wikis are the injection that breaks the paradox, making the effective batch size of contribution much smaller. This is powerful. The result breaks another conflict; the need for a singular vision of an initiative in order for it to be broadly embraced. Without collaboration, top-down programs inhibit acceptance by their completeness. This likely will apply to customer/consumer acceptance in the near future, where early wiki involvement is needed to assure successful commercialization of new products.
However, there is yet another corporate benefit that would appear to result from implementing wiki collaboration that can only be whispered: the obsolesence of Middle Management. If the true decision-makers can see the work being done (in a wiki) without biased presentations and jiggered data, what would become of the PowerPoint people? Their legions would drain from the organization in the same manner that unneeded "work-in-progress" is rapidly depleted after a successful implementation of Lean Manufacturing in a production plant. In this context, what part of the corporate ladder is muda?
The good news is that you only need a small number of contributors to benefit a much larger audience. Wikipedia for instance has just over 75,000 active contributors, but is accessed daily by 5% of all Internet users. Patience and persistence will be rewarded and both are certainly required. However, in a corporate environment there is a risk that people in some part of the company (say, the sales/IT/Finance... department) will not contribute to the common knowledge, hence diminishing the value of the shared wiki for everybody else. Here some kind of incentive scheme could be useful in order to foster the adoption of new tools more quickly.
As the technology that enables mass communication and collaboration becomes more fluid, common-sense and ubiquitous, the justifications for strict hierarchical structures become less compelling as transaction costs are reduced. If we accept the premise that groups, under the right conditions, make better decisions, have sounder judgment, and make better predictions than individuals, and we accept that loosening hierarchies under conditions of digital networking and communications allows individuals to self-select into functions for which they are uniquely suited, then it makes sense to loosen the strict organizational forms that are essential to the laws of business organization so that more fluidity is permitted.
For example, current legal business forms reflect the conventional acceptance of strict distinctions between shareholders, directors, and officers; this could be fundamentally changed or dismantled. In addition to the other benefits flowing from wikinomic interactions, this would allow for a more robust communication and account of the interests and information held by decision-makers, owner-shareholders and those individuals that run day-to-day operations. This is more than simply incorporating technology that allows for a wiki-workforce or a prosumer, but a fundamental change in business organization. This follows and builds on the tradition of the modern cooperative model. However, this could go further using technology to allow all interested parties to tailor a unique business contract that fits the needs of the specific group and is resilient to changes in group composition.
For example, the internal documents of the business organization, e.g., the by-laws and corporate charter of a corporation or the membership agreement of a limited liability company, could be drafted using a wiki on a rolling basis, and all parties - shareholders, directors and employees - could then vote periodically on binding provisions. This would continue so all interested parties could directly propose changes and amendments to the controlling documents, which could be scrutinized and voted upon by all other members on a rolling-basis. This could be accomplished with an inherently progressive voting mechanism that is triggered upon pre-determined terms. Here is an example voting mechanism. Another example of an experiment in this idea can be found here.
If the new kinds of collaboration we are talking about here are really becoming this big, wouldn't (especially large) companies want to integrate these new ways of working (like social bookmarking, social networking, wikis, blogging) and the tools they choose for it in a structured way, and to become visible in their Enterprise Architecture? Business Process Management guru Peter Fingar refers to a Human Interaction Management System. So how would we describe this Enterprise 2.0 Architecture?
The uptake of wiki technology in a large corporation is initially among the more technology-centric groups, but in small communities there may be a pent up demand to work more closely and collaboratively together. In large organizations, people may tend to keep information to themselves. Working in an open forum and putting half-baked ideas out there can be difficult. Even more challenging is the fact that someone comes in after and changes the content. People may resist the capabilities of this technology, and push it aside as no more than a fad. Selling the concept is therefore an important issue.
When a business has commonly understood challenges with knowledge sharing, Selling the concept can be the easy step. At least selling it to those who are suffereing with the status quo and will be the primary contributors and consumers in the wiki culture. Instead the challenge will be engaging those who are content with the status quo. If IT is the gatekeeper and publisher of knowledge in the pre-wiki model and IT is not suffering because of the knowledge sharing difficulties, IT has little motivation to participate in change. It is the business users that are hungry for more/better information. Without IT feeling pain from the current system it becomes easy to push the Wiki implementation back to future budgets and behind other projects that IT decides have higher priority. In this scenario look for a sponsor with leverage over IT or consider an effort that can initially move forward without IT.
Corporate culture has to change from an environment of rewarding the one expert to rewarding the team of experts sharing information. In order to stay competitive in a global market, collaborative tools will need to be utilized to maintain the vast knowledge that a corporation has gathered over time. Otherwise, the consequences will be important. The difficulty lies in operating the switch from the "closed model" where people feel threatened by the concept of openly sharing their knowledge and experience to the "open model" where sharing and participation are rewarded.
Though somewhat rough, the model underlying these assumptions is that people use knowledge and experience as a mean of maintaining their status within organizations. A specific competence of skill often means power and possibility to bargain favorably. The defy managers will be faced with will be in the building of a team culture rewarding openness and sharing more than individual technical skill. The reason why specialists are still so much valued is that they are some kind of a living repository of the organization knowledge. Acknowledging this and trying to go round it would help freeing information flows and improving the aggregated efficiency of teams and individuals in most companies. The "not invented here" model is a thought experiment that makes some interesting points in this regard.
list of reasons why companies will not wiki
list of reasons why companies should wiki
It may be a good thing to distinghuish best practices and strategies for adoption strategy: what will be the most effective way to implement social software as wikis and blogs in an organization?
Unnecessary Learning Curves
Even with technology-centric groups in large corporations, there is hesitation to use wiki technology because the corporate culture rewards the seasoned experts. These were the people who gathered information over long periods of time, but never shared with any other groups. Corporations rewarded these people with promotions and large salaries. Unfortunately, over the next few years many of these people will be retiring and they have not shared this information to continue the corporate knowledge base. Instead this information is lost and the corporation suffers. New hires will have to struggle with a learning curve. You cannot perform a brain dump of information to the next person without letting the next person experience the same situations.
It is too costly to record everything in a technical manual that is outdated as soon as it is published. Wiki technology allows people with various levels of knowledge and experience to collaboratively build a corporate knowledge base. With changing business requirements, your knowledge base adapts very quickly. With all new technology in the corporation, there needs to be a governance model that ensures the validity of the information that is being shared across the organization. Otherwise, your knowledge base will be corrupt. An adoption strategy is needed.
Anyone who’s been around the tech industry for any length of time knows what these three words, and their acronym, NIH, mean. To summarize, NIH refers to the organizational malady one observes in many project leaders and others in positions of control who frown upon, and frequently seek to crush, all ideas, projects and products not initiated by them. Often, if you want your idea adopted by someone with a severe case of NIH, you have to essentially make it their idea – you basically let the NIHer “steal” the idea. Yeah – you know what I’m talking about, ‘cuz just like me, you’ve done it – played doormat for the greater good, because it was more important to you to get the idea adopted than to get the credit.
As technologists let us pose this question: Where does NIH come from? What causes people to become so singularly and doggedly focused on promoting their own pet projects and agendas that they will subjugate the greater good - however measured - to their own selfish interests? I submit for your consideration (and hopefully debate) that NIH stems from, and is part and parcel of, the culture of secrecy that pervades so many technology companies.
==========================================================
(stuff below this line might belong somewhere else - but don't remove it from the current version until we find a home.)
Give the Gift of Good Karma
I had the pleasure of participating recently in a conference call discussion on the topic of consumer experience with several leading thinkers from the Open Source, New Media and Massively Multiplayer Online Game (MMORPG) communities, the purpose of which was to begin a conversation around how and why community-driven, or at least community-inclusive, products and projects seem to deliver superior results. The President of MMORPG company eGenesis offered an interesting thought about how communities’ basic ground rules – like secrecy or openness - influence culture and behavior.
He described his recent experience at burning man, and specifically its gift economy, where strangers give strangers gifts, and how this fostered a very welcoming and relaxed atmosphere. This experience led him to conduct a thought experiment: what if, rather than a gift economy, this gathering were based instead on a theft economy where the ground rules were, if you succeed in stealing other people’s stuff without getting caught, you get to keep the loot. This would lead, he postulated (and I agree) to an environment of secrecy, suspicion, hoarding and deceit. OK - so you’d be forgiven if right now you’re asking yourself “what the hell does this have to do with systems management?” bear with me.
Stop and think for a second about the lengths to which most large software companies go to try to prevent their code from being copied and their license terms from being breached. And consider further the sheer amount of collective money and energy that these companies and their customers spend on lawyers and lawsuits, auditors and audits, and compliance officers and compliance. I’d say that today’s proprietary software world is pretty darned close to the the anti-burning man theft economy dystopia envisioned by Andy.
If one were unlucky enough to be living in such a world, it’s logical to expect that NIH would be epidemic and acute. Because when you create a culture of secrecy and distrust, it is only natural for people to look out exclusively for their own narrow interests. Over time, those who steal and hoard well would get richer and more powerful, and most others would be scraping by at best. Think contemporary Rio - Think computer industry of the 1990s.
Contemporary Trends
And when communities spawn a culture where NIH is rampant, and collaboration scarce, they produce inferior results. Such communities produce inferior results because, over the short term, many good ideas never see the light of day, and over the medium to long term, because good people self select out of these environments.
Not Invented Here
Now consider the meaning of these three words in the context of Open Source. Perhaps better than any other three words I can think of, they convey the power and culture of Open Source. In this context, Not Invented Here means openness, inclusiveness, collaboration, debate, meritocracy – the best idea wins regardless of its source.
For producers and users (or prosumers to borrow a term from the book Wikinomics) of Open Source, Not Invented Here means faster product innovation through user and solution provider code contributions; Not Invented Here means greater utility for Open Source users because the product is, at least in part, invented by them; and Not Invented Here means lower R&D, sales and marketing costs for the Open Source company, which translate into lower acquisition and ownership costs for their customers. In Open Source, Not Invented Here is a beautiful thing.
To summarize, ground rules determine culture, culture determines behavior and behavior determines outcomes. Openness leads to collaboration and trust, collaboration and trust lead to meritocracy and meritocracy leads to better results. In contrast, secrecy and being closed leads to NIH and hoarding, NIH and hoarding lead to autocracy or oligarchy, and to inferior results.
I really love this book! I cited it in a recent blog posting for a company I am working with. I've pasted the blog here so as not to violate the company-promotion rule.
> You should rather integrate the content of your post within the text body. Forget about it, I've done it ;)_ Guillaume
contributed by gtewallace on Jan 27 3:02pm
contributed by Joost Bekel on Jan 31 5:46am
<span class="nlw_phrase"><!-- wiki: 2007-=01-=31 14:57:20 GMT --></span>
Ironically I am posting a comment to highlight that some comments here should not be comments:-)
Joke apart, I wonder if all commenters here realize they have the power to edit the main text body. Just be bold
:-)
contributed by Zoli Erdos on Jan 31 9:43am
Ok, my edits are far from perfect today (and some titles should be improved) but given I agree with Zoli I tried to create links between what has been written (transitions...). Please do not feel annoyed if I transformed your comment in body text, but this gives more value to information. Please tell me if there is something wrong with that and change it yourself if you find a better way to put it.
contributed by domguillermo@hotmail.com}on {date: 2007-02-05 22:36:40 GMT
Page Last Updated: Apr 28 4:12am by f.hantman@structured-debugging.org
Attachments for this page: