Categories
Articles

Cognitive Dissonance in Programming

Cognitive Dissonance in Programming

In the field of psychology, cognitive dissonance is the mental discomfort (psychological stress) experienced by a person who simultaneously holds two or more contradictory beliefs, ideas, or values. The occurrence of cognitive dissonance is a consequence of a person performing an action that contradicts personal beliefs, ideals, and values; and also occurs when confronted with new information that contradicts said beliefs, ideals, and values.

In the fable of The Fox and the Grapes, by Aesop, on failing to reach the desired bunch of grapes, the fox then decides he does not truly want the fruit because it is sour. The fox’s act of rationalization (justification) reduced his anxiety about the cognitive dissonance occurred because of a desire he cannot realize.

Programming – perhaps more than any other profession – is an individual activity, depending on the abilities of the programmer himself, and not upon others. What difference can it make how many other programmers you run into during the day? If asked, most programmers would probably say they preferred to work alone in a place where they wouldn’t be disturbed by other people.

The ideas expressed in the preceding paragraph are possibly the most formidable barrier to improved programming that we shall encounter. First of all, if this is indeed the image generally held of the programming profession, then people will be attracted to, or repelled from, entering the profession according to their preference for working alone or working with others. Social psychologists tell us that there are different personality types – something we all knew, but which is nice to have stamped with authority. Among the general personality traits is one which is measured along three “dimensions” – whether a person is compliantaggressive or detached. The compliant type is characterized by the attitude of liking to work with people and be helpful. The aggressive type wants to earn money and prestige, and the detached type wants to be left to myself to be creative.

Now, every person contains a mixture of these attitudes, but most people lean more heavily in one direction than the others. There is no doubt that the majority of people in programming today lean in the “detached” direction, both by personal choice and because hiring policies for programmers are often directed toward finding such people. And to a great extent, this is a good choice, because a great deal of programming work is alone and creative.

Like most good things, however, the detachment of programmers is often overdeveloped. Although they are detached from people, they are attached to their programs. Indeed, their programs often become extensions of themselves – a fact which is verified in the abominable practice of attaching one’s name to the program itself. But even when the program is not officially blessed with the name of its creator, programmers know whose program it is.

Well, what is wrong with owning programs? Artists own paintings; authors own books; architects own buildings. Don’t these attributions lead to admiration and emulation of good workers by lesser ones? Isn’t it useful to have an author’s name on a book so we have a better idea of what to expect when we read it? And wouldn’t the same apply to programs? Perhaps it would – if people read programs, but we know they do not. Thus, the admiration of individual programmers cannot lead to an emulation of their work, but only to an affectation of their mannerisms. This is the same phenomenon we see in art colonies, where everyone knows how to look like an artist, but few, if any, know how to paint like one.

The real difficulty with property-oriented programming arises from another source. When we think a painting or a novel or a building is inferior, that is a matter of taste. When we think a program is inferior – in spite of the difficulties we know lurk behind the question of good programming – that is a matter at least potentially susceptible to object proof or hypothesis. At the very least, we can put the program on the machine and see what comes out.

An artist can dismiss the opinions of a critic if they do not please him, but can a programmer dismiss the judgment of the computer?

On the surface, it would seem that the judgment of the computer is indisputable, and if this were truly so, the attachment of a programmer to his programs would have serious consequences for his self-image. When the computer revealed a bug in his program, the programmer would have to reason something like this:

This program is defective. This program is part of me, an extension of myself, even carrying my name. I am defective.

But the very harshness of this self-judgment means that it is seldom carried out.

Starting with the work of the social psychologist Leon Festinger, a number of interesting experiments have been performed to establish the reality of a psychological phenomenon called “cognitive dissonance”. A classical experiment in cognitive dissonance goes something like this:

Writing an essay

Two groups of subjects are asked to write an essay arguing in favor of some point with which they feel strong disagreement. One group is paid $1 apiece to write this argument against their own opinions, the other is paid $20 apiece. At the end of the experiment, the subjects are re-tested on their opinions of the matter. Whereas common sense would say that the $20 subjects – having been paid more to change their minds – would be more likely to change their opinions. Cognitive dissonance theory predicts that it will be the other group which will change the most. Dozens of experiments have confirmed the predictions of the theory.

