Employee Recognition Series, Part 1: What NOT to do!
My group was “at the tail end of the whip” – the project team would determine the direction (in closed meetings) and define specific tests which my group would have to carry out. We were left entirely out of the loop on the rationale and planning for such tests, constantly receiving last-minute demands for test set-ups with no context and no idea how (or even if) the results would help advance the project toward its goals.
One time I was informed by the project leader that a particular test I had set up and monitored weeks prior had yielded critically important data. He wanted to recognize my effort and inquired about my preferences (i.e., gift certificate, desktop accessories, etc.). I thanked him for the “attaboy” and told him that what I really wanted was to occasionally be invited to the project team meetings (to understand how my team’s work was contributing, and to get a bit more notice when important tests were coming up).
A few weeks later I received a small digital clock emblazoned with the company logo and “Great Job Award”. I was never invited to a single project meeting. Even though it stopped working long ago, that clock still sits on my desk nearly 30 years later as a reminder of how NOT to recognize and reward employees.
All I wanted was to be in the loop so that I could contribute more effectively to the project goals. Instead of providing timely and appropriate recognition (which would have cost nothing and would only have improved my ability to deliver results) the recognition was late and irrelevant, utterly undermining its purpose.
This post is the first in a series focused on rewards and recognition - keep an eye out for future posts full of tips on how to do recognition right.
Want some advice on your employee recognition program? E-mail us anytime at info@CaedenceConsulting.com.
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.
