When you have a problem that you need to solve and require someone’s help to resolve it, you owe it to that person to simplify the matter. This will help them get their head around how to start thinking about potential solutions. Often, I encounter people that have not boiled the problem statement down to a conceptual elevator speech. They approach the would-be helper and proceed to dump all of the pieces of the puzzle - relevant or not - on the table for consideration. Usually, this is because they are confused by the complexity of the scenario and they don’t know where to start, themselves. The result is usually a combination of frustration and expanded confusion. You have to simplify the complex.
You need to simplify if you are escalating to your management for help, because they are busy people. They have a more broad selection of resources at their disposal and are anxious to understand how they can help. They will quickly attempt to observe, classify and sequence the topic and the overview so they can assemble the appropriate talent and resources to measure, infer, predict and communicate the solutions.
They will likely be unable to help if you approach them with thoughts that are not logically sequenced, have an unclear problem statement, and/or don’t demonstrate an understanding of the symptoms. In fact, they are imagining the necessity to arrange the data in a meaningful way, which they might be justified in considering to be your role. It amounts to upward delegation. The most effective means of communicating to your leadership when asking for help is to have the these three statements ready:
With those three statements, any good leader will know how to get started.
The same holds true if you are approaching a peer or cross-functional team member for help. If you haven’t prepared the request in the template of 1 through 3, above, then you appear to just be handing the whole problem over to them to be solved. By handing the whole problem over to someone else, it could come across as “here, this is your mess to solve” and be received as an accusation instead of a request for help. Of course, this usually results in a defensive fortification of silos, erosion of transparent communication and a pile of “evidence” that it is not their fault. A peer or team member are usually willing, and often anxious, to help. A concise, logical and well thought-out introduction to the issue can help them see “the why” and they can see how they fit into “the what”.
Using the three step approach shows that you understand the problem. It shows that you have observed and classified but are simply stuck at a specific point that you believe they can assist get you past. Another benefit is that defining what the problem is, what you’ve done about it and what you are asking of them, is that it is suggestive of a strategy to achieve resolution. The team member will understand what you really want to accomplish with your request for help.
I’ve had issues escalated to me as a request for help where the minutiae related to and not related to the problem was all presented to me in raw data form. It felt like the equivalent of dumping 999 pieces from a 1000 piece puzzle on my desk and asking me to figure it out. So, I set out to boil it down to the simplest terms. You have to understand the objective and then work from the first step to the last for what is required to achieve the objective. Once we had the steps understand and arranged them into a critical path, we had to consider where we were in the process and what was missing. We used only a very small percentage of the “information” that he brought to me for consideration. It’s easier to embellish the critical path with the decoration of additional details as they become relevant than it is to attempt to understand every single piece of information available whether it is relevant or not. Boil it down to the basics and add as required for problem solving. We developed a credible plan and a logical strategy in a fraction of the time it took to admire the entire data set of anything that has to do with everything.
If you believe in the generalization of problem solving into the following 7 sequential steps (also stated above):
then you can start to appreciate that this article is about a), b) and maybe c).
Once you understand the problem and what you are asking for, the real problem solving starts. Tools like Kepner-Tregoe methodology (my personal favorite), 8D, fishbone diagrams, and Shanin Red-X are examples of tools you use once you’ve set the stage for what you are really trying to accomplish and defined how other resources on your team can help. This article was intended to focus on eliminating the “ready, FIRE!, aim” approach to asking for help. I believe following this advice will increase your worth to your company and increase your effectiveness in securing assistance. Don’t be afraid to do a little work getting organized before you ask for help.
You need to simplify if you are escalating to your management for help, because they are busy people. They have a more broad selection of resources at their disposal and are anxious to understand how they can help. They will quickly attempt to observe, classify and sequence the topic and the overview so they can assemble the appropriate talent and resources to measure, infer, predict and communicate the solutions.
They will likely be unable to help if you approach them with thoughts that are not logically sequenced, have an unclear problem statement, and/or don’t demonstrate an understanding of the symptoms. In fact, they are imagining the necessity to arrange the data in a meaningful way, which they might be justified in considering to be your role. It amounts to upward delegation. The most effective means of communicating to your leadership when asking for help is to have the these three statements ready:
- This is the problem.
- This is what I’ve attempted to do about it.
- This is, specifically, what I am asking of you.
With those three statements, any good leader will know how to get started.
The same holds true if you are approaching a peer or cross-functional team member for help. If you haven’t prepared the request in the template of 1 through 3, above, then you appear to just be handing the whole problem over to them to be solved. By handing the whole problem over to someone else, it could come across as “here, this is your mess to solve” and be received as an accusation instead of a request for help. Of course, this usually results in a defensive fortification of silos, erosion of transparent communication and a pile of “evidence” that it is not their fault. A peer or team member are usually willing, and often anxious, to help. A concise, logical and well thought-out introduction to the issue can help them see “the why” and they can see how they fit into “the what”.
Using the three step approach shows that you understand the problem. It shows that you have observed and classified but are simply stuck at a specific point that you believe they can assist get you past. Another benefit is that defining what the problem is, what you’ve done about it and what you are asking of them, is that it is suggestive of a strategy to achieve resolution. The team member will understand what you really want to accomplish with your request for help.
I’ve had issues escalated to me as a request for help where the minutiae related to and not related to the problem was all presented to me in raw data form. It felt like the equivalent of dumping 999 pieces from a 1000 piece puzzle on my desk and asking me to figure it out. So, I set out to boil it down to the simplest terms. You have to understand the objective and then work from the first step to the last for what is required to achieve the objective. Once we had the steps understand and arranged them into a critical path, we had to consider where we were in the process and what was missing. We used only a very small percentage of the “information” that he brought to me for consideration. It’s easier to embellish the critical path with the decoration of additional details as they become relevant than it is to attempt to understand every single piece of information available whether it is relevant or not. Boil it down to the basics and add as required for problem solving. We developed a credible plan and a logical strategy in a fraction of the time it took to admire the entire data set of anything that has to do with everything.
If you believe in the generalization of problem solving into the following 7 sequential steps (also stated above):
- Observe
- Classify
- Sequence
- Measure
- Infer
- Predict
- Communicate
then you can start to appreciate that this article is about a), b) and maybe c).
Once you understand the problem and what you are asking for, the real problem solving starts. Tools like Kepner-Tregoe methodology (my personal favorite), 8D, fishbone diagrams, and Shanin Red-X are examples of tools you use once you’ve set the stage for what you are really trying to accomplish and defined how other resources on your team can help. This article was intended to focus on eliminating the “ready, FIRE!, aim” approach to asking for help. I believe following this advice will increase your worth to your company and increase your effectiveness in securing assistance. Don’t be afraid to do a little work getting organized before you ask for help.
RSS Feed