The argument behind cognitive dissonance theory is quite simple. In the experiment just outlined, both groups of subjects have had to perform an act – writing an essay against their own opinions which they would not like to do under normal circumstances.

Arguing for what one does not believe is classed as insincerity or hypocrisy neither of which is highly valued in our society. Therefore, a dissonance situation is created.

The subject’s self-image as a sincere person is challenged by the objective fact of his having written the essay.

Dissonance, according to the theory, is an uncomfortable and unstable state for human beings, and must therefore be quickly resolved in one way or another. To resolve a dissonance, one factor or another contributing to it must be made to yield. Which factor depends on the situation, but, generally speaking, it will not be the person’s self-image.

That manages to be preserved through the most miraculous arguments. Now, in the experiments cited, the $20 subjects have an easy resolution of their dissonance:

Of course, I didn’t really believe those arguments. I just did it for the money.

Although taking money to make such arguments is not altogether the most admirable trait, it is much better than actually holding the beliefs in question.

But look at the difficult situation of the dollar group. Even for poor college students – and subjects in psychological experiments are almost always poor college students – one dollar is not a significant amount of money. Thus, the argument of the other group does not carry the ring of conviction for them, and the dissonance must be resolved elsewhere. For many, at least, the easiest resolution is to come to admit that there is really something to the other side of the argument after all, so that writing the essay was not hypocrisy, but simply an exercise in developing a fair and honest mind, one which is capable of seeing both sides of a question.

Another application of the theory of cognitive dissonance predicts what will happen when people have made some large commitment, such as the purchase of a car. If a man who has just purchased a Ford is given a bunch of auto advertisements to read, he spends the majority of his time reading about Fords. It was a Chevrolet he purchased, then the Chevrolet ads capture his attention. This is an example of anticipating the possibility of dissonance and avoiding information that might create it. For if he has just purchased a Ford, he doesn’t want to find out that Chevrolet is the better car, and the best way to do that is to avoid reading the Chevrolet ads. In the Ford ads, he is not likely to find anything that will convince him that he is anything but the wisest of consumers.

Now, what cognitive dissonance has to do with our programming conflict should be vividly clear. A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct – even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with the symptoms of this dissonance resolution – in others, of course. The programmer comes down the hall with his output listing and it is very thin. If he is unable to conceal the failure of his run, he makes some remark such as:

It must be a hardware problem.

or

There must be something strange in your data.

or

I haven’t touched that code in weeks.

There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple

I goofed again

Of course, where the error is more subtle than a complete failure to get output – which can hardly be ignored – the resolution of the dissonance can be made even simpler by merely failing to see that there is an error. And let there be no mistake about it: the human eye has an almost infinite capacity for not seeing what it does not want to see. People who have specialized in debugging other people’s programs can verify this assertion with literally thousands of cases.

The human eye has an almost infinite capacity for not seeing what it does not want to see.

Programmers, if left to their own devices, will ignore the most glaring errors in their output – errors that anyone else can see in an instant. Thus, if we are going to attack the problem of making good programs, and if we are going to start at the fundamental level of meeting specifications, we are going to have to do something about the perfectly normal human tendency to believe that ones “own” program is correct in the face of hard physical evidence to the contrary.

Image Credits:

Photo by Ián Tormo on Unsplash
Categories
Articles

Why experience and intuition can ruin decision making?

Why experience and intuition can ruin decision making?

There is more than one way. There is always more than one way.

There is more than one way. There is always more than one way. This simple credo can be a practical beacon throughout our professional life, leading us to consider alternatives in how software might be organized and how people might be organized. But recognizing alternatives also carries a burden, the burden of making decisions. Developing better software means making choices among alternatives and, better still, finding that creative synthesis that integrates the best of several approaches and thereby exceeds them all. Well-organized teams that base decision making and problem solving on consensus have the best shot at making quality decisions and building such a creative synthesis, but they need to know how to avoid certain traps common to groups. The secrets of consensus-based teamwork are worth exploring.

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it!

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it, which means that successful families and companies make sure there is plenty of opportunity to practice the real thing. By mid-career, the typical professional programmer has solved countless problems and along the way has probably made many thousands of decisions. Naturally, we expect professionals to become good at it. But most of these decisions will have been made individually, by the programmer on her or his own, and problem solving and decision making in groups are different animals altogether.

Risks of Mediocrity

