Your Problem Solving Team
This post is the second of at least three posts in my problem solving mini-series. Think of this as “more lessons learned along the way”. In my career, I’ve been part of a bunch of problem solving activities/projects/blitzes etc. Over time, I’ve developed a sort of ‘radar’ that clues me in that I am dealing with people who aren’t plugged in or who think they already have the answers. These clues don’t lead me to knowing who is “in” and who is “out”, just who might need to be dealt with differently than others. Without further ado, here’s my list of red flags:
- Saying “I think” – Unless you are brainstorming or there is a very specific reason, problem solving is not usually the time for a soapbox. It should be a time to focus on data and facts.
- Ignoring data – Often, people come in to an activity with the ‘solution’ in their head or a bias towards some particular actions. These folks can cause a lot of havoc in sidetracking others.
- Placing TOO much faith in data – The flipside of the above problem. Some folks become so data focused that they fail to see potential pitfalls with the data being used or the real world impact of what is happening.
- Talking about the way they solved this problem “in their old job” – While the problem you are solving is probably not unique to the world, solutions aren’t generally ‘copy and paste’ ready. And, even if they are, the cause and effect needs to be understood in your specific case before implementing the solution.
- Being overly confident in the skills of the team – I’m a firm believer that people can learn and contribute at whatever level they may be at. However, sometimes you need to consider the limitations in skills and/or experience that the team has so you can learn how to augment it.
These aren’t hard and fast rules, but some of the key flags I’ve come across in the past. What about you…any red flags you have found?