In psychological warfare, we use the term grounding to mean a state of quietconfidence. Grounding comes from knowing "how things happen." And usually, you gain knowledge of how things happen through experience, including making mistakes, trial, and error.

Alternative Learning

There is another way to learn (rather than making mistakes), and that is through learning from other people. In order to do that effectively, you need two skills that most people lack: how to read between the lines how to take advice. A famous technical editor said, "People don't read," meaning that it's very rare to find someone who's really done his/her homework, reading technical publications and so forth. It is equally true that people don't listen to advice. Including you. Us, too. We all have to try harder to do these basics more effectively. They seem really simple, but most people don't acquire these basic skills in much depth, and therefore waste a great deal of time and energy by not benefiting from the knowledge of others.
The phrase "reading between the lines" is only a figure of speech. You don't literally read anything between lines of text. What you do is analyze what the author is saying at a level of detail somewhat beyond the surface discussion. To do this you need to use your knowledge, experience, and imagination.
Suppose you are reading a story about human experiences. Try to imagine how those people were feeling and acting that motivated what they did. Were they lazy, angry, ignorant, misinformed, or biased? Now read an article by a vendor or consultant. Is the writer competent to speak and act on this subject? Does he have an agenda, perhaps product or standards centric, and is he trying too hard to persuade you? How does what he is saying compare to your own experience and knowledge? Is he right or wrong or somewhere in between? When did he write this, and what was the historical context of these comments?
These are impressions that you should be able to pick up naturally while you read. Reading between the lines gives you the ability to discriminate what you will add to your knowledge, and what you will reject. Every piece has some good and some bad information. To win the psychological war, you need to know the difference, almost instinctively.

Internal Control

When a friend comes up with bright ideas, it's human nature to try to talk them out of it, because (psychologists say) we are trying to help them avoid being discouraged. We are helping them avoid discouragement by discouraging them verbally. Makes no sense, but most of us engage in this behavior unconsciously. It's natural. In order to change our behavior, we first observe "how things happen."
Similarly, taking advice is not natural. It just seems obvious that any mature adult knows how to take advice. But we don't. Not naturally. Normally, we all think that we know what we are doing. And that we can handle the situation with the force of our own will. In a sense, we mistakenly assume that we can control the world, even when we are in a brand-new situation where we don't have a clue "how things happen."
We use the term brain in gear to mean that you achieved a deep state of understanding (about a set of related topics), so that you can articulate your points very persuasively. A trial lawyer works hard to achieve the state of being in gear.

Expectation Management

Expectation management is one of the most powerful weapons in psychological warfare. In expectation management, we take our instinctual need to discourage other people's ideas, and we use the technique consciously, regarding our own ideas as we present them to other people.
The concept is simple. If you tell someone that your idea will deliver wonderful benefits, and it doesn't, then the person will be dissatisfied. And you lose credibility. However, with expectation management you carefully articulate the potential good and bad outcomes, even emphasizing the negatives. Then with the same idea and same outcome, the person will be pleasantly surprised. You delivered more than they were led to expect! Congratulations.
This technique is essential for group dynamics (e.g., meetings). Always promise less than you can actually deliver. In meetings, tell people clearly what you expect them to do, explain the caveats (i.e., expectation management), and they will often overachieve. Expectation management is used in a convoluted form in software product marketing. Since marketeers are selling to the customer's needs, an inflated product image is created. This is called the expected product. People buy the expected product because it appears to meet their needs. What they actually buy is the generic product, which is what the vendor can deliver. In marketing terms, "crossing the chasm" is the transition from a customer base who will buy based upon sexy technology expectations to customers who will buy based upon real-world quality to satisfy needs. If the product is successful, there will be time to enhance it to actually meet expectations. The product can then become an augmented product through extensions and up-selling options. However, this standard model for software marketing almost always leads to disappointment.
Ideally, expectation management is a form of truthful disclosure. By telling people the truth about the potential outcomes, you establish a psychological framework of expectations. In reality, you can contribute to causes but you cannot control the absolute outcomes. If you do a good job, you are contributing to the desired outcomes. And chances are you'll be able to deliver upon expectations, most times. If you don't manage expectations, then you will underperform in people's perceptions, even with the same outcomes. We highly recommend that you apply expectation management; it is a technique that we use every day.

Psychology of Truth

It is important to understand the meaning of truth, and how to use it, as the basis for your psychological warfare. In an absolute sense, everything that you know is an abstraction of reality. We could say that "everything you know is wrong," which is true in an absolute sense, but not very productive. Thinking more constructively, we can describe our understanding of reality as a set of patterns and models. These patterns and models are an illusion (or, more accurately, a self-inflicted delusion). For example, one can say: "History never repeats itself," which is true in an absolute sense because the world is always changing, always progressing in time. Or so we think.
Software architecture knowledge consists of models. In the hard sciences, it is common knowledge that nature knows nothing about physics. Newton's models for classical mechanics are wrong, when taken out of context. So are Einstein's theories of relativity. However, within their intended contexts, these theories are accurate descriptions of how things happen in the universe. Research in design patterns and AntiPatterns explains why these models work in practice. With the right context and forces, the appropriate model for the solution usually works and produces predictable outcomes.
Despite its weaknesses, classical mechanics is the theoretical model behind numerous human achievements, including rocket science, machinery, buildings, and bridges. In proper context, Einstein's theories accurately describe nuclear energy and near-lightspeed digital communications in distributed systems.

Perception Is Not Reality

It is essential for you to understand some important aspects of mass psychology. Most people believe that "perception is reality" and "seeing is believing." And there may have been some time, before technology, when that was a reasonably effective way to think. But it is not so today. Perception is not reality because technology can falsify perceptions. Technology can create powerful illusions. And especially with computing technology, illusions are becoming easier and easier to manufacture.
For you as an architect, the ability to envision new illusions and impress them upon people's imaginations is vitally important. The architect works in the gray area between intuitive perception and the logical certainty of software. In order to translate intuitive system concepts into software reality, we must have a talent to envision architectural structures. Then we must be able to document these visions and articulate (explain) them in a way that sells the concepts to other people. In other words, we start system envisioning by creating an illusion, and then proceed to architect the system, providing more and more depth to the illusion, until it appears obvious what the system is about, why we should build it, and how it can be realized.
Not all system illusions are worth building even if they are very "sexy." It has been said that "whatever man can see and believe, man can achieve." Software development is an ideal refutation of this kind of wrong-think. A great majority of software projects envision illusions that cannot be effectively realized. In effect, many software projects are subject to the illusion of "imagination run rampant." The architect is responsible for moderating this situation. The architect has the power of imagination, like most people, but the architect is also responsible for managing risks, both technical and peopleoriented, that could impact project success.
In an often-used analogy, software efforts are like building different types of cars. First we build a Ford Pinto (or Yugo). The system does something useful, but the engineering and manufacturing are not superb; in fact, they are just the opposite! Often the system does not meet the full expectations (system illusion) of the users. But in the eyes of the developers, if the system actually works, they gain much confidence and are ready to try again with much more ambition. When the team tackles the next system challenge, it builds a Cadillac with all the bells and whistles. With encouragement from the users, the system developers create overly ambitious requirements that cannot be effectively realized. Cadillac projects are likely failures. The project bogs down in trying to create too complex a system; the effort lacks focus. After this failure, the team takes a much more sober approach to the next system. This time they envision and build a Volkswagen Beetle, a modest system, but very practical and well engineered. It meets human needs and works reliably. That's the whole point.
As architects, we want to facilitate our projects to avoid these extremes. Architectural planning creates a solid system structure that goes beyond the engineering limitations of the Pinto/Yugo. We give the developers an excellent chance to avoid this phase of system evolution. We also argue against building the Cadillac system. We want to advise our colleagues to be practical and avoid the pitfalls where so many other projects have failed. Ideally, we want to design and build the VW on the first attempt. Sometimes you can't talk people out of making these classic mistakes, so you may get forced into building the Pinto/Yugo or Cadillac. At this point, it is okay to make your opinions well known, perhaps vehemently (we favor the adult-assertive approach). If they don't understand your concerns, then document them clearly and move on to new challenges. Do not dwell on lost battles or try to undermine the committed direction of a project, whether you are right or wrong, once you have lost the argument. As a computer scientist once said, "It is the fate of competent advisors to have their best advice ignored." As you already know, people don't listen.

Exploiting Human Weaknesses

One of mankind's greatest psychological weaknesses is that we jump to conclusions too easily. Competent software architects can turn this weakness into a strength for their software organization and the software industry. By creating compelling reference models of software knowledge, we lead our organizations to the appropriate conclusions.
Software architects command extensive knowledge about software technology, software organizations, and real-world business processes that our systems support. Knowledge is power—in this case, the power to change perceptions. For most people, perception is reality. Reference models are the pattern of the solution for transforming perception into real-world success. Let's explore some examples.
Reference models are commonplace in other fields of human endeavor. They facilitate successful practice in sales, investment, journalism, public relations (PR), economics, psychology, digital hardware design, and consulting. A classic sales reference model is: person, organization, goals, and obstacles (POGO). The analogous reference model for investment analysis is: strengths, weaknesses, opportunities, and threats (SWOT).
Journalists and PR professionals use a reference model comprising six questions. These reference models provide an invaluable structure for human discourse that assures quality. Interestingly, many of these models have been incorporated into software standards and practice. For example, the Zachman Framework adopted the journalistic reference model directly. The Reference Model for Open Distributed Processing (RM-ODP) assimilated models from economics and psychology to standardize software architecture viewpoints.
The Hardware Design Level Model (HDLM) has been used in digital engineering practice for more than two decades. HDLM separates design context and forces, so that every EE student learns in college how to design and optimize digital logic circuits with relative ease. Reference models simplify problem solving, so that ordinary professionals can practice their disciplines with world-class results.
Hence the contradiction: Why haven't reference models been used to structure effective software practice? In our opinion, the most effective reference models are unknown by the profession and academia—for example, the Software Design Level Model and RMODP. Other powerful reference models have been imposed with unfortunate consequences. For example, Capability Maturity Model (CMM) certification has become the software equivalent of the Spanish Inquisition. Articulating reference models so that they assist in individual decision making is a kinder, gentler way to reform software practice, and ultimately more effective.

Reference Models as Perception