In the early ages, much study and concern were focused on supposed defects of group problem solving and decision making, particularly the effects of the so-called risky shift and the counter-tendency of groups to pull toward a mediocre mean. In those conservative days, even democratically minded managers worried more about the risky-shift than about creeping mediocrity.

According to the research, collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently. If this model applied to programming, we would expect groups to produce software that used more exotic data structures or more unconventional algorithms or more obscure language features. However, other research on group dynamics seemed to show that groups had a leveling effect on problem solving and decision making that reduced results to a kind of lowest common denominator of individual contributions and abilities. Either way, the lone decision maker seemed to have an edge.

Collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently.

The social and organizational climate in which a group works is what really shapes the ability to perform up to potential. For best results, the corporate culture and group leadership must actively encourage and support innovation and collaboration. In a sense, some teams did perform well, meeting the real expectations of bosses and enterprise policy makers, which were based more on covering the backside than achieving results.

Leading Lightly

In consensus design and decision making, the role of the group leader is crucial, not only in establishing the overall climate for collaboration but also in the detailed way in which leadership is exercised. Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all, not just an average of their contributions, but a genuine synthesis that combines their best. When group leaders, however talented and brilliant, push their own agenda, the quality of teamwork goes down. The effect of group leadership can be as insidious as it is subtle. Even just expressing an opinion at the wrong time can bias a group and lead to a poorer outcome. Research has shown that merely having leaders delay tossing in their own ideas until after all or most group members have presented theirs will improve the group solutions. That means that a leader who merely speaks too soon is probably degrading the quality of team-work. Confident leaders, sure that they are right or know best, may cause the most difficulty.

Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all.

Techies at heart

Most project leaders and mid-level managers in software development are really techies at heart. Nearly every one of them was promoted up from programming, systems analysis, and software engineering. They got where they are by being good at software development. For many, it is hard to let go of the keyboard, letting someone else actually do the work and make the technical choices.

Most of us as managers are prone to one particular failing: a tendency to manage people as though they were modular components. It’s obvious enough where this tendency comes from. Consider the preparation we had for the task of management: We were judged to be good management material because we performed well as doers, as technicians and developers. That often involved organizing our resources into modular pieces, such as software routines, circuits, or other units of work. The modules we constructed were made to exhibit a black-box characteristic, so that their internal idiosyncrasies could be safely ignored. They were designed to be used with a standard interface.

We were judged to be good management material because we performed well as doers, as technicians and developers.

After years of reliance on these modular methods, small wonder that as newly promoted managers, we try to manage our human resources the same way. Unfortunately, it doesn’t work very well.

The Discussion Leader

We now know that one of the most important factors in achieving first-rate problem solving through consensus is having neutral leadership. The position of discussion leader is so powerful that whoever leads or facilitates meetings and discussions must be assiduously neutral about the outcome in order that the best of what the group has to offer can emerge.

Such a leader is everyone’s friend and nobody’s advocate. Such a leader draws out the contributions of all without favoring any. Such a leader helps the group to build its own technical consensus without biasing the outcome or pushing a private agenda.

Ironically, what this means is that project managers and official team leaders are probably the worst choice for leading any discussions or meetings directed at technical problem solving and decision making. They have too much at stake. In a sense, they probably also know too much. The stronger they are as leaders, the more likely they are to actually dampen the free-spirited exploration of alternatives and the building of technical consensus that lead to the best results.

It’s a popular vision that leaders are diligent, thoughtful decision makers. They gather all the relevant facts, weigh them, and come up with the logical, rational decision. But in fact, that idealized process is basically never followed, even by expert, high-pressure decision makers.

Instead, we make decisions and solve problems based on faulty memory and our emotional state at the time, ignoring crucial facts and fixating on irrelevant details because of where and when they occur or whether they are brightly colored.

Some managers take a completely hands-off approach and try to stay out of the technical problem solving altogether; however, this is not ideal for their teams, who are deprived of the manager’s experience and expertise, or for the managers, who miss out on much of the fun. The best of them will turn over meetings and discussions to a neutral facilitator, then practice staying in the background, learning how to contribute without dominating. Some may never learn how to do this, but many actually enjoy being able to be “one of the bunch” again, taking part in technical discussions on equal footing with the rest of the team.

References

  • Peopleware by Larry Constantine
  • Peopleware by Tom DeMarco and Tim Lister
  • Pragmatic Learning & Thinking: Refactor Your Wetware by Andy Hunt

