What I spent my Thursday...
What I spent my Thursday night finishing
I've been posting bits and pieces of the following article, which will appear in a book about learning organizations in 2004. It's a call for recognition that every tool is a double-edged sword about which we need to think critically.
The Invisible Dogma
By Mitch Ratcliffe
When the World Wide Web was young, really just embryonic, I was part of a team charged with building a three-dimensional virtual trade show on the Web, because my employer, which ran successful technology trade shows, believed we had to be on the cutting edge of technology. The virtual trade show team met in person constantly and exchanged text via email, ignoring what our own experience about the limits and possibilities of virtual work was telling us about the potential for online events. We spent hundreds of thousands of dollars to build elaborate virtual booth space to sell to our exhibitor customers and to allow “attendees” to stroll the virtual aisles, collecting virtual brochures and virtual tchotchkes, as though there were no difference between the Javits Convention Center in New York City and a computer screen.
We failed to see, or saw only in retrospect, that our assumptions about how people would adapt to new networked meetings were leading us down a blind alley. We were praying that the Internet did not mean the end of meeting in physical venues with tens of thousands of other people to collect brochures and listen to sales pitches. And our tools, which let us create all sorts of nifty virtual realities, encouraged basic errors every step of the way, precisely because we were not thinking critically about how those tools changed the basic services our company offered.
Eventually, the expense of the virtual trade show project was chalked up as a lesson learned. But that company and many others still have not learned the larger lesson that there are all sorts of assumptions—about how people should act, what needs to be done to be “effective” and “efficient” and “profitable”—wrapped up in the tools we select to support our companies’ businesses. Some of those assumptions are embedded in the tools themselves while others rise out of our purchasing decisions, because we often select tools that reinforce what we think should be or, worse, hope can be the future of an industry. The evidence that this lesson hasn’t been learned? That trade show company, and virtually all the other companies in that industry, are struggling to stay afloat as more communication between customer and vendor migrate online into environments that look nothing like conferences or tradeshows.
Every company relies on tools to accomplish its goals. Those tools, which include systems for accomplishing our work as diverse as the written articles of incorporation to the information systems used to communicate, are selected in hopes of achieving optimal results. Many of the tools we use have become so commonplace that we never think about them or their impact on our day-to-day practices. Computer technology, in particular, is generally thought to be inherently neutral, a shapeless, omnifunctional thing to which we’ve given form by installing instructions in the form of code and, hence, not likely to shape our behavior as much as we shape it. Yet, most companies strive to repair broken human processes with technology, redefining human processes blindly as they do so.
Smart companies and accomplished learning organizations can stop reading here.
You’re still reading. This is a good sign. Either you recognize that even the best learning organization can never stop seeking new insights or you know that technology can’t repair broken human systems. The catch is, even when information technology (IT) is the right answer to improving a process, it has to be monitored—not just for performance and efficiency, but also for its continuing influence on the processes an organization is addressing through automation. Prevention of built-in errors and institutional stupidity, as with forest fires and sexually transmitted disease, begins with you.
“Isn’t the reason there are so many poor data solutions that the owners aren’t willing to dig around in the details,” said Britt Blaser, a developer of open source software for introducing quality assurance into transactions with whom I collaborate. “Fifteen years ago when I funded and later tried to run the Dynamic Computer project, we would send an extra stick-on keyboard key with each computer. It was red with white letters: DWIM. Do What I Mean. It’s what every database customer wants and it’s what most data designers are forced to guess at.”
Active engagement with our tools is the keystone of successfully applying technology to the problems of operating a company. It is the responsibility of management to undertake this engagement rather than apply information technology like an all-purpose salve for broken human processes. This article will tell you what to engage with and the mistakes to watch out for every day, not just on the day you make a buying decision.
Operating on auto-pilot
Anyone who has made a technology buying decision knows the process: An organizational issue is raised, such as “We’re not sharing enough information to learn from our customers and design a better product,” which is followed by the debate about what’s wrong. In a scripted exercise the problem is reduced to a missing step in the information collection, analysis and presentation process, because that’s what companies do today, right? Granted, companies do manage knowledge, often forgetting in large or small ways what it is they actually deliver to a customer. So, having decided that there is a step being missed somewhere, someone draws up a Gantt chart or a process analysis and then the diagnosis is handed over to the IT department to fix. Simple as that. How many of these scripted exercises, which ideally fit in the time allotted to one or two meetings, have you been involved in over the years? How many have failed?
Every failure of a technology is due to the resulting tools’ inability to draw users into a shared irreality field where the differences in workstyles are bridged by sufficiently compelling new levels of productivity to justify the inconvenience of using the tools. For all the talk about “friction-free” value chains, new tools are a hassle because they require a change in behavior. This is why information technology is a management issue in the first place, because we managers have to coach people through the process of adapting to new inconveniences in order to reach a corporate goal. It’s all about people, even if we’re told that information technology is transparent to existing processes and easy to use.
“The enemy we’re fighting against is different from the one we’d war-gamed against,” Lt. General William S. Wallace of the United States Army famously admitted when the first two weeks of war in Iraq led to an “operational pause” while, in the words of a British officer in Iraq quoted by CBS Radio, the “battlespace” was “reshaped.” Note how the language of computer simulation took over the war planning even on the battlefield, which is a sure sign that invisible dogmas are lurking, because it indicates an over-reliance on the shared irreality of the computer simulation to the exclusion of battlefield reality.
The built-in assumptions of the pre-war planning—that the Iraqi people would immediately turn on Saddam Hussein and his regime to welcome and even assist American and British troops—defined a scenario that misled planners, who raced ahead of their supply lines in the first days of the war. “In war, as in everything else, computers are only as infallible as the people running them,” Wall Street Journal columnist Lee Gomes wrote of this blunder. Additional reporting by Slate revealed that during the war games Pentagon planners had gone so far as to unsink ships destroyed by a general who, standing in for the Iraqis, used virtual suicide bombers—he was criticized for not playing fair and resigned rather than be associated with the results of the war games. "Instead of a free-play, two-sided game … it simply became a scripted exercise,” the general wrote to acquaintances in an email leaked to Army Times, a military journal.
In the case of Gulf War II, the generals and war-gamers at the Pentagon wrote their dogmatic belief that Saddam Hussein could not withstand an initial attack in large letters that, fortunately for the soldiers on the ground, resulted in an early recognition of the flaws in the war plan. Commanders on the ground adapted to the reality of the situation rapidly and in part because the war-game tools they used before the war prepared them to respond more quickly. Nevertheless, it is in that breach that management became critical to the success of the operation, which involved having the fewest soldiers killed as possible.
Coming face-to-face with a disconnect between reality and the models used for planning reveals what I call “invisible dogmas,” assumptions erected in the knowledge by which we are surrounded in the information age that mislead efforts and analysis or that shape the channel of communication to reinforce pre-ordained conclusions. Most companies suffer from what Doc Searls and David Weinberger suffer from “Repetitive Mistake Syndrome” because they refuse to learn when they live in a shared irreality field maintained by poorly designed tools for knowledge sharing.
Dogma: remnants of priestly practices
In everyday business and organizations, invisible dogmas are subtle and difficult to identify because information technology decisions are still treated as mysterious despite the fact that the priestly caste of programmers supposedly passed with the decline of the mainframe computer. The white coats and punch cards of the past have given way to the Internet and the nudist programmer working the late shift, even if the mystery attached to what programmers do has remained intact. We have to keep firmly in mind that the vision and skill of the people who apply technology can expand or constrain the conduits for ideas. The evidence of the Internet bubble is that high inspiration does not often yield practical results, because doing something cool is not always a path to doing something useful with a computer.
When confronted with the reality of supporting complex human interactions, technology can be a Typhoid Mary of poor thinking. Information technology, because it is a conduit that shapes our communication, can impose simplistic assumptions about how people should interact or ideological interpretations about the meaning of information and how it should be distributed among a group. Information technology 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.
For managers reading this article, I want to make one point that you should never forget: What information technology does is very simple; it stands in for human services, so any tool for managing knowledge is something that you should be able to understand easily. If a programmer or a software sales rep shows up at your door and spouts a bunch of buzzwords that you don’t understand or that do not map to the realities of your business, their tools aren’t ready for you. Tell them to come back when they know something about what you do. It’s exactly like being in any meeting where, when put on the spot, someone falls back on management fads or prevarication to explain away their mistakes, instead of taking responsibility and sharing the lesson with everyone at the table—you ask them to learn something or find another job.
I can’t count how many times I have been subjected to demonstrations of new products, especially products designed to “enhance productivity,” that consist of the guy who built the tool sitting down and with astonishing flourish and speed setting up and managing a complex project document while they look back over their shoulder and talk about all the great features of the software. Their hands seem to know instinctively where to go on the keyboard or how the mouse saves three steps. It’s really impressive. Here’s why: They’ve reduced their brain to computer code and, of course, they can operate it really well, because it’s their brain. They don’t run up against the mistakes in thinking and the realities of your business that come into conflict with their tools, because the software carries every assumption they made and, so, supports every assumption with a nifty feature.
Then, they leave the software—or worse, they sell it to you—and two weeks later you can’t figure out what the hell it does or even how it is supposed to help you achieve your goals. Of course, there are consulting services available to customize (fix) the software or to beat your team into the patterns of work and information flow that the software demands. It all comes down to the fact that you can’t think using another person’s brain, which is what you’ve got on your hands. Now, not all software is like this. Well-made applications accommodate many different ways of working, which is why, for instance, Microsoft Word is a vast application of which you and your team regularly use only one fiftieth the features. Eventually, the effort of supporting a mass market with an application makes the application so unwieldy that it becomes impractical—this is what is happening with Word and other productivity applications today.
Flexible type, immovable blobjects
Information technology is not a bad investment for a company. Refusing to use computers and networks would be a grave mistake. However, we also need to recognize that the knowledge tools introduced over the last 50 years will have negative consequences, just as type and broadcast media or the interstate highway system have given us propaganda and air pollution, to name just a couple downsides of other paradigmatic technologies.
Granted, a computer connected to a network is a remarkably versatile tool for managing information and can carry almost anything, from simple facts to complex theories. At every layer of its design, however, the computer, its operating system, application software, network connections, the network protocols, the interfaces between computers and databases on the networks shape information. The people who define and build each of those layers often have unchallenged control over the implementation of ideas. And we, the IT customer, often ignore how these tools sculpt what we know into what we want it to be. Assumptions, presumptions, biases and ideologies are injected into software and data services by programmers, designers, even the customer who will use the tools. Simple decisions made early in the life of an IT project 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. Managers, programmers and support personnel who build their career around a particular technology platform don’t just maintain that system but defend it from change, just as monks fought the onset of the Renaissance, and can narrow channels of communication within an organization so that they shut out or reshape much of what the systems were intended to let flow freely.
Email, though it creates many problems related to information overload, is an example of a successful tool for communicating over a network. As email has matured, generations of software that was supposed to facilitate workgroup productivity have fallen by the wayside. When “groupware” first came into vogue along with the first practical and affordable commercial networking technologies in the early 1990s I tried repeatedly to introduce shared word processing and message boards into a technology trade publisher’s offices. Invariably, the staff would try out my latest discovery and then go back to email, which was the simplest way to send a message. At the same time, email was the least efficient way, from a purely statistical perspective, to update a document that a group of people were working together to write – the most recent version of the document was seldom available to everyone, because it hadn’t been mailed to the entire group or someone would forget to attach it to email. Rectifying all those changes in the final document was, and still is, painfully time consuming, but the short-term convenience of sending an email that informed others on the team “Here’s my latest draft of the proposal” outweighed the value of time saved by the person charged with cleaning up the final draft. I’ve compensated for reality by adopting email as my primary tool for communicating with and managing teams; I make sure I’m not the one who has to clean up the final draft whenever possible.
Invisible dogmas can take many forms, from filtering out certain words deemed unsuitable for a community to presumptions about the way people should use hardware or software. Take the example of public libraries that want to provide informational resources to the entire community, including children, so they filter out access to Web sites with the word “breast,” inadvertently blocking women from learning about breast cancer. If they filter the word “ass,” Jesus doesn’t ride into Jerusalem on Palm Sunday.
Invisible dogmas can wipe out reality and replace it with wishful thinking. At a minimum, they sanitize reality, leaving people charged with responding to rapidly changing situations with very little authentic information on which to base their next decision.
Dogmas, however, are the results of remarkably practical decisions that are easily justified by management, employees and contractors or the companies that build knowledge tools.
The technology itself is so enticing that it is often difficult to see beyond the tantalizing features to the shortcomings embodied in the product. For example, I am typing this article on an Apple PowerBook G4 Titanium, which is so cool that Apple CEO Steve Jobs described it this way when it was introduced: “Titanium is sex.” It is the epitome, from a technologist’s perspective, of what industrial designer Karim Rashid calls “blobjects,” which science fiction writer and futurist Bruce Sterling describes as “though they are merely made things, blobjects tend to be fleshy, pseudo-alive, and seductive.” I paid more for this laptop than other computers with similar, though not identical functionality, even though it runs software that is cranky when it deals with 90 percent of the rest of the computers in the world. I bought it because it is cool, because it seduced me, just as every information tool you see this year will promise to deliver improved efficiency, better analysis of corporate data or the implementation of six sigma processes with nary a bump in your existing quarterly goals. Blobjects entice, but each one carries an agenda that spreads like a virus in the world, unevenly, in bursts of rapid adoption and reinforcing built-in dogmas along the way.
Here’s a simple fact: No IT project can achieve perfection. Were you to pull out all the stops and spend whatever it took to build a technology platform for managing a company’s ability to learn from the feedback it receives from the market, there will still be mistakes made. In IT projects, the dogmas are usually injected by decisions made in the face of realities about what can be accomplished on a given budget in a specific timeframe. The budgetary factor is tempered by the beliefs—the rules of thumb—about what is convenient or practical held by managers and the programmers who will build or customize the tools for the particular organization. Why do we recognize that legal advice can be “conservative” or “aggressive” but IT decisions are seldom discussed in such qualitative terms? Both shape the strategy of the company.
If there is a general sense that information management systems must sacrifice complexity to come in under budget, the resulting tools will not deal well with increasingly complicated data. Budget and beliefs result in short cuts based on cost-benefit analyses that can have profound effects on what the organization can achieve. These are the realities we have to keep in mind when erecting the foundation for a company, a learning organization or a government bureaucracy built on information technology. Nevertheless, we often make these decisions in response to messages that appeal to our fears of failure or our desire for success and not with a clear view of how each new tool changes our company in small or large ways.
The DNA of dogma
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, opinions or beliefs that have been arbitrarily laid down as authoritative rules about what people should do with technology, as well as when they should do it and how they should behave. Here is where inflexibility will interfere with the free flow of ideas. When I was attempting to introduce workgroup software into organizations in the early 1990s, my bias was that being able to open and share a document from any workstation was more efficient than emailing a document around a workgroup. While that may or may not be true, I was making an assumption that email was inherently less efficient and tried to block people from using that tool in conjunction with the workgroup tools.
Dogmas can be correct, which makes them all the more diabolically difficult to eliminate. There is no doubt in my mind or any manager’s that an organization should pick tools that enforce its priorities to some degree. It would be impossible to cook a meal in a kitchen where knives were forbidden and every company, because they do largely deal with the manipulation of information, needs to define the range of data it will try to process. So, a little thoughtful dogma is a very good thing. The very act of defining an organization requires managers invent a bit of dogma, a dollop of determinism in an otherwise chaotic environment—after all, we can’t be in the business of doing everything. A deterministic system is purposeful and supports goal setting. However, it that system eliminates the organization’s ability to make choices in the future it writes failure into the DNA of the organization.
Think about your own company. Have you ever said “Failure is not in our vocabulary” to your team? Okay, good post-modern managerial attitude, but bad for your internal debate if you are in the midst of a fierce competitive struggle for market share with another company and failing all the time. Language is a malleable tool in the conference room, but what if one of your software programmers decides to build an enterprise management tool that literally doesn’t acknowledge the notion of failure? Does the prospect of a dialog box popping up on the screen that informs the user trying to explain why a new product line bombed in the Midwest, “I’m sorry, but the word ‘failure’ is not supported in Widget Co.’s ERP system,” fill you with confidence that your team will be responding to reality and not an idealized market in which your competition can’t do better than you?
The mistake would be to get locked into those goals by a technology infrastructure that permanently enforced initial-state biases. If, after achieving your first-year goals of establishing internal competencies and completing product development, you had to go back and spend a year and a large amount of capital to retool your company for delivering its product or services to the market, instead of having these capabilities be an implicit result of your first year’s efforts, your company is not likely to succeed. Think about how many times your company or a company you know has had to retool information technology to support new processes and the consequences of setting and forgetting dogmas becomes painfully apparent.
Participation and modality biases
Rules that define how and when users should contribute to the group’s dialog are participation and modality biases. These biases may take the form of forcing people to use a particular application or that they learn some esoteric mark-up language to participate. Fact is, some of your team is most comfortable using email while others thrive on the phone or using a shared workspace and teleconferencing; there may be a guy who loves entering data in forms on his computer, but because the IT system doesn’t allow that mode of entry in some situations cannot use a form to submit information to a workgroup application. Now, for the purposes of argument, why do any of these people have to change their preferred mode of communication in order to contribute to the group’s success? 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 or telephone.
Even transient events can redefine how a software application reacts to the user’s input, so imagine how a poor choice by a sales manager hoping to streamline her prospecting process across a large sales force could shut down some of her staff and give others who happen to thrive in the application selected unprecedented influence in the organization.
Herein lies the importance of the invisible dogma: If a bias changes the performance of a tool and the tool will change the performance of a group of people, then we, managers, need to be very conscientious about the choices we make with technology. Simple example: How do your people react to being interrupted? Say, interrupted right in the middle of a meeting? The walkie-talkie-like press-to-talk features of the Nextel wireless service, which lets someone butt right into your day via cell phone are about to become a major service feature across most wireless networks—it will be played up in advertisements and the notion that one would ignore a “call” of this type will be judged rude by some, unproductive by others and all the while half the world will think it the worst sort of interruption. What we have here is a participation and a modal bias—first, there is a presumption that the press-to-talk service is useful and necessary (why else would your company have paid for it on the phones issued to employees?), a participation bias, and there is the related assumption that being available at the push of a button is a good thing, even if the person on the receiving end of walkie-talkie chatter can’t stand using the phone in the first place, which is a modality bias.
Technology, because it is usually deployed en masse is a blunt force instrument that often treats everyone the same way. This is especially apparent within the confines of a small group, where individual differences are starkly evident and can be exaggerated by the introduction of a tool that favors one form of participation or mode of dealing with knowledge over others.
Once a new tool is installed in your organization, have you noticed that some people who formerly were middling contributors suddenly take on leading roles under the new regime? Is there a cadre of stars who seem to have had their energy reduced recently? Does any of this have to do with a change in management practices or is it due to the tools changing around these people? In the film The Matrix, Lawrence Fishbourne’s character, Morpheus, introduces the hero Neo to life inside a computer simulation. “Do you think I beat you because I am stronger or faster than you? Do you think that is air you are breathing?” Participation and modality biases are elusive and difficult to understand until you accept the practice of questioning processes anew each day, then they become apparent and pop up everywhere. Do you want to know what the Matrix is? Look around.
Time and skill biases
Time and skill biases are similar to, but fundamentally different than the participation and modality biases, because they are based on the presumption that every user has the same amount of time each day to participate in a group project and assumes that it takes everyone the same time to perform similar chores in the interface. This is a particularly difficult bias to identify when dealing with software since the “ease of use” is assumed to be a uniform characteristic of software, yet not all people have the same skill level or tolerance for learning new commands and short cuts with each new application they choose. The reason original Macintosh operating system was so popular was because Apple strictly enforced its Human Interface User Guidelines across all applications that ran on the computer—the same commands worked the same way regardless of what you were doing with a Macintosh. Likewise, Microsoft’s Office suite provides widely but not completely consistent commands across a core set of productivity tools—it’s just easier to get used to than a collection of tools with different commands.
“If one has to spend precious brain energy learning the peculiarities of the [application] interface, there is less enter left to learn the topic at hand,” says Cliff Figallo, a veteran of building online communities and one of the other authors of a chapter in this book.
For example, I serve on the board of advisors of a company that builds software for workgroups. Among the founders and advisors there is a real passion for a type of collaborative editing tool, called a “wiki” (Hawaiian for “quick”), that allows a group to make changes to a shared Web page. I don’t like wikis, because you have to use a unique set of formatting commands that are unique to this tool that I find similar to other tools, but are dissimilar enough that I often get confused. It just takes me more time to get information into a wiki than I have every day. One other advisor doesn’t “get wikis,” in the words of the rest of the team, too. Compounding this distaste is the fact that each time someone edits a wiki page on the company’s site they get credit and a percentile ranking of their input to the company’s efforts is displayed at the top of the page. “You are in the 25th percentile of contributors” I am informed when I do take the time to work on a wiki page.
Now, to be fair, is this just bitching about my poor performance rating? No, it is an example of both participation and modality bias (some folks like their wikis and some like email as a primary channel for textual communication) and a time and skill bias, because wiki pages require learning a special mark-up language and doing the editing is more time consuming that tapping out an email. I prefer email. But, because the company’s founders like wikis, those pages display my contribution percentile while not a single email comes with a ranking of input, even though I send a lot more email. The system is stilted in favor of what the team wants to sell rather than how its customers may want to behave.
The important question for the company I am advising is whether the wiki serves the needs of the company? I may not be the right advisor for the company if wiki collaboration the primary mode of exchange it seeks to encourage (in fact, wikis are just one part of a larger whole the company is building, but being the flavor of the month and the subject of intense current development, the group is fixating on wikification of everything these days). Maybe they ought to jettison me and find someone who will contribute more? Or, perhaps, the preference for wikis is shutting out input that would be given if other forms of communication were more highly valued.
Most executives I know would prefer to use the phone. Almost no CEO I know makes day-to-day decisions that would be served by ranking their input percentile on a wiki. If one were to put a wiki in place as the sole mode of communication within an organization, it would be a disaster. At the same time, the largest freely accessible and collaboratively produced encyclopedia on the planet, wikipedia, was created using a wiki in less than six years after the technology was introduced. In its proper place, any technology can be a powerful tool. The hoe comes to mind when I head out to the garden, but I wouldn’t want to paint a house with one.
Semantic biases
The use of language is a mess, both due to its constant evolution and the differences in the way people use it. Semantic biases are evident 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 (in software, this evolved from the quality-assurance practices among programmers) and in limited ranges of choice in a knowledge tool that prevent the group from straying outside well-defined lines.
Semantic biases are most prominent in networked environments where different cultures and standards come into conflict. Let me remind the reader, again, that we are only at the earliest stage of the information age. From a historical perspective, we’re just learning to grunt and gesture with computationally enhanced communications. Only the most basic forms of networked transactions have been possible during the greater part of the history of computing and differences between systems were wiped out in the interest of “compatibility” in order to provide comparable information, such as product specifications across an industry. For example, there is a Performance Review Institute that administers the standardized product specifications for the aerospace industry. Achieving this kind of compatibility required that the basic structure of data be standardized first and, once companies were able to communicate about their products or services and the needs they had, generally customers have defined how sellers describe what they have for sale. Albeit, sellers have ladled a heavy dose of marketing on the facts. Nevertheless, when it came to decision-making, product specifications have been the gold standard—if the product didn’t do what the customer needed, it was returned.
When computing evolved past managing data to collection and distribution of knowledge, meaning became infinitely shaded and decisions are now made for convenience or budget’s sake that can substantially change the substance of what is communicated. The value of the same information is different depending upon the system analyzing it, just as no two people see the same event in precisely the same way. Each emphasizes different aspects of an event, for instance during a bullfight, one spectator may watch carefully the cape work of the toreador while another is watching the senoritas in the stands and wondering about how much tequila is in his margarita. Both are seeing the same event. Both will be able to recall it later, but neither will remember the same elements of the experience. Knowledge management is similarly complex and, as I’ve written elsewhere, computers let you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila.
As an excellent example of how varied the view of the same knowledge can be, try performing the same search on several different Web search engines. No two search engines return the same results, because they use different taxonomies, as well as the fact some promote results for payments. Google, the most prominent search engine on the Web displays results based on the number of pages that link to each page that matches the search terms on the assumption that more links means the page is worth looking at. This has given rise to a practice of gaming the Google system by creating dummy links to a Web page in order to raise its ranking—likewise, the notion of “Googlewashing,” a term that describes the systematic usurpation of the public consciousness a la George Orwell’s NewSpeak, has gained a foothold in online discourse. Google races to keep ahead of the system-gamers, just as managers must constantly assess their organizations for short-cuts that can improve performance as well as those that are doing damage to the business.
Within a group or organization the shades of meaning can be managed by strictly enforcing a schema, such as “A four on a scale of one-to-10 means the company should not pursue this opportunity at this time, but the idea should be reviewed again later.” This may work internally, but open the discussion to the outside world and it becomes a useless metric, because one person’s “four” is another’s “six.”
Semantic bias is perhaps the most dangerous type of invisible dogma, because it can convince an entire team that its interpretation of reality is reality.
Historical bias
“That’s the way we’ve always done it,” is the signature of the historical bias, the preservation of outmoded knowledge because of the rigidity of technology. Imposing a practice in technology is like setting it in cement.
The self-organizing qualities of a learning organization are anathema to the way centralized information technology has dealt with change. It is “a different mindset from the prevailing approach to software development and managing vast amounts of information,” says Greg Elin, a developer of “social software” that enables new forms of collaboration. “In the new organization there is no central control, errors are good, flexibility and self-repair are highly valued.”
Historical bias is often well-founded in the stories of the past. Enduring ideas, however, can interfere with necessary evolutionary activity, preventing the organization from considering new information and the changing context of the marketplace until it is too late to react effectively. 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, for example, where digital technology was designed for outputting paper or television signals according to day-part pricing schedules and has locked companies that could be exploiting the Internet and on-demand multimedia networks into increasingly outmoded business models.
When they fade into the background and go unexamined dogmas become invisible and do the most damage. Necessity does dictate that decisions that emphasize certain priorities or subtract what are deemed unnecessary elements at every phase of organizational and application development. This is the reality of developing tools on a limited budget. 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, compromise over what can be programmed into a knowledge platform is a dirty fact of life. 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.
Most dangerous of all is the tendency to settle on a set of technologies, with their attendant biases, and treat this initial state as the foundation for future decisions without returning to examine the compromises that produced initial-state biases in the first place. Everyone knows we make compromises in the process of selecting knowledge tools, but no one records these compromises critically, with the same kind of eye that, for instance, a literary critic or historian does when reviewing a book. There is a real urgency to get on with business that forces compromises into the past and out of sight almost reflexively. It enforces a kind of institutional amnesia that can and should be prevented.
If we were to engage in a practice of reviewing our tools critically, recording the compromises made along the way, it would be much easier to tune both the tools and our organizations over the long run. We may all be dead in the long run, but the people who follow us are going to be even more ignorant of the compromises than we are today if they have no hope of accessing these critical records of corporate and software development. I find this especially ironic in an age when half the books published each year about business attempt to explain the longevity of successful companies. Recording the history of your own company and its decision-making, including how the tools you use shape those decisions because of the compromises with budgetary and computational reality, needs to be far more important to you than finding out how Lou Gerstner made the elephants at IBM dance. Gerstner succeeded because he accessed his own experience and internalized the experience s of the company he took over at its darkest hour. He thought hard about IBM and his own decisions, about the compromises he would have to make at that time and the reparations he’d pay later to correct those earlier shortcuts.
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. It takes practice and is a practice that cannot be carried out by a corporate librarian or even a chief technology officer working on their own. From the beginning of a company’s life, records need to be prepared that exceed the requirements for simple reporting to shareholders or the Securities and Exchange Commission. Internal accountability, in the form of frank discussion and writing down what was left undone at one phase in the life of the firm and needs to be done later, is the architecture for successful growth. But the emphasis on metrics alone, which has dominated in universities and business schools in recent years, is not sufficient to achieve the kind of insight into the company you run today. Management is part science and a lot of art. I’d suggest that a practical and profitable investment among business leaders would be the development of a discipline of business historiography. This is the study of how histories are influenced by the times of the writers—a history of the New Deal era written during the McCarthy era will read very differently than one written in the 1970s. Why? Because each decade is flavored with a different set of hopes and fears. In business, each epoch in the life of a company is defined by very distinct priorities and, below those priorities a lot of different hopes and fears.
Would a company investing today in information technology to support organizational learning be treated very skeptically by an investor who, having lost more than a third of their portfolio value after the Internet bubble burst, prefers a company that “focuses on core competencies?” The resulting limits on available capital might require that the company’s initial information infrastructure assume that only email and database access is necessary to its operational success. Nevertheless, the addition of a wiki and other collaborative tools, as well as the staff to support them—not to mention the entire consultative services division that could evolve from the environment of learning facilitated by these tools—could accelerate the company’s growth. If, after making the case for funding to build these tools the company opts for a stripped down information infrastructure, shouldn’t the analysis of the opportunity be retained and literally taught to future managers? Successful companies, notably Royal Dutch Shell, have made a religion of these practices through the use of scenario development that incorporate these past lessons.
Every company needs to embrace these same critical practices, not necessarily in the guise of scenario development, but in terms of simply recording and talking about the tools they use, the compromises they’ve accepted, the blind alleys they’ve discovered and so forth. A business historiography will take all that data and perspectives gained over time to understand why some tools or features of information technology were chosen and others not to provide management with an evolving analysis of opportunities missed and those that are re-emerging as the company considers new tools and computational capabilities continue to evolve.
Where we’ve been and don’t want to go, again
In fact, to a very great degree, we are flirting with a type of dark ages in business and organizational thought, precisely because a great many people are more interested in imposing what they think is the right approach to group dynamics through the unenlightened use of technology. Invisible dogmas—unstudied and facile management fads or simple faith in a particular way of doing business imposed at some stage in an organization’s life—are akin to the religious fervor that laid civilization low in the early fifth century. Rigorous thinking was replaced by faith reinforced by dogma, which became unquestioned truth, very much like the company that, when asked why it does something one way and not another, responds “Because that’s the way we’ve always done it.” Alas, it’s not as easy to detect as religious dogma, because you aren’t asked to kiss as many rings as during a visit to the Vatican. But we all know from personal experience what it is like to be ushered into the mahogany offices of an executive who operates like the Pope, don’t we?
One of the reasons that invisible dogmas crop up so frequently is that the decisions that shape the future collection and processing of knowledge is highly political. It is often uncomfortable to ask questions of acknowledged domain experts that suppose they might be installing unfounded biases in a system of knowledge. Yet this is exactly what we 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, as well as by managers who are responsible to use the tools profitably, 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 available the invisible dogmas that they must create in order to get any working software into users’ hands.
If there is nothing simple in city government or academic bureaucracy (and there seldom is), then how do you codify the current state of a discipline, like accounting or quantum mechanics, in which the scope of the known facts is changing constantly and influential contributors can reshape a debate with a single pronouncement or finding?
This may seem trivial today, but for the future user of information or knowledge architects, the products of invisible dogmas will appear as incongruous as the discovery of an American Colonial musket in the midst of an Egyptian archeological dig. If a decision today doesn’t make complete sense today the results will become completely mysterious after a couple generations. When making our initial decisions about a technology we need to ensure that the rationales are recorded so they can be resurrected and reconsidered in context during future upgrades and at new junctures in the life of a company. Doing so will substantially reduce the cost and complexity of significant changes in a business process or a wholesale transformation of a company.
Simply put, the source of dogmas is our own laziness about addressing systemic issues in our organizations and in recording the reasons we do things within a company. We opt, for instance, for “collaboration” software to make people collaborate instead of teaching them to work together respectfully and constructively. We fail to appreciate how these tools change the requirements when hiring new employees, and often blame the employees when they fail to thrive in the stunted learning environments we’ve created. If management wants to take credit for success, the institutionalization of critical thinking about our choices of information tools is absolutely essential to the role of a manager in the information age.
The introduction of the printing press and the vernacularization of the Bible broke the back of the priest caste that dominated intellectual life in the middle ages, because they allowed the layman to think about and question the dogmas of the church. Today’s information-rich workplace is the institutional equivalent of the gothic cathedral and the mysteries of our tools need to be stripped away and made plain and comprehensible, which means managers have to lead the task of disseminating and thinking about the invisible dogmas that reside quietly in our tools but which have profound effects on the success of organizations. From the way we organize our companies to the tools we use to share information, the assumptions of the past must be questioned every day if we hope to building on the shoulders of the giants that have come before.
Posted by Mitch Ratcliffe at
03:04 PM
|
Comments (0)
|
TrackBack
