RatcliffeBlog - Mitch Thinking Out Loud

Invisible dogmas and their cost

Invisible dogmas and their cost

I'm working on an article for a book to be published by Cambridge University Press this fall, and have come across what I think is a perfect example of my subject, the invisible dogmas that can be built into organizations by the unexamined use of technology. I'll get to the example in a moment -- here's a draft of the first section of the article, which will be a chapter of the book Creating a Learning Culture -- Strategy, Technology and Practice:

Technology is neutral. Everyone knows that, or believes it. In the strictest sense, when technology is waiting on the shelf to be put to use, this is true—it can be put to almost any use. However, when confronted with the reality of supporting humans and their complex interactions, technology can be a Typhoid Mary of poor thinking. It can be a carrier of assumptions about how people can or should interact, dogmatic interpretations of the meaning of information and how it should be distributed among a group. It is rife with invisible dogmas that can foul the best-laid plans of management, leaving learning organizations in ruins as people and networks route around the rigid stupidity they perceive in misapplied technology.

 

Granted, a computer connected to a network is a remarkably versatile tool for managing information and can carry almost anything, including the assumptions, presumptions, biases and ideologies of the programmer, the designer or the customer who will use the tool. Technology does shape the flow of information. The vision and skill of the people who apply technology can expand or constrain the conduits for ideas. Simple decisions made by programmers become embedded in the hardware and software used by groups, whether those decisions were right or wrong. Early errors are compounded by upgrades that ossify the original features. Programmers and support personnel who build their career around a particular technology platform don’t just maintain that system but defend it from change and can ultimately create narrow channels that shut out or reshape much of what the systems were intended to let flow freely. This is an invisible dogma every learning organization—every group hoping to accelerate their work or goals with technology—needs to be aware of and attentive to at every step along the path of technology use.

 

So, choose wisely when choosing technology to support your organization. Simple enough to say, but what, exactly, are we to look for when trying to cobble together—which is what we must do because there is no end-to-end solution for enabling any group to collaborate and learn with equal facility in all settings—a foundation for teams to collaborate and learn together? Look for biases, which are embedded in the programming and design of a product. Usually, you can see it in the interface in the form of rules and design choices that represent the following strains of bias in thinking:

 

• Participation and modality biases, that define how and when users should contribute to the group’s dialog; this may take the form of forcing people to use a form or that they learn some esoteric mark-up language to participate—maybe some of your team is most comfortable using email, but cannot do so to submit information to the workgroup application (why do they have to change? Because a programmer said so? Not a good enough reason when those people earn $80,000 a year already and do just fine communicating by email);


• Semantic biases, evident both in the range of options available for categorizing information, from labeling every new topic as a “problem” to be solved instead of a business opportunity (this evolving from the quality-assurance based practices of software programmers) to limited ranges of choices in pop-up menus that prevent the group from straying outside the well-defined lines that the program lays out;


• Time and skill biases, based on the presumption that every user has the same amount of time each day to participate in a group project to assuming that it takes everyone the same time to perform chores in the interface (that they all have the same skill level with the technology);


• Historical bias, the preservation of outmoded knowledge because of the rigidity of technology. What if your company has moved from making buggy whips to airplanes and the software you use still is designed for a buggy whip company? Often, it is the failure of software to evolve with the organization that makes it utterly useless—this has happened in many media companies, where digital technology was designed for outputting paper or television signals and has locked companies that could be exploiting the Internet and on-demand multimedia networks into outmoded business models.

 

Invisible dogmas can take many forms, from filtering of certain words deemed unsuitable for a community to presumptions about the way people should use hardware or software. Necessity dictates that decisions be made at every phase of development which emphasize certain priorities or subtract what are deemed unnecessary features. This is the reality of developing tools on a limited budget and well in advance of a truly universal computational environment that can accommodate any information or mode of input with total flexibility to manipulate data for accurate re-representation to many users. It’s still very early in the computational evolutionary epoch and sacrifices must be made. An organization can face these realities by examining decisions to assess how they will shape the resulting knowledge for good or bad, increased or decreased accuracy and clarity and the ability to re-use information as technology continues to develop.

 

The scientific method, which demands rigorous self examination by scientists of their data, their analytical choices and the final results, is the model for abolishing—or, at least, substantially reducing—built-in biases and limitations that can have a negative impact on the groups using technology for learning or management. A discipline of software historiography will eventually emerge. This article suggests a few of the steps that can be taken today to launch this practice.

 

Decisions that shape the future collection and processing of knowledge are highly political. It is often uncomfortable to ask questions of acknowledged experts in a domain of knowledge that suppose they might be installing unfounded biases in a system for capturing information and conveying it to others. Yet this is exactly what programmers and information architects must do in order to ensure that they are not building errors or blind spots into the future of a field of study or even a single project. Knowing how and why design decisions are made, recording those decisions for future use by programmers charged with upkeep and improvement of an application, and recognizing when a decision is based on a controversial position or promoted by an influential individual, so that future users of the system can revisit its basic assumptions is a tightrope act involving competing agendas and personalities.

 

Unfortunately, most experts concentrate their deep knowledge in one area and cannot conceive of the complexities or concessions required to build, for example, a simple application for communicating information (as distinct from knowledge). Even the dedicated polymath who has learned a programming language in graduate school in order to process a large amount of data, but has not kept up on the latest advances in software, is likely to be many technological generations behind the leading edge by the time they reach 40 years of age. So, we must encourage the development of questioning skills that allow the parties to a technology-supported learning organization to collaborate to identify and eliminate to the degree possible within the allotted time and budget the invisible dogmas that they must create in order to get any working software into users’ hands.

Okay, so here is the perfect example of a hidden dogma: The U.S. military preparation for the Iraq war, which was largely "wargamed" using computers that selected feedback based on history and the assumptions programmed by the designers of a scenario for the war. Unfortunately, a lot of people are going to die as a result of the flawed assumptions in the pre-Iraq war games. Lee Gomes does a good job of explaining the process here: "People who follow war gaming say flaws might have occurred for several reasons. Intelligence failures may have miscalculated such realities as the size of Iraqi forces, for example. Or game planners may have let that age-old enemy of careful planning -- wishful thinking -- affect their analysis."

As a result, the U.S. military, despite its denial that it is the case (while CBS radio had an interview with a British general who said the coalition is working to make the "battlespace" right for the attack on Baghdad), is in a two-week or longer "operational pause" and Lt. General William Wallace is saying "The enemy we're fighting against is different from the one we'd war-gamed against."