Printer Friendly

Machines don't have issues--only people do.

"WE HAVE AN ISSUE with a leaking fuel tank, and the team is stuck. We need our help right away." An issue about leaking gasoline? That sounded more like a problem to me!

I arrived at the client site at 10:00 p.m. that same night, tired and a little grouchy (okay, more than a little grouchy), having worked that day, taken two connecting flights and a fifty-odd mile drive on each end, eating only junk food. I needed sleep, but the people assigned to the project were stuck, they said, unable to make progress. They had to report by conference call at 7:00 a.m., and were starting to panic. They wanted to meet with me immediately.

I perceived the nature of the "issue" as soon as I walked into the conference room. At ten p.m., there were more than twenty people sitting around. They were, for the most part, well-meaning engineers and suppliers, doing their best to do as they were told: represent the best interests of their company or department. The conference table was littered with soda cans, spilt coffee, pizza boxes, and half-eaten sandwiches that were beginning to smell. I was invited to dig in, but politely declined.

I immediately knew what was wrong, not with the tank, but with the so-called team. "How many competent engineers," I thought, "does it take to figure out why a few fuel tanks, returned after several weeks in the field, are leaking?" Two or three seemed like a good number for this team. If they could not figure it out, then why were they on the payroll? That's their job.

Two very good engineers had been assigned to work with this large group, but could make no progress at all. Why not? Because they were part of a committee assigned to resolve an issue, not a team organized to complete a project. The tactics were not in phase with the business strategy. And management's interest in a fix for the problem was in conflict with the approach of a committee assigned to resolve an issue. Resolution is not a fix. A team working on a project has to have a specific, well-defined tactical approach that management understands, one that reliably leads to the answer. For technical projects, the approach has to be based upon the physics model I describe in my article, "The Model for Solving Technical Problems." In my experience, this approach works every time.

I asked everyone in the room to introduce themselves. There were representatives from every supplier that provided a component or material for the tank. There were people from every department involved in purchasing, engineering, and approving changes. Each saw it as his responsibility to defend his turf and make sure that no blame accrued to his department, company, or worse, individuals.

I then asked all but three to leave. They could head for the airport at their convenience and go home. Twenty brilliant people cannot effectively work on a project that should be completed by two or three, especially if they have competing goals. I went back to the hotel, slept a few hours, and returned at 6 a.m.

One of the engineers whom I had asked to stay apologized for not making more progress. He didn't have to. He had no chance, not with the rest of the people looking at this as an issue that had to be resolved by a committee, instead of as a problem that needed to be converted to a project designed for execution by a small, effective team.

I was not interested in resolving issues. I don't work on issues. This was not a complex problem. It needed answers, and fast. To get those answers, we required a good tactical plan. Some projects are complicated, and that means we need to be even more disciplined at the tactical level, more focused on making certain that the project has a leader who clearly understands sound tactics and makes sure those tactics fit with the business strategy. Trying to resolve issues at the tactical level is a distraction.

By noon we had answered the following questions:

** How is the tank supposed to function?

** How many functions does it perform?

** Which are high-risk functions?

** Which function is it failing to perform?

** Where is the energy supply coming from that caused the function to fail?

By the end of the day we had:

** Replicated the failure and proven we understood the physics of it; and

** Proposed tactical fixes consistent with the business strategy.

I left at the end of the first day, but stayed in contact with the small team that continued the work over the weekend. They implemented a temporary fix, tested a permanent fix and began the approval process. The leader then brought back to the team a few of the people who had earlier been asked to leave. The size of the team, however, was kept small by removing people as they were no longer needed.

As the tactics changed, the people on the team changed. A good leader knows how to roll people on and off a team, keeping the team small, lean, and effective, while making certain that roles and responsibilities are understood and respected. By including everyone that might be involved, instead of changing team members as the needs and roles change, a team becomes a committee and loses focus.

I have never seen a large team succeed with a narrowly defined technical project in a factory that must continue to operate. I have, however, seen small teams solve complex problems without interfering with operations. Plant managers sure like that!

The approach to solving technical problems becomes corrupted when people make issues out of problems. An issue is political; a technical problem is not. There are no politics around the laws of physics. The more we politicize technical problems, the more we argue about how to resolve issues, and the further we get from the simple laws that we use to make machines work.

When I reviewed this article with a colleague, he told me that the legal department in his company wanted to eliminate the use of the word "defect." They had already told the engineers never to say they had a problem, only issues. Lawyers don't want anyone to know exactly what they mean. Issues are, by nature, a forum for arguments. Goals, once defined at the tactical level, are not. If we never admit that we have a problem, we can argue about it endlessly.

Engineers, however, want others to know precisely what they mean. Engineers need to think their way through a technical problem and to be accurate and precise when they measure. When communicating, they need to be equally accurate and precise, so their meaning is clear and their actions are predictable and repeatable. Language can be distorted to the point where a word can mean many things, or whatever you want. Using selected words, you can obfuscate and confuse, shift blame and never accept responsibility. Engineers cannot work that way.

"Houston, we have an issue," could have meant anything had astronaut Jack Swigert said it from Apollo 13. When a fuel tank exploded, Swigert said (according to Jim Lovell in Lost Moon), "Houston, we've had a problem." The ground control team knew it was serious. They responded accordingly to develop a plan, and divide the tasks into specific assignments. Time was against them. There was no time to discuss issues.

In his January, 2003 editorial, "Affirmative Action: Goal vs. Issue," Washington Post syndicated columnist William Raspberry wrote, "How can a concept like affirmative action split Americans into so many warring factions?... My own conclusion is that virtually all of us are both for and against affirmative action. How we argue about it depends very much on whether we see diversity as a goal--or only an issue." He goes on to say, "Issues, by their very nature, divide. They force us to take sides, to work against one another, to produce winners and losers. That is their political purpose ... Goals, on the other hand, can be shared--even when we embrace different means for reaching them."

Lawyers prefer to identify issues and debate sides, because they intend to divide and polarize. Engineers prefer to investigate problems and set goals, because they intend to coordinate and organize.

There are two sets of laws to which we are all subjected: the laws of man and the laws of physics. The laws of physics are a lot simpler than the laws of man. Issues relate to man-made laws. Technical problems relate to the laws of physics.

When given an assignment, you have to determine if the project deals with issues or problems. They are not the same thing. The tactical approach for one will fail for the other.

Solving a technical problem is much easier than resolving an issue. The foundation of technical problem solving, specifically at the engineering level, is always based upon the laws of physics.

Think about this for your next project, whether you lead the team or just work for it. You will find your work much more successful if you can keep it out of the convoluted world of issues.


Allen, John. Warranty Week, May 31, 2005. ww20050531.html.

Lovell, Jim, & Kluger, Jeffrey. (1994). Lost Moon: The Perilous Voyage of Apollo 13. Boston: Houghton Mifflin Company.

Raspberry, William. (2003) "Affirmative Action: Goal vs. Issue." Washington Post, January 27, 2003. Retrieved June 27, 2005 from:


* John Allen is founder and president of John Allen, LLC, a consulting company in New Hampshire.
COPYRIGHT 2006 Institute of General Semantics
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2006, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Allen, John
Publication:ETC.: A Review of General Semantics
Geographic Code:1USA
Date:Jan 1, 2006
Previous Article:A. E. van Vogt and the World of Null-A.
Next Article:Read House dedication: a new home for general semantics.

Related Articles
Controlling access to supercomputers.
Meeting to look for solutions to meandering of McKenzie.
A story full of holes.
Gambling on gaming: revenues from gambling are just too tempting for troubled state budgets.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters