Safe to fail experiments are about education.

Safe to fail experiments are about learning

In IT, ‘safe to fail’ describes activities that are used to generate knowledge. Additional terms that might be used are probes, spikes, R&D and prototypes. The outcome of a safe to fail experiment can be innovation, the information necessary to make decisions or to discover alternatives.  All these scenarios are appropriate for a safe to fail experiment however regardless of intent sometimes safe to fail  experiment are not safe nor are they appropriate.

Safe to fail experiments are appropriate in situations where learning is required to deliver a project. An experiment or a bit of prototyping might be needed to learn whether something is possible or if there is a more effective way to perform a repetitive task. For example, earlier in my career my team converted credit card portfolios from one provider to another. We used a standard process for most of the hard work. We were always looking for a way to make the process more efficient  using mock conversions as experiments. The goal was to find better processes and techniques.  These experiments did not always yield process changes, but they always added to our knowledge of what would and wouldn’t work. Another opportunity for safe to fail experiments is in situations where several possible alternatives exist. You need an experiment to determine which (if any) of the alternatives make sense. A test or an experiment is considered successful if it proves either that an alternative is a good choice OR if the results can be used to cross an alternative off the list. Organizations that judge results that can disqualify an alternative as a failure are apt sort out alternatives in the market place rather than before they go into production because experiments will not be safe. Finally, safe to fail experiments are useful tools in formal decision-making frameworks. For example, frameworks built to comply with the CMMI process area, Decision Analysis and Resolution (DAR), often leverage safe to fail experiments to generate data for formal, structured decision-making.

Safe to fail experiments are not always appropriate.  Many projects exist with a both fairly well understood solution and a hard deadline. In some portion of these projects the solution may not be perfectly optimal or the coolest possible solution, but it is doable in the timeframe. Experimenting to find a more optimal solution when taking the time and effort could cause you to miss the due date is not appropriate. In the credit card example mentioned earlier, we explored new ideas and optimization between projects to avoid experiments that would put the conversion at risk or cause the team to miss more of their weekend than was already necessary. Experiments that imperil the commitments a team has made or inhibits their ability to effectively deliver are not experiments and are safe to fail. Experimenting is also not appropriate where negative results are thought of as a black mark on a career. In this case straying from the tried and true approaches are generally a bad idea. This scenario tends to occur in highly politicized or overly competitive organizations. In this type of scenario if you can’t change the environment, I would suggest experimenting with other job opportunities. A third scenario is more questionable than absolutely inappropriate. In scenarios where there is little potential upside to the experiment experimentation is probably not a good idea. In most organizations, time and attention are always in short supply. Every team needs to judge what it needs to learn and ration resources that are in short supply when there is little or no perceived upside.

Safe to fail experiments are scenarios where an organization or team truly wants to sift through possible alternatives before using them in a project or in production. Safe to fail experimentation is an application of the scientific method (testing hypotheses) to generate knowledge and decisions so that teams and projects deliver more value.

What you see is dependent on what you expect.

What you see is dependent on what you expect.

Cognitive bias refers to a pattern of behavior that reflect a deviation in judgment that occurs under particular situations. Biases develop as filters and / or shortcuts that help us perceive information quickly in a manner that turns out to be beneficial to a decision process. Biases that help us recognize patterns help early humans stay alive by recognizing situations where predators tended to exist. The short cut in the decision process that the bias provided kept our ancestors alive even if there were false positives (you could have lots of false positives but only one false negative). Project teams (Agile or not) use or fall prey to a wide range of biases that affect perceptions and decisions. A sample of common bias that affect project teams in this category include:

Anchor bias refers to the tendency to rely heavily on one piece of information when making decisions. This bias is often seen when early estimates for a project or a tasks are made. The instant they are placed on the table they become a reference point to which all changes will be compared.