Applying the classic reference model for consulting intervention, there are three basic questions that the readers (software architects) should consider:
1. What is the problem? Reference models are basic intellectual tools that are virtually nonexistent in software practice. Effective reference models exist but are relatively unknown by the profession. The corpus of software knowledge is not expressed in terms of reference models. The lack of reference models inhibits our profession from separating design forces and evolving software into an engineering discipline with successful, predictable outcomes.
Software professionals need reference models in order to understand abstractions. For example, the founders of the software design patterns movement (The Hillside Group) have claimed that four out of five software developers cannot abstract effectively. Only 20% of adults have the appropriate world-perspective to define abstractions. Reference models are a necessity in the confusing, rapidly changing technology environment in which we practice.
2. What are other people doing to contribute to the problem? The hard technology problems addressed by reference models are "application problems"—a phrase vendors repeat laughingly, all the way to the bank.
3. What are you (software architects) doing to contribute to the problem? This question leads to a Gestalt turnaround: What can we (software architects) do to resolve the problem? We can learn the available, effective reference models for software. We can educate and evangelize the profession toward the use of existing, effective reference models. When we see an important issue unresolved by available models, we can create a new model, optimize it, and contribute it to the corpus of software knowledge. The instantaneous global reach of the Internet make this imminently feasible. We can mentor our peers constantly about reference models, design patterns, and other forms of software problem solving. We (software architects) can take responsibility for our part of the mind-boggling problems and opportunities that the software industry is confronting. Through the articulation of reference models, we can help the software profession become more enjoyable and successful.

Biological Response Model

One of the most universally useful reference models describes biological response. This model shows what happens as a biological system is stressed to various degrees. It can be used to describe how people behave, psychologically, when stimulated, and how people can change their minds or behaviors. It is also a good description of how you might respond to external stimulation, so with an understanding of this model, you can choose to follow your biological instincts or choose another path.

The biological response model works according to various stages of excitement. Initially, if the stimulation is small, it is ignored, either deliberately or unconsciously. Consciously our response might be: "It's not important" or "I'm ignoring it." Biologically we are drawn toward small stimuli.
As the intensity of stimulation increases, our attraction changes and we are increasingly repelled. The next level of psychological response is denial, or deliberate ignorance. In denial, we deny the truth or existence of a stimulus event. We turn away from it. We do this automatically; it's human nature, which makes it very difficult to control this part of the response.
As stimulation continues to increase, so does excitation. When a stimulus becomes impossible to deny, we become angry—or joyful—depending upon the situation. It is not possible to maintain a high level of excitation indefinitely. So, in short order, psychological energy is released, such as an angry display or laughter. If the stimulation persists beyond a state of excitation, then we experience depression (sadness) or a state of acceptance. Further stimulation above this level of intensity can be fatal.
In psychological warfare we use the biological response model to our advantage, because for most people these are automatic responses of which they are not consciously aware. In fact, some people are so unaware of their own responses that they may not even know when they are angry, until they erupt in an excited frenzy. "Gone ballistic" is the popular phrase for this behavior.
We use this model by adjusting the intensity of our architectural evangelism according to the situation and desired outcome. In some cases, we want to get something accepted without much controversy. This is called "flying under the radar screen." We keep the message at a very low level of intensity and mention the matter infrequently. In some cases, we want people to take notice and to change what they are doing in accordance with our ideas. In this case, we may want to push them right over the top of the model and get them very excited about the concept, with a goal toward changed behavior (acceptance instead of ignorance or resistance).

Group Applications of Response

