Home > Store

Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision

Register your product to gain access to bonus material or receive a coupon.

Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision


  • Sorry, this book is no longer in print.
Not for Sale


  • Copyright 2002
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 464
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-60456-6
  • ISBN-13: 978-0-201-60456-6

Most people have experienced--at least once in their lives--the incomparable thrill of being part of a great team effort. They can remember the unity of purpose they experienced, the powerful passion that inspired them, and the incredible results they achieved. People who have been on a great team can attest that the difference between being on a team with a shared vision and being on a team without one is the difference between joy and misery.

In 1996, Jim and Michele McCarthy, after successful careers leading software development teams at Microsoft and elsewhere, set out to discover a set of repeatable group behaviors that would always lead to the formation of a state of shared vision for any team. They hoped for a practical, communicable, and reliable process that could be used to create the best possible teams every time it was applied. They established a hands-on laboratory for the study and teaching of high-performance teamwork. In a controlled simulation environment, their principle research and teaching effort--the McCarthy Software Development BootCamp--challenged dozens of real-world, high-tech teams to produce and deliver a product. Teams were given a product development assignment, and instructed to form a team, envision the product, agree on how to make it, then design, build, and ship it on time. By repeating these simulations time after time, with the new teams building on the learning from previous teams, core practices emerged that were repeatedly successful. These were encoded as patterns and protocols.

Software for Your Head is the first publication of the most significant results of the authors' unprecedented five-year investigation into the dynamics of contemporary teams. The information in this book will provide a means for any team to create for itself a compelling state of shared vision.



Related Article

Managing Software Teams for Results: Introduction to the Elements of the Core

Web Resources

Click below for Web Resources related to this title:
Author Web Site

Sample Content

Online Sample Chapters

Managing Software Teams for Results: Achieving Performance Through Effective Collaboration

Managing Software Teams for Results: Patterns and Protocols

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:

Table of Contents




1. The Elements of Check In.

Overcoming Distance.

The Check In Protocol.

The Check Out Protocol.

The Passer Protocol.


Problem Behaviors.

Patterns Synergistic with Check In.

2. Check In Patterns and Protocols.

Pattern: Check In.

Additional Discussion of Check In.

Pattern: Check Out.

Pattern: Passer.

Pattern: Connection.

3. Check In Antipatterns.

Antipattern: Too Emotional.

Antipattern: No Hurt Feelings.

Antipattern: Wrong Tolerance.

4. Other Patterns in the Check In Family.

Pattern: Team = Product.

Pattern: Self-Care.

Pattern: Thinking and Feeling.

Pattern: Pretend.

Pattern: The Greatness Cycle.


5. The Elements of Decider.

Other Decision-Related Elements.


6. Decider Patterns and Protocols.

Pattern: Decider.

Analysis of Decider.

Pattern: Resolution.

Pattern: Work with Intention.

Pattern: Ecology of Ideas.

7. Decider Antipatterns.

Antipattern: Resolution Avoidance.

Antipattern: Oblivion.

Antipattern: Turf.

Antipattern: Boss Won't Give Power.

Antipattern: Team Quackery.


8. The Elements of Alignment.

Personal and Team Alignment.

9. Alignment Pattern and Protocol.

Pattern: Alignment.

10. Alignment Antipatterns.

Antipattern: Not Enough People.

Antipattern: Align Me.

11. Alignment Patterns.

Pattern: Personal Alignment.

How and Why Alignment Works.

Pattern: Investigate.

Pattern: Receptivity.

Pattern: Web of Commitment.

Pattern: Ask for Help.


12. The Elements of Shared Vision.

Aspects of Shared Vision.

Patterns Involved in the Shared Vision Process.

13. Shared Vision Patterns and Protocols.

Pattern: Shared Vision.

Pattern: Metavision.

Pattern: Far Vision.

Pattern: Version.

14. Shared Vision Antipatterns.

Antipattern: Blinder.

Antipattern: Technicality.

Antipattern: Recoil.

Antipattern: Feedback.

15. The Perfection Game Pattern 3

Playing and Perfecting.


Appendix A. The Core Lexicon.
Appendix B. BootCamp Material.
Appendix C. The Core Protocols V. 1.0.
Authors. 0201604566T01022002


The Core V. 1.0 Background

We didn't create The Core. Instead, we watched it grow. We did, however, along with John Rae-Grant, create the set of initial conditions under which The Core protocols, or something very much like them, would almost certainly emerge. Over the years, we have maintained healthy conditions for Core evolution. Along the way, we also pruned the tree from growing into a few false directions. And we added resources: our own money, time, focus, and stamina. We protected it. Took notes. Tried it out. Passed it out.

A proper credit also has to include the hundreds of product developers and other students from around the world who contributed to The Core's development over the years. Crediting one person or segment of contributors exclusively would be inaccurate, however. The real story is both simpler and more complex.The emergence of The Core was in some measure a result of our experiences in 1994-95. We were working for a commercial software company, leading a development team of approximately 150 people. We used a homegrown aphorism to help us try new ideas:

Team = Software

That's the idea. Because of its many virtues, despite its deficits, and regardless of others who have had the same thought, this maxim became a bit of a mantra for us. During stressful times, when we were tempted to retreat from the overwhelming complexity of the software development tasks; when the confusion and disorientation were really getting to us; when schedules were slipping and goals receding and prospects were looking pretty grim indeed. Then, just when we needed it most, someone in our group would invariably come up with a new idea, would provide a fresh point of view based on "Team = Software." "I get it," he might say, and then rattle off some new application of "Team = Software" that could apply to our situation. Occasionally, these ideas were profound; more often they weren't. They were almost always useful, however.

The essence of the "Team = Software" philosophy is that the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product's development.

We also realized that everyone has a product or provides a service. Everyone produces a concrete expression of his value system that carries that person's virtues and vices out into the world.

What was our leadership team making? We moved through the hierarchical levels in our organization and answered two pertinent questions at each interesting point: Who is the team here? And what is its product?

Let's call the team of frontline developers the Level I team. Level I makes the actual product. The managers of this team constitute the Level II team. Its product is the Level I team. When applying the "Team = Software" philosophy, the team on one level is the product of the team at the next higher level. If the Level II team sees an undesirable trait in the Level I team, it must be an expression of or reflection of Level II teamwork and the Level II team members. This pattern applies to teams at all levels, right up through the corporate ranks.

This idea may seem clever, obvious, fanciful, or just plain wrong-headed, but to us it was certainly helpful. Using this model, no one can hide from accountability. In our situation, even though we were bosses, we could not fault a team for lacking a virtue, unless and until we had personally demonstrated it. Nor could we expect any remedy that we weren't personally modeling. On the one hand, this realization was depressing, because there really was no escape: Responsibility inevitably migrated upward and weighed heavily from time to time on our well-paid, if under-exercised, shoulders. On the other hand, this realization offered an incredibly hopeful perspective as something more, something immediate, something completely within our control that was available to remedy any shortcomings of the team.

If we saw something screwed up somewhere or noticed some good fruit dying on the vine, we could immediately find and fix the problem. To inspire other team members to go get that fruit before it died, we would gather and visibly devour tantalizing fruit that had gone unpicked in our own neck of the woods.If we wanted any property to materialize on the Level I team, we would have to incorporate that property into our own behavior. This change in behavior was conceptually simple, but challenging to implement. In any case, keeping this basic framework in mind exposed many novel approaches to team problems. When we first applied this perspective, so many new possibilities opened up at such a rapid pace that we were unable to keep up with them. Although many little tests and a few big ones did yield the desired results, we saw so many new solutions to problems that had plagued us for years that we hardly knew where to begin. We quickly realized that we couldn't possibly conduct sufficient experiments to develop a full understanding of precisely how useful the formula was; to discover where it failed; or to see where the behavior it inspired might lead. We wanted to explore its dynamics and map its etiology in the systems we believed it governed--that is, check it out all the way.

Unfortunately, the experimental opportunities in a commercial software development effort are necessarily limited. A major obstacle is the simple passage of calendar time. A large commercial software project can take months or years. The possibilities we were seeing appeared so valuable, however, that even a few months seemed far too long for each cycle if we were to learn everything possible. With millions of dollars at stake on a single development effort, radical experimentation seemed risky. The number of variables with which we could tinker was low. Together, the sluggishness of "real-world" calendar time and the responsibilities of prudent business practices worked against the idea of implementing the sustained, radical, and rapid experimentation that we envisioned. Still, we thought big breakthroughs in team dynamics were possible--breakthroughs that could make collaboration simpler and more effective for any team.

To study this material in depth, we had to complete a development cycle in a much shorter time. Life itself was too short to go through enough development cycles. Even a very busy, unusually stable, and highly focused development manager could--if he stayed with the task for a long time--expect to oversee 10 to 20 projects in one professional lifetime. Many of these projects would use essentially the same teams, reducing the diversity of team sources that would enrich the manager's education and hasten experimental progress.