Clustering illusion (or clustering bias) is the tendency to see patterns in clusters or streaks of in a smaller sample of data inside larger data sets. For example, a team I recently worked with had an average velocity of 30 story points per sprint (ranged between 20 – 36) that had three sprints in a row that delivered 40+ story points. While nothing significant had changed with how the team was working outsiders saw a pattern and believed something out of the ordinary was occurring. (FYI – if there is no statistical significance to the data what we are seeing is “common cause” variance.)

The curse of knowledge bias generates a filter that blocks the ability think about a topic from a different and generally less informed perspective. In many cases being an expert on a topic makes it very difficult to see an out-of-the-box solution. This is one of the reasons significant changes in IT platforms or concepts come as new players enter the organization that have less experience with current tools and techniques. In a similar manner to the curse of knowledge, the status quo bias, the tendency to want things to stay relatively the same, creates a perception filter that helps the individual or team identify data and concepts which makes them comfortable.

An availability cascade causes a concept to become more and more plausible the more it is repeated publicly.  A self-reinforcing feedback loop. Perhaps that is why Pokemon became more popular the more it was shown on the Cartoon Network. Daniel Pink, author of To Sell Is Human, in a Salesforce.Com webinar on July 9th pointed out that repetition increase process fluency which makes the repeated item perceived to more true through repetition. Sales, marketing and 24 hour news channels understand and use the availability cascade bias to great effect.

A final example of biases that affect behavior and perception is optimism bias. Optimism bias is the tendency to be overoptimistic about favorable outcomes. This bias is often exhibited in status reports or in promises made early in a project. These are generally not lies but rather due to optimism bias we believe that we can deliver. Dr. Ricardo Validri in Software Process and Measurement Cast 84 suggests that optimism bias one of major reasons IT personnel are poor estimators.

This is a sample of cognitive biases that affect how we perceive information and then how we make decisions. Each of the biases reflects some basic component of human psychology and has been found to be generally beneficial however all biases can create blind spots. A good coach or leader will first be aware of his or her biases and then help the team understand their blind spots while not abandoning the short cuts that can help us perceive what is important and make timely decisions.

Many of us have a cognitive bias toward eating scorpions!

Many of us have a cognitive bias toward eating scorpions!

Cognitive bias refers to a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. The phrase cognitive bias was introduced by Amos Tversky and Daniel Kahneman in 1972. Biases can affect how information is perceived, how teams and individuals behave and even, potentially, the perception of ourselves. Biases are a part of nearly every human interaction therefore the different biases must be understood if we are going to help teams grow and evolve.

Project teams make decisions on continuous basis. Most decisions are made based on how the decision maker perceives the information he or she has at hand. One bias that can affect how information is perceived is the illusory correlation. The illusory correlation is the perception of a relationship between two or more variables when no relationship exists. An example would be the perception that a team that works more hours a week has higher productivity because working longer gives the perception of creating more output. The perception of a relationship causes the other factors to be paid less attention (such as the higher level of effort they are expending). There are numerous biases that affect how information is perceived. Biases that affect how data is perceived can impact the outcome of decisions or even whether we make needed decisions at all.   

Biases can affect behavior. Neglect of probability is a type of cognitive bias common in IT organizations planning and estimating projects or in risk management. For example, most estimates should be represented as a range based on probability. Techniques like Monte Carlo analysis can be used to generate a range of probability based estimates. However, almost all estimates are represented as a single number and regardless of all the caveats attached the continuum of probability is ignored. Lottery ticket sales are another reflection of the neglect of probability bias; buying one or 10 doesn’t materially affect the probability of winning but it does not stop those who think buying ten tickets increases their chances of winning. In both cases neglecting probability affects how we behave and make decisions.  

Biases can effect motivation attitudes of ourselves. For example, a self-serving attributional bias, occurs when success is attributed to internal factions and failures to external factors. The type of bias can occur at an individual level or at the team level. While self-serving bias can improve self-esteem (or a team self-esteem) it can also cloud judgment by causing an overestimation of capability. For example, if a team is able to deliver more than their long-term productivity or velocity would predict, the team might then perceive that they have increased their capability to deliver. If no fundamental changes have occurred such as an infusion of knowledge, training or new tools, the higher velocity may not be attributable to the team. A good coach will help teams examine these types of biases during retrospectives.