Image Credits

  • Photo by Caleb Jones on Unsplash
  • Photo by Clem Onojeghuo on Unsplash
  • Photo by Josh Calabrese on Unsplash
  • josh-calabrese-236920-unsplash
  • Photo by Dylan Gillis on Unsplash
  • Photo by rawpixel on Unsplash
Categories
Articles Javascript

A Refreshing Guide to Object.freeze in Javascript by Dr.Victor Fries

A Refreshing Guide to Object.freeze in Javascript by Dr.Victor Fries

What killed the dinosaurs? The Ice Age!

In JavaScript, objects are used to store keyed collections of various data and more complex entities. Objects penetrate almost every aspect of the JavaScript language.

The object might be accessed as global or passed as an argument. Functions that have access to the object can modify the object, whether intentionally or accidentally. To prevent modification of our objects, one of the techniques is to use Object.freeze().

Freezing an object can be useful for representing a logically immutable data structure, especially if changing the properties of the object could lead to bad behavior elsewhere in your application.

Allow me to break the ice: My name is Object.freeze(). Learn it well, for it’s the chilling sound of your doom.

The Object.freeze() method freezes an object: basically it prevents four things from an object:

The method returns the passed object.

Let’s kick some ice!

Tonight’s forecast… a freeze is coming!

Nothing can be added to or removed from the properties set of a frozen object. Any attempt to do so will fail, either silently or by throwing a TypeError exception (most commonly, but not exclusively, when in strict mode).

For data properties of a frozen object, values cannot be changed, the writable and configurable attributes are set to false. Accessor properties (getters and setters) work the same (and still give the illusion that you are changing the value). Note that values that are objects can still be modified, unless they are also frozen. As an object, an array can be frozen whereafter its elements cannot be altered. No elements can be added or removed from it as well.

The function returns the passed object. It does not create a frozen copy.

Tonight, hell freezes over! (Freezing Objects)

I’m putting array on ice (Freezing Arrays)

The object being frozen is immutable. However, it is not necessarily constant. The following example shows that a frozen object is not constant (freeze is shallow).

To be a constant object, the entire reference graph (direct and indirect references to other objects) must reference only immutable frozen objects. The object being frozen is said to be immutable because the entire object state (values and references to other objects) within the whole object is fixed. Note that strings, numbers, and booleans are always immutable and that Functions and Arrays are objects.

Freeze in hell, Batman! (The Shallow Freeze)

The result of calling Object.freeze(object) only applies to the immediate properties of objectitself and will prevent future property addition, removal or value re-assignment operations only on object. If the value of those properties are objects themselves, those objects are not frozen and may be the target of property addition, removal or value re-assignment operations.

Everything freezes! (The Deep Freeze)

In this universe, there’s only one absolute… everything freezes!

To make an object immutable, recursively freeze each property which is of type object (deep freeze). Use the pattern on a case-by-case basis based on your design when you know the object contains no cycles in the reference graph, otherwise an endless loop will be triggered. An enhancement to deepFreeze() would be to have an internal function that receives a path (e.g. an Array) argument so you can suppress calling deepFreeze() recursively when an object is in the process of being made immutable. You still run a risk of freezing an object that shouldn’t be frozen, such as window.

Object.freeze vs const

const and Object.freeze are two completely different things.

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, solely that the variable identifier can not be reassigned.

const applies to bindings (“variables”). It creates an immutable binding, i.e. you cannot assign a new value to the binding. Object.freeze works on values, and more specifically, object values. It makes an object immutable, i.e. you cannot change its properties.

In ES5 Object.freeze doesn’t work on primitives, which would probably be more commonly declared using const than objects. You can freeze primitives in ES6, but then you also have support for const. On the other hand const used to declare objects doesn’t “freeze” them, you just can’t redeclare the whole object, but you can modify its keys freely. On the other hand you can redeclare frozen objects.

Object.freeze vs Object.seal

Objects sealed with Object.seal() can have their existing properties changed. Existing properties in objects frozen with Object.freeze() are made immutable.

The following related functions prevent the modification of object attributes.

Function Object is made non-extensible configurable is set to false for each property writable is set to false for each property
Object.preventExtensions Yes No No
Object.seal Yes Yes No
Object.freeze Yes Yes Yes