In early 1996, to accelerate the rate and breadth of our experiments, we went out on our own and established a laboratory devoted to the study and teaching of teamwork. The ultimate existence of The Core protocols became a virtual certainty when we decided how we would operate the new lab, which we named "Software Development BootCamp." The principal experiment conducted would be a recurrent product development simulation, lasting five days and nights with a new team each time. It would take place every month or so. The developers would complete four steps:

  1. Form a team.
  2. Envision a product.
  3. Agree on how it would be made.
  4. Design and build it.

At the end of the week, the teams would have to deliver their products on time, or stay longer to do so, or not, as they chose.

We knew that we could successfully conduct such a product development effort, even leading it personally, if needed. We had done just that for many years, earning our living in a variety of environments. We had sufficient information, tips, techniques, and useful practices to transmit high value to most students. We could teach them practices that could ensure the successful outcome of their own product development efforts, now or later, simulated or not.

We had already gained, organized, and articulated considerable knowledge from our experiences in leading or otherwise contributing to dozens of development efforts, most of which proved quite successful. This body of knowledge would serve as the starting point for the first BootCamp teams. Even if we learned nothing during BootCamp, we still would have plenty to offer.

BootCamp has allowed us to effectively compress a software development cycle into a five-day experience. In five days, students learn what would normally require a long development cycle. The intense BootCamp experience includes all of the failures and triumphs that occur with normal team formation; the creation of a team-shared vision; and the design, implementation, and delivery of a product. The days in each BootCamp are packed with accelerated team dynamics; what usually takes a year or more is created in a few long days and nights of exceptionally deep engagement.

The many new insights from BootCamp emerged at a vastly increased clip. The learning pace was accelerated by our experience of working intimately with some 60 different software development teams. We first helped to create the team, and then their products. We experienced complete development cycles with incredible frequency and velocity--one or two times per month at peak periods. Working with teams of every kind and composition, and working before and after BootCamp, we applied what we learned to our own teamwork.

One additional factor led to the creation of The Core protocols, and originated in our standard assignment to the students. Each team would have to build a product in one week. But what product would the BootCamp teams make?

At one level, BootCamp is conceptually simple: We assemble a group of software developers. Sometimes the students are members of a preexisting team. Sometimes they represent as many types of developers as possible: corporate employees, entrepreneurs, computer scientists, software testers, writers, editors, graphic artists, coders, managers, executives, program and project managers, and producers. Often, there will be nondevelopers in attendance: nurses, teachers, homebodies, consultants, and press members. We give each new team-in-waiting a single assignment:

Design, implement, and deliver a course that teaches you everything you need to know to ship great software on time, every time.

This assignment has remained unchanged since the first BootCamp. It seemed to us that it would be useful to look at team dynamics from the real-time point of view of a team actually working in a state of effective teamwork. Teams exhibiting the most desirable teamwork were best able to solve the riddles of such teamwork.

The decision to devote the BootCamp teams' efforts to resolving the issues of bringing teams to the effective state they were enjoying was a productive innovation. Teams in a newly gained high-performance state produce extraordinary results. When they examine the conditions and elements of their own high performance, as it occurs, the quality of insight is substantial.

Almost every BootCamp team has experienced the following flash of insight: If teamwork itself could be made more efficient and direct, then the team members would be able to find the solutions to the big problems that vexed them. This knowledge could then be leveraged to enhance their other endeavors.

High-performance teams typically acquire their reputations by accomplishing the specific goals they set for themselves. For example, a great basketball team wins many basketball games. The players are not remembered for their contributions to the art and science of team enhancement, but for putting balls through hoops. Achieving a team's original goal is a task not directly related to explicitly uncovering the dynamics of team formation. In the case of the BootCamp teams, the presenting task became the discovery, refinement, and codification of practices that would always lead to the formation of great teams.

As one BootCamp led to the next, we began capturing the best practices employed by the teams, and we encoded these behaviors to make them easily transmissible. These lessons from the BootCamp experiences gradually evolved into The Core protocols. When a team applies The Core protocols consistently, it will produce superior results.

The booting process stimulated by The Core protocols can be ongoing, yielding more efficient and capable groups. The lesson that the booting process continues in a general way is reinforced vividly when we see every new BootCamp team learn more, do more, and add more to the richness and the reproducibility of the "multipersonal" patterns and protocols that lie at the heart of The Core.And that's our story--how we watched The Core protocols emerge.

The Elements of The Core

We have encoded information regarding team behaviors that in our experience will invariably increase any team's desirable results. We have organized the information in a small group of textual structures that make up The Core.


  1. Patterns
  2. Antipatterns
  3. Definitions
  4. Protocols

To the potential adopter, The Core protocols are the most significant of these four classes of information. The Core patterns and antipatterns articulate the reasons behind many of the choices we have made as designers of The Core protocols, but The Core protocols are the elements that actually specify--in a detailed, formal way--our recommended personal and team behaviors. The Core protocols have been developed and experimented with through many iterations, and have been used by many people over significant periods of time. We are confident that their consistent and correct application will yield very good results. Even if all the ideas in The Core patterns and antipatterns are mortally flawed, use of The Core protocols will still produce the best results of any set of practices we've seen or tried. If we do not understand why they work, we do understand that they work.

Additionally, it should be noted that the common understanding and practical acceptance of some terms included in The Core definitions are required in order to properly apply some of The Core protocols. To the extent that this is so, those Core definitions must necessarily be given equal weight to The Core protocols.


A pattern is a standardized way of efficiently communicating the solution to a problem in a context; a pattern should generate something and tell you how to generate that something. Patterns promise particular results and consequences if you apply them. A pattern for a dress, for example, will support you in creating the dress it promises but limit the wearer's options. Use of The Core patterns has repeatedly generated teams that perform better than the teams originally expected of themselves.

The word "pattern" has come to have a special meaning for software developers. The idea of patterns in software descends from a special use of the term first articulated by Christopher Alexander, thinker and architect, in the 1970s.1 He created a structure for documenting patterns and collections of patterns called "pattern languages." These pattern languages were used to encode and communicate important ideas about the practice and purpose of architecture.

Patterns are a means of transmitting general solutions to common problems. The special software or architectural sense of the word "pattern" is not really all that different from the usual use of the word. If you have a pattern, especially one that has been consistently successful in its application, you don't have the thing itself, but you do have a head start in making the thing, or learning enough to make it or use it. For this reason, patterns have come to be widely written about and discussed as a communications mechanism in the software field.The classic definition of a pattern of this type is "A solution to a problem in a context." People being what they are, there is some dispute about the definition of software patterns. Generally, software patterns are abstract solutions to recurrent technical problems faced by programmers. They are a way for a programmer to understand and acquire a language for discussing problems. This can lead to the accumulation of intelligence. Theoretically, patterns enable the re-use of the best thinking done to date, and allow a pattern consumer to access the body of solutions available.

We define patterns as software for your head. Our pattern-based software, like other applications of the pattern concepts, provides solutions to common problems. The patterns in The Core contain information, procedures, and constraints that you can "load" into your mind. Once loaded or learned, you can apply them. Your teammates can do the same, and then all can share in what we believe is a rich source of psychological, linguistic, and behavioral resources. Apply these patterns however and whenever you care to.

The Core patterns apply to the shaping of a group's thinking, and the making and execution of its decisions. Our goal in supplying patterns of this type isWe want to create a world wherein a group's behaviors consistently achieve that group's predetermined goals.


These are patterns that describe common solutions that yield undesirable results. In effect, they are false patterns, patterns that reliably fail. For every antipattern in The Core, we present a pattern or a protocol (or both) that has provided a satisfactory solution to the problem many times.

"One-eighty" is the somewhat whimsical name we have given to a special type of phenomenon we have observed more often than we expected. A one-eighty is an idea that expresses conventional wisdom, but it yields undesirable results and does so in the most abysmal way conceivable. A one-eighty is so wrong-headed that, if instead of following the idea in question, a person performed steps precisely opposite to those specified or suggested, he would actually achieve the ostensible goal of the one-eighty. In other words: Conventional wisdom is often real wisdom, but encoded as the opposite folly.


Most software systems have their own definitions of special terms. Generally, the system authors define these terms. Naturally, the definitions of such terms are local in scope.

The words used in The Core are found in everyday English. To reduce complications caused by the availability of the same words for everyday use and their specific application and meaning in the context of The Core, we supply a lexicon of Core definitions.

  • The purpose of the lexicon is to specify the exact meaning of what might otherwise be overloaded words or phrases. These may or may not have general usage beyond The Core, but, if they do, we define them locally because we found that their application typically lacked precision.
  • The definitions are designed to increase the results of your team, not necessarily to provide any real truth-value beyond the scope of the team life. The Core's definitions are not dictionary definitions. They are tokens in a system.
  • The definitions are somewhat arbitrary and must be accepted for the system to function. For the purpose of applying The Core, they are best seen as straightforward but local axioms, arbitrary little chunks of meaning. Just "givens."
  • These definitions provide the linguistic material required to construct and use The Core. The definitions are just a part of the rules of the game. They are special constraints that can channel substantial power to and from the team playing the game.

