Noticing and avoiding the Abilene Paradox

The Abilene Paradox is a management theory introduced in 1974 by Jerry B. Harvey, Ph.D.

He writes a story about four people, himself, his wife, and his in-laws are sitting together in Coleman, Texas, on a sweltering summer afternoon.

They all agree to go to Abilene, 50 Miles/ 80 Km away, for dinner. But, on the way back, they are all angry at each other because they all claimed they didn’t want to go and only went because of the other.

The conversation in the original article, “The Abilene Paradox: The Management of Agreement,” started it off like this. The father-in-law says. “I’d love to have dinner at this lovely place in Abilene.”

His wife said, “Yes, it sounds like a great idea.” Then Mr. Harvey, thinking this would be a bad idea to drive over an hour in a car with no air conditioning, says, “Well, if your mother wants to go, I’ll go.” His mother-in-law replies, “Well, of course, I want to go.”

Looking at how this article started, we can look at other examples and discuss how people, especially those who want to lead, can avoid it.

In addition, there are other examples where one person might agree to something that others find a waste of time but go along with it.

We will also cover how these fit with the “Abilene Paradox” and how to recognize and avoid this.

Examples of mismanaged agreements

1) The Sofa Story

One gentleman wrote about a sofa in his apartment that he hates and called it managing false assumptions. He bought the couch together with his wife because he heard his wife say, “It looks nice.” She later said that she said it because he gave the impression that he liked it. So now they both have a sofa in their apartment they both hate.

Lesson learned

In the future, especially when money is involved: Both parties will ask if the other person really likes the article in the discussion. Remember to be honest with your feelings about things you want. Especially on a decision, you would have to live with for a long time.

2) Missing High-Level Design

An IT Project Manager led a sub-project to design a new Data Base setup for a large client’s new Data Center. To know how large a network was needed and how many types of Servers would be, he needed a High-Level Design that was agreed upon by the client. Unfortunately, the project had already started before he took over.

He said when he took over the project, the Lead Project Manager told his predecessor to design the Network and Data Base setup without the High-Level Design. Everyone agreed to do it, despite not knowing the basic information, “What kind of Network connection is coming from the IT Provider and to the other offices?” and “What kind of Power System is in the Data Center where the Data Base Servers will be?” Other fundamental questions should have been answered.

He said his predecessor and his team created three designs that wouldn’t work before finally being taken off the project, stating that he and his team could not deliver a design the client wanted.

When the new Project Manager took over, the Lead Project Manager also told him to have his lead IT Architect create a design without the needed information. The new PM asked his lead IT Architect if this was possible and told him not to worry about making anyone happy. His IT Architect replied, “There is no way I can do that without this information.”

The Project Manager returned to the Lead Project Manager and said, “We aren’t doing anything until you get an overall lead Architect that can put together a basic design While working with his IT Architect.” He also clarified that he would walk if the Lead Project Manager disagreed.

None to say, the new Project Manager ended up replacing the Lead Project. The newly promoted Lead Project Manager took the concerns about the essential questions to the client, who was happy to give the needed information.

In this case, the previous Project Manager was afraid to speak up and was replaced. Then the Lead-Project Manager was afraid to discuss anything with the client or lead IT Architects out of fear he would look bad. Finally, the new Sub Project Manager saved the overall project by speaking up and received a promotion to Lead Project Manager.

Lesson Learned

Always speak up. If you are against an idea, don’t worry about what others think or want. Instead, make it clear you see a problem and address it.

Sometimes, it is better to walk away on your terms than to be released for not being able to complete a task you knew couldn’t be done with the information you never received.

3) The Wrong Lamps

A Construction Manager told me he was responsible for constructing some condominium apartments. The hallway lamps ordered initially weren’t going to arrive before the deadline. So, the head electrician grabbed the catalog from the company they ordered the original lamps, randomly pointed at a lower-priced set, and said, “Let’s just install these.”