Bias are powerful psychological filters that affect how both individuals and teams perceive the world around themselves and then how they behave. Biases reflect shortcuts in how we interpret and react to stimulus. In many cases these reactions are valuable however they can also cause problems (as many shortcuts occasionally can). Understanding how biases impact how individuals and teams perceive the world around them can help team make better decisions and therefore deliver value more effectively. 

Where do our cultures overlap?

Where do our cultures overlap?

I discussed the impact of organizational culture on decision making. Organizational culture has been shown to trump team culture. Many organizations make sourcing decisions that create teams with members from multiple organizations. Each organization will have its own organizational culture and goals. The more in common each of organization’s culture has with each other, the more apt groups of people are to form teams and make decisions effectively. Components of culture, such as the dichotomy between individualistic cultures and collective cultures, and the differences in business goals are important drivers that need to be understood.

Organizations with teams that historically had been staffed with team members that are individualistic by nature are often shocked when teams suddenly become blended with members that have a more collective nature.  This can be exacerbated if the new team members are offshore. The decision making styles will be different. Organizations centered in the USA, Britain, and Canada are typically staffed with employees that are individualistic, while many outsourcing organizations are perceived to be staffed with personnel that have a more collective outlook. A best practice suggested by Raja Bavani (SPaMCAST 190 – Raja Bavani, Distributed Agile) is to bring team members together for at least one sprint in person. The act of working together towards a common goal builds trust and helps the team members learn each other’s decision making styles.

Each organization pursues growth and being as profitable as possible. The devil is in the details thought. These goals are pursued in different ways and can create conflict that is translated down to a team level.  For example, several years ago I heard a salesman from a contracting firm say they weren’t worried as much about quality of what they delivered as making the project delivery date, because they would be paid after delivery to fix the defects and maintain the application. A best practice I have observed for long-term sourcing partners is to formulate an arrangement in which both share in the return on investment delivered by work the organizations do together. By creating more of a partnership the goals of both organizations will be more closely synchronized, making easier for team members to trust each other’s motives and for increased transparency in the decision making process.

When teams are comprised of members from multiple organizations, the cultures and goals of both organizations need to be identified and the ramifications of the differences need to be understood.  The more the cultures and goals can be synchronized the greater the likelihood that there will be a  true partnership. Partnerships develop the deeper level of trust and transparency that is needed for effective and efficient team decision making.

Distance and language make communication difficult.

Distance and language make communication difficult.

Distributed teams are a fact of life in many, if not most, IT organizations. Distributed teams are always less efficient than a co-located teams all things being equal. It is the last phrase, “all things being equal” that causes organizations to leverage distributed teams. Distributed teams have more challenges in making team decisions than co-located team due to potential culture differences and physical separation.

Culture is an often used term that describes typical behaviors and the mean ascribed to those behaviors. All groups have a culture. Within a group, culture allows members to interpret behavior and communication therefore building a bond of trust. When team members perceive differences in the behavior they anticipate a disruption in the bonds of trust occur. Since trust is a prerequisite to effective decision making disruptions to trust are serious issues to the health of a team. In corporate scenarios three types of cultures are generally considered to be important. Team, organization and national cultures are most often mentioned. Research has shown that organizational culture generally trumps all other types of cultures.

One mechanism to avoiding culture clashes is to ensure that the goals of a project are strongly tired to the goals of the organization. A second is to make sure that the techniques the team is being asked to use do not cause behaviors that are seen to be at odds with the corporate culture. Ensuring that no one is surprised by how the team will act or that it will be making decisions (or requiring them) will help establish a base of trust. When team and organization cultures are sympathetic they reinforce each other supporting a trust relationship and a more efficient decision making processes.

