In the room, 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 there was no blame for his company or department.
I then asked all but three to leave. Twenty brilliant people cannot effectively work on a project that should be completed by two or three, especially if they have competing goals.
This was not an issue that had to be resolved by a committee; but rather a problem that needed to be converted to a project, then executed to a conclusion by a small, effective team.
I was not interested in resolving any issues. I don't work on issues. This was not a complex project. It deserved answers, and fast. To get those answers, we needed a good tactical plan. Sure, some projects are complicated. 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 they are integrated with the business strategy.
By noon we had answered the following questions:
1. How is the tank supposed to function? How many functions does it perform? Which are high-risk functions?
2. Which function is it failing to perform?
3. 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 failure; and proposed tactical fixes, which were 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 included a few of the people who had earlier been asked to leave. The size of the team, however, was kept small by removing those 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 roles change, a team becomes a committee and loses focus.
I have never seen a large team assigned to a narrowly defined technical project work well in a factory that has to continue to operate. I have, however, seen small teams solve complex problems without interfering with operations.
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. But this is not a model for engineers to think their way through a technical problem.
When given an assignment, you have to determine if the project deals with an issue or a problem. They are not the same thing. The tactical approach for one will fail for the other.
Solving technical problems is a lot easier than resolving issues. That being the case, why would one think in terms of issues when there is an easier, more efficient way? 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 are a team member. It will make it a lot simpler if you can keep it out of the convoluted world of issues.