The Construction Manager thought they were ugly and would not be as bright as needed to see in the hallway clearly. He decided the head electrician knew what he was doing but decided to ask the owner what she thought. The building owner glanced at the lights and, without hesitation, agreed.

After the lights were installed, as the Construction Manager thought, the lights didn’t give off enough lights. As in the Abilene story, she said, “I never really liked those lamps.” The electrician said, “I thought you guys would look further, as I only randomly pointed.”

Lesson learned

In this case, the lesson learned was to ensure each person looked at the lamps and discussed the technical differences. Look at how much lighting the proposed idea has. Even though the final blame went to the electrician, as he is the expert, everyone agreed to buy the proposed lamps. Everyone was to blame.

Areas where only one agrees it is the right thing but isn’t

4) The job title that didn’t matter

A man told me he was the Project Manager for the Development team, one of ten teams in a project where they were starting the rollout of a new Data Base for his company. He said when they were ready to move into production, they had a meeting about how to work with the “After Care Support.”

The importance of the meeting was as follows. First, to discuss the processes to follow when handling calls from clients when there is a problem. Second, to look at the process for testing the access to the new Data Base.

During the meeting, the presenter spoke about how the primary tester holding the title “Super User” would follow the process. The Project Manager of the Finance Team didn’t like the title of “Super User” and spoke up, giving all kinds of reasons and regulations. The presenter said this didn’t matter and we should continue with the presentation. However, the Finance Teams Project Manager would not back off and continued arguing. This “discussion” continued for over 20 minutes.

The Project Manager for the Development team noticed how much time had gone by with no end in sight, and nobody else seemed to wish to speak up; he spoke up. He just stood up and said, “Why are we discussing this? Does it really matter?” When only the Finance Teams PM replied, “It does.” He said, “Then let’s take a vote”.

He went to the Whiteboard, wrote down the name “Super User,” then asked the Finance PM, “What title do you want?” The finance PM said, “Senior test person.” So, he wrote that down.

He said when he counted the votes out of 15 people, two wanted “Senior test person,” one wanted “Superuser,” and 12 didn’t vote. He then turned to the presenter and said, “Please change the name to Senior test person.”

Lesson learned

Even in a case where a subject doesn’t matter, speak up. In a business world where you are one of the leaders, you should remember time is money. In this case, 45 minutes were lost, counting the time needed for the Development PM to get people to agree. If he didn’t speak up, more time would have been lost.

5) Extra training

Once, a construction manager told me how his supervisor wanted his team and the other teams to take a class on a new method for mixing concrete.

He asked the other construction managers what their teams thought about it, but all the people who were to take the course were against it. His team was especially against it as they were responsible for the electrical installation and had never worked with mixing concrete. The team who works with concrete said they are already using the method in the class. Therefore, they didn’t need it.

After speaking with all the construction managers, he asked if anyone should bring this up with the supervisor. They all said they were scared to discuss it with him since he had already made his mind up on the subject.

They all took the course, which cost the company $250 per person, times 25 people. In addition, it was half a day when nobody was working on any of the company’s construction sites.

Lesson learned

The construction manager learned that if he rationally went to the supervisor to show him the cost, and the one team of five who would benefit, was already using the new method, it would have been canceled.

Also, if you are in a situation where you would never be able to speak rationally with your superiors on such decisions, it would be advisable to move to another job when the chance arrives.

Summary

In all cases, it sums up to people who are afraid to speak up. To become a good leader, consider that people will often agree to things out of fear of speaking up. This is because people are so scared to hurt other people’s feelings they would just walk with the crowd.

Always be prepared to find a way to rationally explain why you are not for taking part in something. When speaking up, remember, “You can catch more flies with honey than with vinegar,” so try to be friendly when speaking up.

Author

  • Ken Tillery - Project management expert and contributor

    Ken holds a Master of Science in Global Management and currently works as a Global Project Manager and has worked as a Global Service Delivery Manager. Ken spent the last 15 years leading globally dispersed teams with team members located in multiple countries. Has also given classes on how to deal with cultural differences and related issues when working with project teams with members located across borders and continents.

    View all posts