Physical separation influences decision making in a number of different ways. The first is through the potential for affecting communication frequency. Distance reduces the frequency of interaction (time zones only exacerbate problems).  Herbsleb and Grinter] found that communication frequency contributes to the inefficiency of distributed teams thus decisions must often be made quickly with the limited information available[1]. Inefficient decisions can lead to defects and rework which reduces the value a team can deliver or force them to embrace unsustainable practices. Red Bull anyone?

Solutions for physical separation are many. First, don’t do it. If you your organization is distributed try to organize teams in each location and leverage a scrum of scrums to coordinate. A second technique is to leverage video conferencing as continuously as possible to emulate physical presence. Tools like instant messengers and other forms of chat are also very useful but are best when used in combination with video. A third technique where significant time zone differences (more than 5 hours) exist is to ensure some shared day and the shared day should inconvenience everyone (everyone should share the time zone pain).

Research[2] has shown that distributed team, especially when team members are predominately from collective cultures, tend rely on a leader act as the focal point for decisions. This can be problematic for Agile teams where self-organization has not become an ingrained behavior. Reliance on a leader to champion a decision process becomes a problem to an Agile team when they start to generate a hierarchy which tends to reduce team cohesiveness. One solution is for the Scrum Master or coach to facilitate making sure that all team members get involved with decision making and that the right person drives the process. When one person starts to be the only decision maker, the coach, during the retrospective, should help the team discuss how the team can broaden its capabilities so that it avoids developing a single point of failure.

Distributed teams have all of the same issues that co-located teams have when wrestling with decisions plus potential culture issues and issues caused by physical separation. In a perfect world we would not have a distributed team but rather have distributed teams. The added problems that a distributed team has making decisions are not insurmountable. They do require that we recognize the risks, ensure as continuous communication as humanly possible and have active coaching available to help the team learn and institutionalize the concept of self-organization.

[1] Herbsleb J, Grinter R. Architectures, coordination and distance: Conway’s law and beyond. IEEESoftware 16(5): 1999, 963–70.[2] Investigating Decision Making Processes in Distributed Development Teams: Findings of a Comparative Empirical Study, Ban Al-ani , David Redmiles


Every task requires the right tools.

Every task requires the right tools.

Team based decision making requires mechanisms for creating consensus among team members. In the Daily Process Thoughts of June 26th we described the prerequisites teams must satisfy to make a decision. The prerequisites are a decision to be made, trust, knowledge and the tools to make a decisions. In many instances team members are assumed to have the required tools and techniques in their arsenal. Unless team members have been trained in tools to generate consensus and decisions this is rarely the case. I suggest three decision making techniques each team should have; voting, Fist to Five and the Nominal Group Technique. Note each technique is more complex than the next and is representative of many other similar techniques.

Voting is a decision making technique that almost everyone understands. The simplicity of the process is a major positive of this technique. The downside to voting as a decision making mechanism is that someone (or some group of someones) will lose. The win / lose mechanism can create a divide within the team which will pull it apart over time or generate passive aggressive behavior.

Fist to Five is a tool that combines consensus building and voting. The technique has been attributed to numerous people or organizations ranging from Jim Highsmith to the American Youth Foundation. Fist to Five introduces an element of the quality of the common “yes”/”no” vote. Each participant responds to a proposed solutions with a fist or up to five fingers. A fist is designated as a “no” (and I will try to block the decision) or some number of fingers. The number of fingers is a “yes,” with an indication of how good a “yes” is, it usually ranging from one meaning the voters still has some issues to five meaning the voter will man the barricades to fight for the decision. Fist to Five provides a way to check the “sense of the group,” and the quality of the consensus on a scale.

Consensus decision making requires involvement and commitment. Many group oriented techniques have been developed to generate involvement such as brainstorming. The goal of brainstorming is to give team members an opportunity to engage. The nominal group technique (NGT), uses a more structured format to obtain multiple inputs from team on a particular problem or issue. This mechanism is often useful to help new teams as they build relationships and for distributed teams where formality can be used to combat distance.

