In Praise of the “Stretch” Goal
Return in a week with 20 ideas to solve the problem - twenty! I panicked – Was he crazy? I’d never come up with more than 3 ideas to attack any previous problem; where would I get 20?
Establishing “stretch” goals is one component of setting high overall expectations. Such goals have to be balanced just on the verge of achievability, and there must be a culture of trust in place – there must not be negative consequences for failing to reach a stretch goal.
As a rookie design engineer, at least once per week I would be in my manager’s office discussing the details of my assignments. This one particularly thorny design problem had me vexed. After a bit of informal discussion and brainstorming, my manager asked me to return in a week with 20 ideas to solve the problem - twenty! I panicked – I’d never come up with more than 3 ideas to attack any previous problem; where would I get 20?
A week later, I was back in the office with 12 ideas to discuss. I never quite reached the requested 20, but the ambitious goal drove me to generate at least 9 more ideas than I would have otherwise conceived. When my manager asked for 20, I attempted it, trusting that coming up a bit short would not be cause for chastisement. That said, had my manager asked for 1000 ideas, I would probably have ignored the comment as hyperbole and returned with my usual 2 or 3.
Most people love a challenge. However, they won’t take up the challenge if they think they’ll be punished for failing. Further, they will quickly shut down if the challenge seems too overwhelming. Setting effective stretch goals for your team requires that they (a) agree the goal is difficult but might be achievable, and (b) understand that falling short will not incur any negative repercussions. Work with your team to establish such goals – their buy-in is key.
Over the years we’ve been exposed to Six Sigma, Juran, Deming PDCA, 8D, Dale Carnegie, A3, Shainin, and more. Each technique works pretty well, and has been demonstrated many times in a wide variety of industries and circumstances. At the core they are all essentially the same!
Each approach relies on an underlying logical flow that goes like this: [a] make sure the problem is clearly defined; [b] be open to all sources of information; [c] vet the information for relevance and accuracy; [d] use the process of elimination to narrow down all possible causes to the most likely few; [e] prove which of the suspects is really the cause of the issue; [f] generate a number of potential solutions; [g] evaluate the effectiveness, feasibility and risk of the potential solutions; [h] implement the winning solution(s); and [i] take steps to make sure your solution(s) don’t unravel in the future.
The differences between the paradigms resides in supplementary steps and toolkits. For example, 8D contains the important “In
Your primary role as a manager is to ensure your team’s success. Internalize this. Make sure your team members know this. Build an environment of trust and collaboration. A direct report of mine would frequently leave me out of the loop as problems escalated, preferring instead to “work harder”. It was clear that he felt uncomfortable delivering bad news to me (his boss) when things were not going according to plan. Let me tell you the rest of the story.