Winter has come at last

Yes! If I must suffer… Humanity will suffer with me! I shall repay them for sentencing me to a life without human comfort. I will blanket the city in endless winter! First… Gotham. And then… The world!

Hope, you enjoyed the article and learned something new about Object.freeze() in Javascript. Please show us your love by sharing the article and let us know your views in the comments.

Categories
Articles

Consensus and Compromise

Consensus and Compromise

Getting the most from a software development team depends on the ability to build technical consensus among the professionals on the project. But why should it matter whether you and your office mate agree on the layout of an entry form or the best way to report error messages? Technical consensus is not about getting along together or feeling close to your fellow programmers. (Not that there is anything wrong with getting along or feeling good about each other.) Technical consensus is about taking full advantage of all the skills and experiences of every team member. It’s about building better software.

Technical consensus is not about getting along together or feeling close to your fellow programmers.

Software professionals may understand good software, or at least claim to know it when they see it, but technical consensus is a lot less well understood among developers. Probably most software developers have had some bad experiences with what they thought was design by consensus. They’ll tell you tales of brilliant ideas being lost in discussions, about compromising their artistic integrity, about six-month projects that took years, and about groups that settled for less than the best. Listen carefully and you’ll realize that what they are talking about is not consensus at all, but compromise. What’s the difference?

Unpromising Compromise

Compromise is neither one thing nor another but something halfway in between, which often means in the middle of nowhere. Consider this variation on a classic example. Your team is designing a graphical user interface. One group strongly advocates placing the control buttons across the bottom of the screen, another is pushing for a panel down the left side. Between these horizontal and vertical extremes, a perfectly objective compromise can be struck: just place the buttons along a diagonal across the middle of the screen!

A compromise, like this one, is frequently worse than any of the original alternatives, but a consensus solution can be better than all of them. Technical compromises often fail to account for the merits in each of the alternatives, and their advantages are lost by taking some kind of average position. True consensus is not based on compromise, in which everyone and every position loses a little, but on synthesis, in which everyone wins big. The payoff, of course, is better software.

Technical compromises often fail to account for the merits in each of the alternatives, and their advantages are lost by taking some kind of average position.

A synthesis is something original that incorporates essential features of each contributing idea or proposal. In the interface design example given above, it’s easy to see a creative synthesis in which the placement of the button panel is an option selectable by the user. Not only does a consensus based on synthesis incorporate the best of the alternatives, but new features or capabilities typically emerge from the combination. Out of the synthesis of horizontal and vertical button panels might emerge end-user customization. The product thus incorporates the best of both worlds, not the worst. Building real consensus is not easy, as politicians and labor negotiators know all too well. Building a technical consensus is a little different from building political consensus, but it has some of the same elements. Both take a commitment to working things out; both require a certain faith in the process.

Consensus Is Neither Compromise Nor Coercion

Confusing consensus with compromise may be the great “wives’ tale” that undermines the collaborative nature of meetings. The Thomas-Kilmann conflict mode instrument provides clear differentiation between the compromising individual and the collaborative individual. This is useful when considering a definition of consensus for an organizing tool:

  • Individuals who have some ability to cooperate while remaining somewhat unassertive engage in a compromising conflict mode.
  • The very assertive and very cooperative person uses the collaborating mode of conflict resolution.

True consensus, therefore, relies on a collaborative mode of reaching decisions versus a compromising mode.

True Believers

Team members need to believe that it is possible to reach a technical synthesis incorporating the best elements and aspects of everyone’s contributions. Believing this, they will stubbornly look for something better, rather than settle on compromise or cling needlessly to personal favorites. By persisting, they build their understanding of the problem and the nature of the strengths and weaknesses of each approach. From this, they enhance the odds of finding that creative something that exceeds them all.

Consensus design also works best when each of us believes that building a better piece of software is more important than getting our own favorite ideas into the result in some predetermined form. This investment in the quality of the outcome makes it easier to see the merits of whatever ideas emerge from the group process.

It helps, of course, if teamwork is applauded over individual pyrotechnics. Companies that reward individual performance instead of group success, or those that promote the lone wolf programmer over the team player, typically end up with a staff of uncompromising loners who probably will not and cannot play team sports. Such companies will rightly conclude that the best software is produced by their frontier-type geniuses. What they don’t realize is that they’ve set it up to come out that way. Other outcomes are possible, of course.