NGT is a structured group discussion / voting method. The format prevents the domination by a single person or subject matter expert and passive group members to participate. The output of the process is a set of prioritized ideas, solutions or recommendations. The steps for a sprint team: 1) State an open-ended question (“How are we going to solve a business problem?”). 2) Each team member will spend 5 – 10 minutes in silence individually brainstorming all the possible ideas. Write each idea on sticky note (if in person) or write the ideas in an electronic note (distributed). 3) Share the ideas in a round robin manner with someone acting as a recorder adding each idea to a flip chart or shareable mind map. (Round Robin is one response per person rotating until all ideas are recorded.). Use the classic brainstorming rules of allowing no criticism and allowing requests for clarification. 4) Have each person evaluate the ideas and then individually anonymously vote for the best ones (I typically suggest voting for the top five, five being best and one being the lowest). The idea with the most votes wins. Variant: discuss the top vote getters and then revote.

There are a myriad of group decision making techniques. They vary in complexity and each try to address issues that a team might have when creating a decision. However, none of these techniques have ANY value if the team is not aware of the technique or cannot execute the technique. Teams can struggle creating a consensus, become passionately split on an idea or simply struggle understanding the options that are appropriate. Each team needs a pallet of decision making tools available (or a coach with those techniques) or risk failing to make good decisions or decisions in a timely manner.

Having a camera is a prerequisite to taking a picture.

Agile teams make decisions continuously, all shapes and sizes. These decisions are critical to keeping work continuously moving forward.  Having to search for someone to make a decision or to setup a meeting to make a decision can be difference between completing or not completing a piece of work during an iteration. What are the prerequisites for Agile teams to make decisions?  There are some obvious prerequisites, like the need to make a decision, but assuming that basic need is met I would suggest that addition the team needs trust, knowledge and the tools to make a decisions.


Team decision making is a collaborative process and requires trust (this even more important when the team is distributed) and a sense of shared responsibility. Trust among team members is generated from a set of interactions, either facilitated or organic, in which team members learn the capabilities and opinions of their teammates. These interactions generate a common team culture that as it deepens allows team members to develop a better understanding of each person’s (and by extension the team’s) capabilities and behaviors. Assuming actions and communications that lead to decisions are made in line with the profile we have developed for the team we can work together to make decisions.


Knowledge is one of those prerequisite that can be rectified relatively quickly. Diversity helps broaden the team’s knowledge however teams need to understand the knowledge capabilities as deeply as skills based capabilities. When there are deficiencies team members need to work to fill the gap. Without the knowledge to make a decisions the answer derived will be correct only by accident.


There are numerous methods and techniques to make decisions. We will explore a few in Daily Process Thoughts on June 27th.  Decision making frameworks provide team members with the knowledge of tools that can help the team approach decision making. Many of us have one or two mechanisms for making a team decision. The most common technique leverages PowerPoint, boredom and arguing. Techniques like De Bono’s 6 Thinking Hats, Highsmith’s Fist to Five and maybe even roshambo might be valuable tools to have in your decision making tool box.


A team without trust, knowledge and the tools to make decisions is going to struggle. The struggle to make decisions will translate into making poor decisions or worse, into asking someone else to make the decision. Bad decisions are not the worst problem because feedback from mistakes will help the team learn make BETTER decisions or to learn HOW to make decisions.


Our guide acted as a servant leader.

Our guide acted as a servant leader.

The servant leader works to empower and serve the people he or she leads. Empowerment on an Agile team is reflected by the removing of impediments and coaching the team so it performs to its capability using Agile practices. If you are leveraging Scrum, this is the role described as a Scrum Master. In xP this is the role of a coach, Skip Prichard observes that servant leadership is a blend and balance between leader and servant. You don’t lose leadership qualities when becoming a servant leader. Different writers describe the seven pillars of servant leadership, the nine qualities of the servant leader or the 12 key practices of a servant leader. All of these lists can consolidated into four attributes which are fosters learning, facilitates collaboration, generates trust and acts as the team’s advocate.

A servant leader fosters an atmosphere in which a team continuously learns. Teams learn new skills, gain deeper understanding of the business, of the technology, of the capability of the team and how to deliver greater value. The servant leader helps to create an environment that supports the respectful and safe expression of ideas. They lead by example, through coaching and teaching.