The biological response model can also be applied to the facilitation of groups, although we are straying from the biological origins of this model when we do so. In theory, each of us individually has a group inside our minds, formed through early childhood experiences. This reference model indicates that we all have interactions between members of our internal group. Real groups are the extension of this concept into interpersonal interactions. So we use these concepts to explain that, if the response model applies to individuals, then it can also be extrapolated to groups.
As the model implies, people often get excited about something before they change their behaviors and accept it. Laughter is one way to push groups over the top and into release and acceptance. Laughter is a great way to diffuse successful situations and win arguments. The experience of laughter involves a high level of excitation and leads to an immediate release of stress (i.e., exactly what we're seeking). Some of the best comedy is self-effacement—in other words, making fun of yourself. Watch standup comedians on television to learn more. Particularly watch for humor based upon self-effacement. Also, the worst kind of humor relates to human body parts. You will see professional comedians use this kind of humor too often for their own good. Avoid this kind of humor at all costs, for reasons such as political correctness.
In groups, we tend to link response models together, so that we create waves of responses. Since death is seldom an option, we continue beyond each state of acceptance into a new curve of excitement. Repeatedly we want to bring individuals and groups to a high level of interest and excitement, make a decision, then move on to the next matter. Meeting facilitation, covered in other chapters, uses the principles of biological response with groups in this way.
We use meeting breakouts to enable people to create something (anything as a first draft), so that they often have ownership and are excited about defending it. It also gives us a starting point for discussion, even if it's bad. We then give them their chance to defend it in public. That's very exciting for the presenter. If the presentation provokes a response from the audience, then he or she can become very excited too. Good things are happening. We have experienced group excitement in very positive and negative senses. Either way is equally beneficial from the facilitator's perspective. In either sense, an excited group is a group that can make decisions and implement choices vigorously. The last thing we want is a group that's falling asleep. In that case, behaviors won't change and little progress is made.

Reference Selling

One of the ultimate weapons in psychological warfare is the power of illusion. In this warfare we prey on human weaknesses with positive intent. Suppose we had to sell a 10-million-dollar software system (i.e., very expensive). The buying authority for such a product may not even exist entirely within the IT community of the organization; perhaps it resides in the Chairman of the Board of Directors. But even more important than influencing the Chairman will be justifying the sale to the organization, so that the executives have a clear indication of need. It's a lobbying effort on a massive scale, because no one individual needs (or can justify) the whole system, but each may benefit in his or her own way from the purchase.
This kind of salesmanship assignment is a primary activity of software architecture, as it is for software salesmen. But the need to "sell the system" may be just as great for the architect. And the situation, as we have posed it, is within the scope of the kinds of "organizational sales" that software architects participate in and sometimes lead.
The trick for making such a large sale is in the sales pitch. First, you need multiple points of contact in the organization, ideally representing multiple chains of management. We want to talk to each point of contact with the intent of achieving two key things. The highest priority is to convince them that what you are selling is what they want. Then it is important to get them to articulate that need. We will use that information later. Then you want to get additional referrals to other people in the organization. If you succeed with your first contact, you are well on your way. You have a successful sales pitch. However, it often takes three to six months to complete business on this scale.
We use the referrals to lobby additional points of contact in the organization. Remember that leaving a voicemail is not good enough. We need to get them on the phone and/or meet them in person to deliver our pitch. On the second and subsequent contacts, we use the fact that earlier contacts indicated "need" for the product in order to convince our current prospect that it's a growing wave of demand within the organization.
We are telling the customer that it's safe for him/her to support this purchase, because many other people already do. It's a done deal. It's a fait accompli. Real salesmen will stretch the truth (via careful articulation) just a bit in order to make their point. In other words, this is a form of namedropping, with a systematic intent. What's important is that we are using the power of illusion to create and consolidate demand for our product.
We are describing a systematic sales process that is used by some of the world's largest software companies, called "reference selling." The software architect should be aware of how this process works, both in order to resist its influence from the outside (if necessary), and in order to use the process to build consensus on the inside of the organization (when needed).

Psychology of Ownership

With individuals and groups, a very important concept is ownership. This is using the "not invented here" syndrome to our advantage in psychological warfare. Ownership can take a long time to develop but is a very important concept for the architect to foster. Ownership can be much more easily eliminated than developed.
Ownership can be quickly eliminated if there is one "know-it-all" person who overrules and makes all decisions on a design or project. For some naysayers, this is the definition of the architect's role. To avoid this perception, the architect cannot be a micromanager. The architect should focus on architecturally significant questions and delegate engineering design questions to the responsible developers. In this way, individual developers acquire and control ownership of their own design space. Interfering with their design decisions, without an overwhelming reason, can be deadly to a project, because it destroys ownership.
Smart people know how to give someone else an idea. This is the key to ownership on the personal level. On most projects there is a "customer," someone who literally owns the project from a financial or responsibility perspective. Many customers are quite insistent that their ideas always take precedence, even if they are not qualified on the technical subject matter. Anyone else's "bright idea" can be either accepted or discarded, based on their whim or fancy. As an architect, you need to be sensitive to this phenomenon. There are some arguments which you can't win, no matter how right you are, because you don't "own" the project. It is not your money being spent, for example.
You must learn to let go of certain cherished ideas, if you can't win over the real project owner. In our work experience, this situation will arise most frequently when there is a direct family relationship between the real project owner and a team member. Many good ideas will get overruled because the family member disagrees—whether or not he or she is really qualified to do so. This is a good example of "life is not fair." And it is something that you will have to live with, unless you leave the project.
Ownership is best fostered in a relationship of trust among the team members and the architect. There must be a division of design responsibilities if there is to be both ownership and quality design. The architect is responsible for architecturally significant decisions. The other team members each have assigned responsibilities. If everyone contributes, and is told how important his or her contributions are, there is the proper environment for establishing a sense of ownership. Ownership requires respect for all team members, no matter how large-scale or narrowly focused their responsibilities are. In the psychological warfare over ownership, the desired outcome is long-term peace, with mutual respect and trust. A powerful weapon in this battle for peace is showing that you care about team members and their ideas. Some might call it affection or love.
People won't listen to you until they know you care about them. Psychologically, what people want most is "to know that they matter," that you think their ideas are important and worth considering, that you think their contributions are essential to the effort. This feeling of mutual respect should be fostered at every opportunity. Showing respect for team members often results in reciprocal feelings for the architect. We use these concepts often in our own daily lives.
Some architects do rule by ego. They do their best to dishonor and discredit other people's ideas through political techniques and/or meeting confrontations. And they can be very successful, professionally. In the wake of such people you will find many discontented persons, crushed by the overwhelming ego. This fosters feelings of resentment which are long-lived, well beyond project completion. We do not like working with people like this, although we have had plenty of experiences with such people. You will have to make your own judgments, if this is your style of interaction. We do know that the person who rules by ego destroys ownership intentionally. And we think that practice is counterproductive.

Psychological Akido

Being an architect is a tough job. It can be particularly challenging to your psychological health. It is difficult to stay positive and happy while it sometimes seems that the whole world is upon your shoulders. And bad things happen all the time. It can be quite frustrating at times. Most adults experience frustration often; statistically, a typical adult gets angry about 10 times every day. That's normal psychology.
The common man, inexperienced in psychological warfare, is constantly trying to get himself out of trouble. As experienced warriors, we embrace trouble as much as we embrace success. Good and bad things happen. Most of the events are of small consequence. And many events are out of our control. To be happy in a world of trouble, we must learn to let things go that we cannot control, and to contribute to the success of those events that we can influence.
To acquire the ability to endure bad events and remain happy, we use a philosophy of personal expectation management. We try and try to create success on software projects. We try and try to help our peers and colleagues achieve career and personal success. But in our personal expectation management, we expect nothing—no change in outcome, regarding our involvement. Like medical doctors, we try to do no harm. But there are times when good work leads to bad outcomes, too. It's the luck of the draw. Every day and every decision is a gamble. When nothing happens, great! It's just what we expected. When good things happen, great! It's a pleasant surprise. When bad things happen, there is often a much greater opportunity to be exploited. We should look for it and attempt to bounce forward, instead of being discouraged.
We learn the most from our mistakes, and the least from our successes. Not that we seek to fail. With an attitude of personal expectation management, we don't expect our strategies and patterns to work. So we give it our best effort, acting as if it won't work unless our input is perfect (in a time-bounded sense, of course). For example, suppose we are applying a software design pattern to one of our architectures. If we make a halfhearted effort to apply the pattern, it's very unlikely to generate benefits. Developers will easily ignore it or misuse it so that the benefits evaporate. If we apply the pattern with a reasonable effort, reasonable documentation, and so forth, we are assuming that good things will happen, and with luck the pattern will generate benefits. Developers might understand exactly what we mean, and even add value to our pattern application. We think this is wishful thinking in practice. Finally, suppose that we decide to use the pattern, assume that it's likely to go wrong, and apply it with exceptional care and due diligence, documenting and communicating clearly our intentions to the developers. Even though we expect nothing, we have given the pattern the best chance to perform its function. If nothing good happens, so be it. If it works, that's great, and a very pleasant surprise.
In Psychological Akido, we apply these philosophies in terms of a process of learning. We expect both good and bad things to happen as a result of our architectural work. Our goal is to understand "how things happen." MBAs learn that good things happen when you pull the "action lever." An action lever is anything that you or your project might do to effect change. Unfortunately, we live in world of confusion, of increasing change and information overload. Seeing the action lever is difficult and often requires experience and expertise. That's why companies hire expert consultants; they know where the action lever is. An architect plays this role as well, within the scope of technology and system building.
When good things happen, we have found an action lever, perhaps by accident. The cause may not be immediately obvious. We try to apply the same techniques again in a systematic, experimental way, in order to refine our knowledge of the action lever. When bad things happen, we learn even more. We have found one or more destruct button, which we must try to avoid on future trials. As experience progresses, we learn to avoid the destruct buttons and pull the action levers, becoming more effective.
It is interesting to note that the process of learning to use a computer involves these principles directly. In one dramatic experience, we once took a programming class for a new operating system, in beta test. The software had many defects, as all commercial operating systems do, but these defects were much more prevalent than most of the class had ever encountered (in a near-production release), all of us being experienced software engineers. Because we had not learned the destruct buttons of this new software, everybody experienced frequent crashes, requiring reboot. About 30 reboots were needed on the first day alone, as we attempted to perform simple tasks. The situation reminds us of when we put noncomputer users in front of a demonstration, and they break the software within the first few keystrokes—a well-known phenomenon. In our rebooting laboratory, we learned to "do this and this in a specific order" and "not ever do that," plus remove an erroneous file or two after rebooting. Overnight, many of us thought that it was hopelessly buggy software. By the second day, all students had cut their rebooting needs in half. And we were able to perform more sophisticated programming tasks than we had attempted on the first day. By the end of the week, we were able to perform extremely sophisticated programming tasks, with virtually no rebooting required, except when we chose to reboot intentionally. We had learned the action levers and the destruct buttons. Most surprisingly, we didn't have to think about it; we did it naturally, as we had internalized this knowledge about how we used the system. On reflection, this experience is common to people who use computers. This was just a dramatic example of experienced software engineers repeating the process for new software.
Psychological Akido is much the same, but instead of learning to control a machine, we are learning to survive the psychological warfare that is life. As architects, our life stresses are significant. We use Psychological Akido to help us to cope with life and to learn to perform better and better. Psychological Akido is our quality control process for psychological warfare.

Intellectual Akido

Psychological Akido is a defensive strategy that works on a personal level. It guards us from the insane situations and environments that we often encounter in our profession. As architects, we should attempt to do more than merely protect ourselves. We should try to help others to grow professionally and personally.
Intellectual Akido is an extension and scaling up of the former practice, to affect many more lives and change the way that people do software. In a sense, the goal of Intellectual Akido is to make the world a better place. Mentoring individuals one by one, we can have some limited impact, perhaps helping a few dozen people over a lifetime. In Psychological Akido, our scope can be much more ambitious, possibly affecting thousands of lives directly.
We apply Psychological Akido as a front-end process, gathering knowledge from good and bad experiences. The next step is to transform our positive experiences into patterns, in the "software patterns" sense. We want to find practices that repeatedly work, so that we can share them with many others. Initially, we prove to ourselves that the patterns work, by applying them in our own work. Then we mentor other professionals to do the same. We learn the ins and outs of the new technique.
When we are satisfied that the quality of this knowledge is worth sharing on a wider scale, we shift knowledge-sharing strategies. We transition from one-to-one sharing (e.g., mentoring) into one-to-many sharing. This transition is an essential idea for affecting the practices of large groups of developers. Suppose you were an enterprise architect or a Chief Information Officer. You would have to execute educational and administrative strategies that change behaviors on a mass scale. One-to-one mentoring simply wouldn't work.
One thing that you must do is to generate documentation. A useful first step is a set of tutorial briefing charts. With these charts you can project your message to groups ranging from a half dozen to several hundred people. The experience of teaching and answering questions will focus your knowledge of the solution and how it is executed. In a sense, you are providing many shortcuts for your student's own Psychological Akido process. You are telling them explicitly where the action levers are, and what to avoid in terms of destruct buttons.
In many cases, some 5% or more will listen carefully, learn the new patterns of knowledge, and apply them to their own work. According to the Nolan Curve, a classic learning theory, if 5% of your skill base can successfully apply much more effective practices, the other 95% will eventually migrate. Within a single organization, a tutorial may be sufficient to effect the required change. Ideally your tutorial includes an even balance of lecture, experience, and feedback (e.g., discussing their experience). From a training perspective, what the students do successfully in class, you can expect them to do on the job. Experience, such as programming laboratories, is vital to their effective knowledge acquisition.
To affect a large group of developers, you need to go further in your knowledge dissemination. A magazine article is a wonderful way to communicate to very large groups. It's wonderful because it's a relatively short-term commitment on your part, and the rewards of professional recognition are superb—almost as good as writing a book. Magazines are continually seeking talent, and if you have something that really works in this chaotic software industry, the knowledge is probably well worth sharing. Posting the same information on the Internet is useful, but not nearly as persuasive as the magazine format.
Everything we have done so far in this process has affected many lives. But the impacts are transient, at best. The tutorial helped us to focus our ideas and develop the verbal articulation of the ideas which is necessary to communicate the message. To create permanent knowledge we must go further. In particular we are talking about books and standards. A standard is a documented technical agreement. It has great moral hegemony. Most standards focus on detailed technical solutions that are intended for vendor implementation. If your ideas are applicable, this is a reasonable mechanism to pursue, given its shortcomings—primarily compromises and long delays. We do not discourage standardization, since we have pursued this approach on a number of occasions.
A book defines intellectual standards. Note that the role in society of journalism and publishing is to confer credibility upon authors, people, and organizations. A book is the ultimate form of journalism. It yields substantial credibility, as well as professional recognition. Hence the phrase that he/she "wrote the book." It is also said that "he who writes, writes history." Exactly. The book author is in a unique position of defining a new ground truth, a new reality—new ways of thinking and perceiving that are a permanent part of human history.
For example, many more people (perhaps 1000 times) have read our books on CORBA than will ever read the standard. It is an awesome responsibility. As architects involved in the CORBA standardization process, we use this authority to articulate the technology in a way that is more effective than the standards alone. If you study this situation, you will discover that there is a great gap between what can be readily assimilated (and what is useful in practical applications) and what appears in a typical standards document. A standards-oriented book resolves this gap and makes the technology usable to much greater numbers of developers.

Winning the War

After the book, the job is not nearly finished. As a result of the book, good things happen. In our early book experiences, we were surrounded by naysayers prior to publication, and they all disappeared around the time it was published. They quit their jobs or were transferred into obscurity. Miraculous, to say the least. We were asked to do many more tutorials, worldwide, and to write magazine articles—an almost endless demand for knowledge and wisdom. You can leverage your newfound popularity to enrich your business, or you can go further in the process, which is not nearly complete.
The transition from grunt to expert began on the day you stepped up to the podium and gave your first tutorial. You became the expert (whether you deserved it or not) because you had the courage to put yourself on the front line for the sake of your message. That warfighting spirit can carry you through step after step of Intellectual Akido, until you are affecting many people's lives, and making the world a better place. According to surveys, public speaking is the number one fear for most adults, more so than death. Since you were able to overcome a fear worse than death, you have earned the "right to speak" and a position of respect and authority.
As you travel about the world sharing your message (post book), two important things happen. First, you learn to articulate your message an order of magnitude better than before you wrote the book. You grow and transition from imparting a little bit of knowledge (which everybody knows is dangerous) to communicating lethally effective practices. This newfound confidence does not continue forever, so enjoy it while it lasts. Second, you gain a much deeper sense of how things go wrong by applying your knowledge. What are people's basic misunderstandings? How did they try and fail to succeed?
A second book, describing the AntiPatterns of the misapplication of your ideas, might be an appropriate follow-on. This will help many more people to avoid the common pitfalls. Also, you have gained much more knowledge by following through with this process. Since you have so much more to share, someday you may want to write again—and repeat this final step in the process.
As a series editor, and an advisor to many authors, I always tell them: do not be afraid to share everything that you know about that topic. Be generous with references and citations. The emotional instinct is to hold things back. Save some key bits and pieces for myself, so that I can make money. Not necessary. Not even close. In Intellectual Akido our philosophy is to give it all away. And when you give it all away, you gain so much more. Because there are so many people in this industry who try to hoard their knowledge, the Akido practitioner is a welcome and refreshing alternative. It is also a principle of entertainment, that the actor/actress who gives everything on stage is the most appreciated. The more you give, the more people will enjoy and benefit from your message. And you will grow in knowledge, much faster than anybody can attempt to "catch up" to you.

Winning the Peace

Most of the people capable of "catching up" to you technically will probably scoff at your work and not bother reading it anyway. That's one of the unpleasant shortcomings of this way of life, but probably unavoidable. Professional jealousies will arise. People will be on your case because they feel resentment about your popularity and success. Luckily, there will be few and infrequent encounters. Be sensitive to this.
To follow our way of coping, you must become a kinder, humbler, and nicer person. Do not give these people a reason to criticize you. Never win an argument by implying that, "I wrote the book, so shut up!" Never brag about your accomplishments; let others do that for you. Win by explaining your ideas, which by this time are very well thought out. Let naysayers make up reasons to dislike you, and eventually they will fade away. When you must go up against these people, stay off "front street." Let other people do your talking, while you quietly work in the back room writing the architectures and specifications, doing work that you love.
As your success grows, some of your peers will want to beat you up for any number of reasons. You may have become the symbol of a technology that they don't like. You may be a competitor to their business or their ego. You can attack them head-on, but we wouldn't recommend it. We have tried and failed using this approach.
What's much more effective is an age-old secret of psychological warfare. Be gracious. Turn the other cheek. Most outside observers won't see the situation in terms of issues; they'll interpret a confrontation in terms of personalities. If you are the cool guy (or gal) they'll see the other player as a hothead—someone who is venting anger, not someone who is rationally motivated. We were cheered up, after a recent scuffle, when one of the observers commented that: "At least Tom Mowbray is cool." Remember that "the people have the power," not your hotheaded peers.
An even deeper warfare secret, which always works, is a four-letter word. Love. It's almost unbelievable, but this word has the power to erase all bad feelings, and reverse insurmountable conflicts. We have seen it work for us in recent days, resolving impossible situations that most people assumed would be protracted indefinitely in the fires of war. If you know someone well, it is perfectly reasonable to wish them well and send your love and respect to them and their families. Do it. Don't hold back. Express your feelings honestly and sincerely. You don't need to say much. Once is sufficient. And it is merely a small personal gesture. But it is the key to winning the peace. This is the ultimate weapon of psychological warfare.

Getting Ready for Psychological Warfare

Psychological warfare requires essential skills for maintaining your own peace of mind and affecting the world about you. As a software architect, you endure tremendous psychological pressures which you must manage, both for yourself and your software organization. Using these techniques, you can progress from small successes to global influence. We emphasize that you should apply these powerful techniques "for the right reasons." Hopefully, your number one motivation for being in this profession is not to make money. To be a true professional you must love your work.
We can unkindly describe the person who's in this business only for the money as a confidence trickster. Another popular terminology for describing these sorts of people is "trough guy," as in a pig trough. We fully understand that there are some roles in the IT business where this way of thinking is appropriate, such as sales engineering. And we have seen several friends follow this path, which leads to quite abrasive ways of interacting. But we take strong exception to this attitude in software architects. It is simply bad behavior and highly inappropriate to attain success as a software architect.
In our philosophy of software architecture, we don't use psychological warfare for purely personal or selfish reasons. These techniques are strictly apolitical. Both good guys and bad guys can use them. And nobody is either all bad or all good. To be the good guys, and do our jobs properly, we must be sophisticated about psychological warfare techniques. We use this knowledge to defend ourselves, defend our projects, and make progress in otherwise intractable situations.

Exercises

Exercise 1

You will need two 15-minute segments of time to complete this exercise in "reading between the lines." Select a historical or fictional book that you might consider to be rather dry reading material. Depending upon your tastes it could be the Holy Bible or Catcher in the Rye. Find a story about people, and read a paragraph or two carefully. Think about what was it like to be those people. What motivations could they have? What pressures were they under? What do they want and why are they doing what they're doing? Use your imagination to fill in the details of their lives that further explain and enlighten the story. Have someone ask you these questions about the story and hear what you come up with.
Now select some technical reading material, perhaps a recent magazine. Pick articles written by vendors or consultants, individuals who are likely to have an agenda (selling something) for writing the story. Read a few paragraphs and think about them. Why are they telling you this? What is their agenda? How does their message compare with what you already know about the topic? Did they neglect to mention something germaine to the topic? Do they claim something which you suspect is misleading or blatantly false? Did they include proper citations for verifying their claims, or are they vague about their sources? What is their surface motivation, e.g., telling you about the Java language? And what is their true motivation, e.g., selling you their Java tool by telling you how hard your work will be without some great tool? This is an exercise in subtlety. You are learning to perceive beyond the surface content and get into the author's head. What you know from your perspective is equally as important as the content that you are reading. Most messages that we encounter every day come from biased sources and there is a hidden agenda for sharing this information—for example, advertising and commercials. But more important, much of what you assume is unbiased editorial content (e.g., newspaper stories) is actually based upon press releases from highly biased sources. In fact, some large software companies have hundreds of public relations agents feeding information to the media as quickly as they can assimilate and print it. This is the world of managed perceptions that we live in. Either learn to see through it, or be misled by most of what you read.

Exercise 2

To learn the concept of internal psychological control, there are a few things that you can practice all the time to consciously modify your natural reactions. When someone comes to you with a technical idea, it is natural to try to talk him out of it. We naturally want to discourage people from attempting things that lead to disappointment. In this exercise, try to spend a whole day encouraging people, instead of discouraging them. Before you reflexively blurt out your discouraging message, STOP! Take a breath. Think of a positive message, one that will give them ownership and permission to try it on their own recognizance. This exercise is about changing your own behavior. This discouragement behavior is one of the most obvious natural reactions, so we use it as a classic example which you can work on. Unless you are in a high light environment, like San Diego beach, most people don't smile as a regular habit. In this exercise, try smiling when you encounter people—friends, acquaintances, and nonthreatening strangers. Inside your head, the message you want to convey with your smile is, "I want you to know that you matter and I care." This conscious modification of behavior will have a positive impact upon the people around you. You'll be having a good day, and you won't know why. There is a distinct difference between what we would do naturally and emotionally, and what we should do for ourselves, our friends, and our businesses. Psychologically, we may be stressed out, we may be frustrated, we may want to lash out at people emotionally, sometimes for the slightest implied insult. In psychological warfare, we know that it is "always a mistake to take things personally." Before we react emotionally, internal control should kick in, directing us to respond, not react. By responding with internal control, we can maintain important relationships in our lives and our businesses, which might otherwise be destroyed in a few heedless moments.

Exercise 3

Try the following. Soon. Suppose that you know that you are about to be asked to deliver something, and you are on your way to management to discuss the details. In this exercise, we apply expectation management to our commitment for delivery.
Let's say that you think it's about one day's work, but you're likely to get interrupted and miss a one-day deadline. You believe that if you had two days, you could easily complete the task and deliver. And in three days you could deliver a gold-plated high-quality version.
When you talk to management, I would propose three days, initially, and claim that, "I'll be able to deliver what we basically need by that time." If management balks, and claims they need it in one day, I would tell them the truth, with a bit of underselling. "I really need two days to do an adequate job. I'm very likely to get pulled off into other tasks during those two days, so it will be a struggle." If they absolutely insist on one day, tell them the truth again. State your conditions. "The only way I can deliver is if I get absolutely no interruptions. The only way I can ensure that is if I work at home and unplug the phones."
They should buy on this basis, or find someone else to do the task. So, worst case, you get to spend a luxurious day at home. Take a long hot bath. Do a few hours of uninterrupted work. And take the rest of the day off. Worst case. More likely is that you'll get your two days, they'll expect a minimal job, and you'll deliver a more-than-minimal product, exceeding expectations. You'll be a hero. You kept your word. You delivered on time. And your quality exceeded expectations. Well done! You should give yourself a day off for working so hard! It is quite natural to want to oversell something that you can do in order to quickly generate consensus. However, if you oversell, you have set yourself up for underdelivery. And that's the opposite of expectation management.

Exercise 4

Applying the principles of Psychological Akido, let's turn around your next negative situation and find the positive lessons learned. Suppose your boss (or customer) is in the habit of getting quite angry because the software is late and buggy, or some other equally normal occurrence. How should you react? Most people would have a reflexive emotional response (without thinking) which varies widely based upon early childhood experience (or so the psychologists claim). Some people might get angry, right along with the boss: "Those darn programmers, they're always late, and their code stinks, damn them to hell!" Other people can't tolerate anger, and they close down. They become very passive, afraid, and quiet. Or they find a reason not to be there and leave.
As an expert martial artist in Psychological Akido, our response is to stay balanced. This is the boss's emotional trauma, not ours. We don't have to be afraid or angry. That's the boss's process erupting, not ours. We want to be there for the boss, and help him work through his feelings. Sensitively. I might say something like, "I'm sorry you feel that way about this situation, how can I help?" Neither angry, nor afraid, but compassionate.
Ideally, let the boss sort his own problem. You might ask some leading questions to get him started on identifying alternatives. Perhaps, "What do you think is causing this problem?" and "If you had a magic wand, what would we do to fix this?" Help the boss channel his/her energy into constructive brainstorming of alternatives, and then to selection of positive actions. There are always alternatives. Using this martial art, we channel negative energy into constructive planning and action, because fundamentally we believe that positives and negatives are the same. Both express energy that leads to equally constructive possibilities. From the experience, we learn "how things happen," and a new way forward for dealing with negative situations.

Exercise 5

Suppose our job was to redirect 100 software projects to use a common process or standard, such as .NET, within one year. If we were brilliant enough to redirect one project every week, through face-to-face mentoring, it would take two years to complete the task. Nobody is that brilliant or consistently productive. We can't succeed working one-on-one. That's working hard, not smart.
The techniques of Intellectual Akido show a way forward. The core of the strategy is to prepare and present tutorials on .NET that will evangelize and train the developers to use the technology effectively. In addition, various process and guidelines documents can make it easy to transfer lessons learned to projects, so that they can adopt the desired technology readily. In addition we would add a few other elements, such as an executive policy letter directing all projects to make the transition. We would also add .NET to the enterprise operational environment (i.e., site licensing and easy acquisition and installation by any project).
When given an intractable task such as the one described in this exercise is to approach it confidently with a firm grounding in the psychological warfare techniques that will make you ultimately successful.

---

• Run Away Back to Mama
• Basic Level
• Drill Sergeant
• Navy SEAL
• Special Advisor
• Commander-in-Chief
• Secret Agent
• I Spy

---