Wherever possible, we have tried to use words that do have some generally accepted meaning close to what we are trying to convey in our application of the term. We dislike making up new words. This way, anybody can get a sense of what is being discussed by a Core team without recourse to the lexicon.


Almost all team activity is untouched by The Core. The Core protocols are meant to ensure that a few important results-oriented behaviors will be attained by a given team with a

  • Previously unavailable degree of reliability
  • Higher than usual degree of efficiency
  • More uniform distribution of accountability

Any team can use The Core protocols to achieve these goals. The rest of the time, team life goes on, as the team desires.

When adopted, Core protocols will provide teams with a reliable means to efficiently achieve at least the following:

  1. Group interpersonal connection with an increased level of access to one another
  2. Collective, unanimous decision making and related accountability distribution
  3. Team and personal alignment
  4. Achievement of a shared vision, including
  • Long-term or far vision
  • Short-term or version-oriented vision
  • Personal commitment to personal and team goals
  • Team commitment to personal and team goals

Many teams have never experienced these achievements. The Core protocols turn them into everyday activities.

The Core protocols do not predefine or limit2 the content transmitted between connecting parties. Instead, the protocols provide the opportunity to transmit and receive the content deemed important by the parties.

The protocols in The Core are conceptually simple, memorable, and practical. We have found each one to be extremely effective; many teams have used them, and they quickly become second nature for the teams. While we have no desire to formalize normal team interplay, we do provide sufficient structure so that teams can enjoy particular kinds of interplay that are as consistently high quality, highly reliable, and as results oriented as a team might desire.

1. See, for example, Christopher Alexander, et al., A Pattern Language (Oxford University Press, 1977) and Alexander, The Timeless Way (Oxford University Press, 1979).

2. Beyond supporting the normal limits expected in an environment allowing civilized discourse, at any rate.



AAccountability. See Alignment; Decider
   CheckIn and, 29-30, 390
   defined, 336
   GreatnessCycle and, 94, 95 (Table)
Aggregate headgap, defined, 12
Aggregation, Decider and, 135-136, 159, 160
Alexander, Christopher, xx
AlignMe antipattern, 185, 208-213, 380-381
   about, 20-21
   in BootCamp, 368, 372, 380-381
   defined, 232n
   elements of, 185, 187-188
   team scenario with, 182-184
Alignment antipatterns, 199-213. See also AlignMe
Alignment depth, 226
Alignment evidence, 223, 231
Alignment patterns, 189-193. See also AskforHelp; Investigate; PersonalAlignment; Receptivity; SharedVision; TeamAlignment; WebofCommitment
Alignment protocols, 193, 195-197, 400-401. See also Investigate; PerfectionGame
Anger. See Mad
Antipatterns, xix, xxi-xxii, 336. See also CheckIn
Art space, in BootCamp, 361-363
Asker role/commitments, 256-259, 409-412
AskforHelp pattern, 253-256
AskforHelp protocol
   in BootCamp, 365, 368
   commitments, 258-259, 411-412
   questions about, 259-260
   roles, 256-257, 259, 409-411
Attraction, PersonalAlignment and, 233
Autocratic decision-making, 121-122, 146
Awareness, defined, 19BBehaviors, problem, 14. See also WrongTolerance
Bits, defined, 50n
Black hats, 255n, 360, 369-371, 376-377
Blame, caring and, 161-162
   AlignMe and, 208-210, 211, 212, 213
   AskforHelp and, 256n
   defined, 337
Blinder antipattern, 274, 275, 278, 283, 303-305
Block, defined, 337
Blue hats, 360
BootCamp. See also Black hats; Consultants
   about, 358-364
   answer key, 365-375
   art space, 361-363
   CheckIn and, 39n, 379-380
   confrontation, 378
   establishment of, xvi-xix
   facilities liaison, 361
   goals of, 364-365, 381
   group discussion, 377
   hats, 360-361
   materials, 353-381
   moderators, 378-379
   personal participation in, 354-358
   psychotherapy, compared to, 375-381
   simulation example, 359
   staff, 363-364
   team assignments, 364