A servant leader facilitates collaboration not only by creating a learning environment but by helping the team to establish a vision and goals which the team can use as a guide. The servant leader provides the tools and techniques needed for the team to self-organize and to make decisions. Collaborating is the action of working with someone (or someones) to generate an outcome. The servant, when needed, coaches and mentors team members to work together to achieve the goals they have committed to meeting.

A servant leader builds trust through trusting. When leaders exhibit trust of team members, team members show significantly higher levels of trust[1].  Trust is an important ingredient for working in teams because it underpins effective co-operative[2] behaviors. Trust creates an environment that makes communication flow more easily and allows the team self-organize rather than to be organized.

In old western movies the settlers would circle the wagons when threatened. Agile teams can’t circle the wagons however someone must advocate for the team. The servant leader is the voice of the team. Helping to remove impediments and to help deflect other demands that could deflect the team from living up to their capability.

Teams are a core component of work today. Agile teams are more efficient when they are empowered. Servant leaders help the team learn and collaborate. Servant leaders deliver and foster trust which makes the team more effective. Without someone to be the team’s voice and advocate, teams will be buffeted by the capricious demands of the organization making it difficult to deliver consistent value.


[1] Sen Sendjaya, Andre Pekerti, (2010) “Servant leadership as antecedent of trust in organizations”, Leadership & Organization Development Journal, Vol. 31 Iss: 7, pp.643 – 663

Without decision making techniques teams can wander.

Without decision making techniques teams can wander.

Leadership and decision making in Agile organizations and teams requires different processes and skills. Agile requires a shift from the classic command and control model to a team based model in which teams self-organize and make decisions. There are four major decision making / leadership differences that must be embraced to make Agile work well. They include servant leadership, time boxes, team focused decision making and flexibility.

Servant leadership (we will do a deep dive on June 25) is a person that puts others first. The servant leader empowers, mentors and facilitates the team. Scrum masters or coaches often find themselves playing this role on sprint teams. When the leadership mantle is taken, even if for a specific decision, the person that is playing the role can’t revert to more old style directive models or trust and the esprit de corps of the team will be damaged.

Time boxes change the pace of decisions. The use of short focused iterations forces decisions to be made or work may grind to a halt. Time compression changes the dynamics of the decision making process. For example, the team will tend to rely on expertise rather than extended data gather exercises. Decision making processes need to feature brutal transparency and trust. Team members need to be able to openly, honestly and safely share opinions and knowledge if decisions are going to be made when they are needed.

Team focused decision making plays a central role in Agile. Classic project management models focus on having the project manager facilitate and make decisions either as a command and control leader or a more enlightened participatory leaders. In either case the responsibility, and therefore the final decision, rested on the PM’s shoulders. Agile turns the model on its head and puts the responsibility for decision making on the team. A scrum masters, coach or someone playing that role for the discussion may well facilitate the decision making process but they don’t own it.

Decision processes need to be flexible enough to reflect that not all decisions need to be made by the entire team. In some cases subgroups or individual team members may need to make decisions which then can be socialized by the larger group. Obviously critical decisions on technical direction (for example making the architecture decisions that cloud computing or client server would require) would not be made in this manner. Another twist on flexibility is the need to have multiple decision models and know when to use them. For example, most teams use a consensus model for most decisions however, at times, voting might be required to move forward.  The team needs to understand how to leverage multiple decision models and when to use them.

Agile teams are different. Agile teams make decisions differently from classic project management teams. Servant leaders facilitate and coach the team so they can make decisions within the time boxes they work within, without popping a fuse from the stress time boxes can generate. One technique never will suffice to help teams make all the decisions that are needed. The team needs to have the flexibility to pick the techniques for decision making that make sense for the specific decision that needs to be made.

Thomas M. Cagley Jr.