One essential rule in building technical consensus is: No horse trading! Trading votes or support or influence is one of the classic tactics for political success, but it can destroy technical effectiveness. For example, we might work a trade in the interface design. I’ll agree to your stupid idea of having the button panel across the bottom, if you agree to my clever design for icons without labels. The result is an interface that is less than the best in not one, but two features. Horse trading is just compromise in another disguise, but compromise made worse because decisions in one area contaminate those in another. Good technical consensus must see each issue as a separate problem, to be resolved on the merits, not as part of a point scoring system in which concessions in one area can be traded for obstinacy in another.

Just the Facts

One likes to think that technical decisions are made on the basis of technical issues—facts, measurable quantities, practical considerations. The truth is that feelings, opinions, intuition, and just plain biases are part of any decision-making or problem-solving process involving people. This is the reality of what it is to be human, and although some people try to deny, control, or suppress these nonrational aspects, it never works completely.

An essential skill of any team that hopes to build technical consensus is to learn to separate fact from opinion. If the group, collectively, is to make the best decisions and solve problems creatively, they need access to the best information and to know what kind of information they have. Opinions aren’t bad; team members should be able to express them freely. Opinions can even be useful, especially when weighted by hard-won experience, but they must not be confused with facts or data or analyses. Facts, too, have their limitations. In the areas of aesthetics or marketing appeal, facts may be in short supply. Unfortunately, once some group members have made up their minds, they do not want to be bothered by facts.

Calling something a fact doesn’t make it so, and groups have to learn to cut through the bull and agree not to abuse the language.

Consensus: I Can Live with That and Support It

A collaborative meeting strives toward highly participatory decision making. But what constitutes agreement about decisions? And how much agreement must a team have to move forward comfortably with other work? Consensus-driven decisions form the most sustainable agreements a team can use to create action. Therefore, a collaborative meeting includes a posted definition of consensus as one of its organizing tools.

We can use a definition that removes the binary or black-and-white connotations from the notion of agreement and instead reinforces the notion of agreement without compromise and without violent dissention. Simply stated, consensus means: I can live with that and support it.

This helps participants understand that collaboration can be achieved in a team without everyone being wildly enthusiastic about the choice. The choice reflects a shared understanding by the team. The choice is good enough to live with and support. The choice is adequate to help us move forward. The choice has enough of a team sense that no one feels completely left out of it.

Teams that agree to work in a consensus-driven mode make a few implicit statements to one another as they begin a meeting:

“We believe that any decision made by the team is better than a decision made by an individual” This does not mean that the team cannot have experts that give very strong recommendations to the team about how to proceed. Experts often provide the necessary rocket fuel to help teams move forward and maintain focus on the larger collaborative issues. This is especially true in our technical environments in which we have to rely on specialists in a variety of domains in order to converge on our complex “righteous solutions” for our “wicked problems.” Experts ensure that the team has accessed its greatest wisdom in order to build the best overall solution.

“We understand that gaining consensus can take more time”. Because of the work and commitment it takes to gain consensus in a highly charged issue, a team has to understand at the start what is required of them. They may choose to reserve consensus for critical, high-risk decisions only.

“We may not seek consensus for all decisions” Some conflicts are not so important as to warrant the time to resolve it to a consensus level of agreement. Therefore, once meeting participants truly understand the meaning of consensus, they can then more knowledgeably choose when to use less time-consuming forms of decision making.

Trina Hoefling (author of Working Virtually ), a facilitator who specializes in conflict resolution, leads teams through a decision process at the very start of any meeting to help them decide explicitly about their consensus organizing tool:

“When will we use consensus to resolve conflict? When consensus is not warranted, what other decision-making process will we use?”

By making these clarifications at the very start of the meeting and posting them, Trina helps the team move along at a pace that works for them with regard to consensus building. In sum, teams decide which decisions are important enough that they should only be resolved in consensus, and which decisions can be taken through a less enduring approach.

Teams who believe in consensus and use it appropriately are teams that are able to work more and more collaboratively.

Image credits

  • Photo by Fabian Burghardt on Unsplash
  • Photo by Kevin Gent on Unsplash
  • Photo by Joshua Clay on Unsplash
  • Photo by rawpixel on Unsplash
  • Photo by rawpixel on Unsplash
  • Photo by mike-erskine on Unsplash