I recall somebody mentioning that the former definition for insanity is doing an action repeatedly while expecting different results. Among the interests that I have in organizations is how at times many organizations make the same mistakes; or how sometimes the same mistake might be made by a particular organization repetitively. So it is fascinating indeed when an airline facing an ice storm encounters much the same complaints from customers after a similar storm the previous year. I realize that some of the difficulties relate to how humans are creatures of habit and of social construction: the things that they do extend from tendency, indoctrination, and quasi-intellectualism rather than great thought. However, from an organizational level, I believe that impairment is sometimes data related. I don’t mean that there is necessarily any lack of data or guidance from the data, assuming it exists; but rather I refer to the real problem of accessibility. Not only is decision-making an “internal” process – that is to say, it occurs within people – but I suggest that data-perception likewise remains internal. Perhaps most people in organizations still perceive organizational events within themselves. How difficult it must be to externalize to structural capital.
When I first acquired my job, much of the work happened “inside the person”; this internal process generated little data. Creating a documentation trail – maintaining criteria that can be reviewed by peers – developing formal stages and flows in processing, these are all steps towards externalization. Externalization makes it possible for me not only to deliver more sophisticated products, but there is a truly noticeable process of change and development. If much of my work were to occur in my head, the persistent articles of business outside my body would be diminished. I can think of no greater damage to business development than insulating myself from the rest of the organization – rendering my thoughts largely inaccessible – thoughts that greatly influence my deliverables. Development can occur much more coherently outside the body.
A thought that occurs inside the mind depending on its purpose is sometimes described as an “opinion”; and if it is used to interact with others, it might be called “participation.” Within the context of a democratic system, people are expected to participate by expressing themselves; this little packet of involvement seems fairly coherent in that it can be attributed to specific individuals. However, in an organizational setting, attribution might sometimes be lost. I believe this is one of the main reasons why people keep intelligence to themselves; because once it exits the body, it is quite difficult to establish ownership. On the other hands, organizations seem to reduce the relevance of participation by recognizing it merely as opinion rather than as a source of intelligence. Ownership belongs to the organization where intelligence seems to magically appear out of nowhere. Externalization is impaired by these ownership dynamics.
I realize that I am offering a fairly complex narrative on why organizations might repeat the same mistakes. However, we have to accept the reality that every person who joins an organization will at some point leave; and if good ideas are not properly attributed, it seems illogical to have or at least express them – to externalize intelligence so that others can benefit. I guess “attribution” isn’t quite the right term. I don’t mean establishing ownership per se but rather ownership benefits. Sometimes the benefits are not aligned with ownership. Local police seem to routinely complain about the failure of particular communities to volunteer intelligence about criminal activity. Community members probably conclude that the potential for gain is quite poor while the likelihood of loss is relatively high. This is an example of how lack of beneficial attribution can both impair the flow of data and prevent development.
I remember when a sportscar snagged the bumper of my parked vehicle. I wondered whether it is truly necessary to report the incident to the police. My motto is that when unsure, go anyways. In order to file a report, a clerk at the collision reporting centre said that I had to sign a document allowing the police to obtain all sorts of data about me. Given that the police , by their own admission, don’t seem to have much knowledge of crime even in high crime areas, I found myself a bit surprised they might have some kind of specialized bureaucrat or data scientist fishing medical, police, and insurance records. Still, I didn’t have any concerns signing the authorization. It just seemed like a situation not of beneficial attribution but negative. When I finally got to see an officer to discuss my incident, he mentioned that I didn’t even have to file a report. “No way, my insurer made me think I had to come!” I said. It is not something he would have done in my shoes. Well, I don’t file reports for a living, I thought.
After my trip to the reporting centre, I returned to the office in order to work on my reports, which I guess I submit to people for a living. In fact, I recall my supervisor calling me the “master of reports.” I reflected on how the officer seemed real and authentic; in contrast, I found the clerk almost victimized by process. She was keeping way too much of it inside. I came to realize that the officer, while doing a fairly mundane job at the reporting centre, was successfully protecting his inner person. The clerk seemed almost psychologically deformed by her environment. It was at that instant that I understood how externalization represents a useful coping mechanism when the process is too big to hold inside. I habitually externalize not for beneficial attribution. Rather, I don’t want the process living inside of me and pulling me in. Indeed, I don’t believe that people are meant to hold vast amounts of data or even elaborate processes to engage data. Yet we still need to maintain and deal with data. Invariably, it is necessary to externalize intelligence and have a means of interacting with large amounts of it. I therefore offer some general thoughts on externalization.
1) Presumption of Complex Collaboration
My assumption when I go about a process of externalization is that I should assume my tasks will at some point be given dozens of people. The process should exhibit scalability. It should be possible for my coworkers to get together and perform my tasks – if they cooperate and have adequate preamble. Despite any apparent inefficiency, tasks should be broken up into smaller pieces such as stages. There should not be a huge leap from data to finished product. If such a leap were possible, the tasks would not necessitate collaboration. However, I should distinguish between a process meant for a group and actually making use of a group to do the process. I merely mean that I do not presume that the process will be handled by a single person.
2) Presumption of Relearning
Theoretically, an external system, process, or approach is something that I should be able to relearn. There are times where I might put a technology aside for months or sometimes even years. Externalization should make it possible for me to pick up where I left off. One of the reasons I believe the Java programming language has had so much support relates to how programs can be broken up into smaller pieces simple enough for a person to relearn. For example, although I write frequently about the Crosswave Differential Algorithm, this algorithm actually exists more in my sourcecode than my head. I literally have to refer back to the sourcecode to “understand” the material. My understanding occurs externally. I can only hold concepts inside me – usually not any coding specifics.
3) Presumption of Computer-assistance and Automation
I once did a job where employees were expected handle data by entering SQL code manually and directly to the server. There was no “front-end” to prevent coding errors. I consider this situation plausible for development but not for commercial operations. Surprisingly when assets mysteriously disappeared from clients, there didn’t seem to be a formal corrective process. Isn’t an SQL server an externality? Well, I agree that the server is external, but the service is internal. If employees have to form the code themselves, and they are responsible for handling the data from beginning to end, the processing system is leveraging much more on people than the reverse. So the fact that computers might be involved doesn’t mean that they are being used in a manner that makes the job easier and the outcomes better. Externalization should not force people to remember idiosyncratic details better suited for machines.
4) Presumption of Patterns
I make use of patterned coding. So it is rarely necessary to reinvent the wheel. When coding is patterned, it is possible to refer to it many years later and still understand what is happening. In other words, patterns help to enable externalization. Strangely enough, my experience is that people of similar minds tend to make use of the same patterns. Conversely, as I once said to a programmer that some people seem “plain messed up” in their thinking judging by their sourcecode. We both laughed at this crude pearl of wisdom. Some programmers seem upside down when writing code. But rather than question their styles, I am more inclined to question the absence of patterns. A person should program in order to understand his or her own handiwork. Patterns help to preserve the familiarity of code.
Perpetuation Through Ubiquity
The final part of this blog is difficult to explain without some kind of example. I therefore point to the computer in Iron Man. Iron Man is a superb externalizer. He does a fair amount of thinking outside his head. I know some people are going to say that my position is quite impossible since a person can only think inside the head. Wrong! A person can think outside the head if proper support systems are in place. The support has to be adequately abstract to enable its application to all sorts of data. The human mind should be focused almost entirely on concepts and interfacing; but this is quite challenging if the support is limited to a specific application. For example, assume that a transit system pays to have studies done on a regular basis. Each report is reviewed and then put aside. The knowledge becomes isolated rather than part of a ubiquitous system. This forces the human to read the report, evaluate it, and respond – a largely internal chain of events. I am not surprised when dozens of reports are produced all on the same subject, and yet the same problems keep occurring, or the status quo never changes.
I have what I consider a fairly ubiquitous system. I examine events using the Crosswave Differential Algorithm. I believe in my handiwork. So I don’t waste time mulling over things. The environment is designed to guide me. I stopped using the system for a few months last summer, and I actually ended up in the hospital. I am unsure if not using the algorithm had anything to do with me being in the hospital, but I certainly had no idea how I came to be in the hospital. One of the doctors was saying that I was probably the luckiest man alive; and that I should have died of a blood clot to the brain. He insisted that I should buy a lottery ticket. But was it really luck to push the boundaries – to exist in extreme improbability? Or maybe I was simply born physically disadvantaged, and something had kept me going? Well, after that experience, I decided to resume using the system. Now I am back to myself hardly thinking about what I do. I have a system that does the thinking for me. As I say, I concentrate on concepts and interfacing. And there are many complex concepts regarding its use such as the “Ecology of Truth”: the relevance of spectral distributions based on shock differentials. That’s about short-term versus long-term guidance based on the inclusion of differently timed events. Sure that probably sounds complicated, which is why I don’t do it in my head.