"Boss-as-judge" decisions, 122, 125-126, 146
BossWon'tYield antipattern, 116, 163-165CCare/Caring, defined, 160-161
Censorship, self, 76
Charisma, TeamQuackery and, 172-173
Checked in, defined, 337
CheckIn, 11-17, 23n, 27, 329
CheckIn antipatterns, 14, 53-68. See also NoHurtFeelings; TooEmotional; WrongTolerance
CheckIn patterns. See also CheckOut; Connection; Decider; GreatnessCycle; Passer; Pretend; Self-Care; Team = Product; ThinkingandFeeling
   behaviors, problem, 14
   benefits of, 42
   connection and, 14
   discussion, additional, 32-42
   distance, overcoming, 11-12
   emotions and, 22-25, 33
   multiple levels, 34
   patterns synergistic with, 15, 17
   problem, 19-22
   solution, 34
   team characteristics with, 4-10, 41-42
CheckIn protocols. See also Group CheckIn; Personal CheckIn
   benefits of, 36
   in BootCamp, 369, 372, 379-380
   components of, 12-13
   defined, 25
   emotional states, core, 29-30, 35, 36, 37, 38, 39, 55, 94, 95 (Table), 390
   evasions, common, 35-36, 38-39
   functions, 34, 35
   group, 27-28
   guidelines, 31, 391
   identification, increased, 37
   illegal, 36n
   meetings, use at, 41-42
   presence and, 17, 42
   results, 30-31, 37-38, 39, 42
   rules, 32, 391
   specific "In-ness" commitments, 26-27, 388-389
   synopsis, 28-29
   team characteristics with, 39-40
   when to use, 31, 390-391
CheckOut pattern, 43
CheckOut protocol
   commitments, 45, 392
   components of, 13
   guidelines, 45, 393
   results, 44
   synopsis, 44, 392
   when to use, 44-45, 391, 392
Coaches. See Consultants
Conflict avoidance, defined, 65
Conflict(s). See also Decider; ResolutionAvoidance
   CheckIn and, 17
   cost of reducing, 93
   GreatnessCycle and, 82, 83, 92-94, 96, 97
Confrontation, in BootCamp, 378
Connection. See also CheckIn
   in BootCamp, 365
   Decider and, 135
   defined, 14
   FarVision and, 297
Connection pattern, 48-52
"Consensus-style" decisions, 123-124
   in BootCamp, 361, 363-364, 366, 367, 369, 377
   TeamQuackery and, 172
Conway, Mel, 70n
Conway's Law, 70n
Core V. 1.0. See also BootCamp
   defined, 338
   elements/structure of, xix-xxivv
Core V. 1.0 protocols. See also Alignment; AskforHelp; CheckIn; CheckOut; Decider; IntentionCheck; Passer; Passionometer; PerfectionGame; Resolution; SharedVision; WebofCommitment
   licensing agreement, 418-424
   overview, 385-387
   structural aspects of, xix, xx, xxii-xxiv
Corporate culture, 207
Courage, 91, 94
Culture, corporate, 207
Cynicism, 168-170, 234DDarwin, Charles, 97, 98
   CheckIn and, 26, 27
   elements of, 111-115
   FarVision and, 300
   Passer and, 46
   team scenario with, 106-109
Decider antipatterns, 115-116. See also BossWon'tYield; Oblivion; ResolutionAvoidance; TeamQuackery; Turf
Decider patterns. See also Resolution; WorkwithIntention
   analysis, 130-137
   commitments, 130
   outcomes, 130
   problem, 117-126
   SharedVision and, 270
   solution, 126-130
   won't get in strategy, 136-137
Decider protocols. See also IntentionCheck
   about, 394-395
   in BootCamp, 368, 369, 372
   commitments, 397
   guidelines, 395-396
   outcomes, 397
   steps of, 126-130
   voting, 127 (Table), 129-130, 396-397
   defined, 119
   making, common techniques of, 120-126
   unanimity of, 111-112, 114
Definitions, xix, xx, xxii-xxiii, 335-351
Democratic decision-making, 121, 122
   of CheckIn, 338
   of presence, 85
Despair, TeamQuackery and, 168-170
Developers, defined, 272
Disbelief, TeamQuackery and, 168-170
Disclosure, 13n
Disintegration, lateness and, 247, 248
Distance, CheckIn and, 11-12EEcologyofIdeas pattern
   Decider and, 114-115, 146-147
   problem, 146
   solution, 147
EcologyofIdeas pattern (Cont.


Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020