The real world has proven over and over again that it is a dynamic system.   Decision making in this environment, especially as it relates to process improvement, requires a steady influx of new knowledge and information to have an even reasonable chance of getting an answer that works.  Unfortunately that flow of information can be throttled.  Once throttled, metaphorical walls begin to be built around a leader.  These walls create an echo chamber which reinforces ideas, concepts or models that are comfortable rather than new or different and potentially uncomfortable.  This is basic human nature therefore requires you to actively resist raising your shields and loading photon torpedoes at the drop of the hat.

Comfort and process improvement leader are phrases that can’t exist together, much akin to the relationship between suffering and great art.  As a leader if you are comfortable you are not trying hard enough.  How does comfort with a specific process, concept or model happen when by definition it shouldn’t?  Generally success; personal success or success reflected from a boss or mentors are key culprits.  Regardless of where it comes from success is a seductive force leading some to try the same solution over and over. I do not suggest that you avoid success or route for failure but rather that you do not become comfortable with one solution or idea.  If you let success and comfort translate into building walls between you and other ideas you are creating an echo chamber.  I suggest that you have started down the road to failure because the world changes, the environment changes and people change even if your solutions do not and if you are very unlucky that failure when it comes will not be quick.

Another set of problems are the feedback loops generated within micro-communities.  Micro-communities have become common ranging across email bulletin boards and the new wave of social media tools.  Social media tools have created tools to support hyper focus by connecting people more easily without regard geography or time zone (no one really sleeps).  These micro-communities while they can tear down walls also can lead to walls between people and ideas being built as the community evolve to become more than a sum of the individuals.  The issue is not the communities per se but rather the degree that many of these communities build enforcement mechanisms to guard their catechism.  Enforcement creates an echo chamber which can lead to the belief that there aren’t new ideas or dissenters.  When all we hear is how good an idea is the less likely we are to consider different ideas, tactics and strategies when making decisions.  Therefore as the environment and context changes these strategies and tactics work drift away from center of the bull’s-eye.  Failure at this point is a matter of time not of probability unless new information is accepted into the decision making process.

Regardless of how walls around ideas are formed, walls create weakness in the decision process.  Walls either reduce or stop feedback that could differ from your current point of view.  When walls exist, feedback will tend to be from sources that think similarly creating the echo chamber noted before.   The common social media term for this behavior is “tribes” (popularized by uber-blogger and author Seth Godin).   Godin suggests:

“Internet has ended mass marketing and revived a human social unit from the distant past: tribes. Founded on shared ideas and values, tribes give ordinary people the power to lead and make big change.”[1]

These tribes are micro communities that can foster and nurture new ideas until they can be absorbed into the core.  An example in our world is the agile movement.  Once upon a time, agile was a radical concept.  Micro-communities adopted these methods and ideas and nurtured until now they are merging into the core software development processes.  Great stuff until the tribe or micro-community creates walls that stop them from listening to the environment and context around them and emulate the Anasazi Indians (great pueblos but not much left of the tribe).  Creating too thick of walls will starve the micro-community of information that is needed to continuously challenge current ideas and concepts.  Diversity of ideas helps ensure that the ideas and concepts that are finally accepted and leave the incubator of the micro-community have been challenged intellectually before they have to compete head-on with more entrenched positions.  The truism that finding problems in software before you implement it is less expensive and painful is equally true for ideas, concepts and strategies.

I think we have all heard the definition of insanity; “doing the same thing over and over again and expecting different results” attributed to Einstein and strive to avoid falling into that trap. The problem is that many of us have the expectation that a strategy for change that worked once will work again.  As change agents we must remember that regardless of how close the context appears, it is different.   It is different if for no other reasons than time has passed and both you and those you are leading in change have been exposed more life events.   Have you constructed an echo chamber?    Decisions in an echo chamber put you and your change program at risk.  To paraphrase Ronald Reagan, “Mr. Change Agent, open your mind!  Mr. Change Agent, tear down this wall!”

[1] Seth Godin, “Seth Godin on tribes we lead”, TED2009,


Get every new post delivered to your Inbox.

Join 3,303 other followers