Written by: Amy Leschke-Kahle, VP of Performance Acceleration at Marcus Buckingham Company, an ADP company…
The Myth of Goals: An Honest Observation of What We All Wish Was True
Amy Leschke-Kahle, VP of Performance Acceleration at The Marcus Buckingham Company, discusses the myth of goals.
Have you ever asked yourself why the goals we set last year somehow became virtually irrelevant by about March? Aren’t goals supposed to be impermeable in helping us align, get the right work done, and create a means for measuring performance? Wouldn’t it be great if goals made all those things happen?
It’s not that goals in and of themselves are bad; it’s just that we use them badly.
Here are a few things to consider that will reveal how your organization is thinking about goals – and if they are truly achieving what you set out for them to do.
Myth #1: SMART goals are smart
While SMART (Specific Measurable Achievable Realistic Timely) goals were designed to standardize the goal development process, most SMART goals are actually not so smart. Do you have a valid, countable metric that determines success or did you make up a metric so you could check your “M” box? Are you confident that the work can be done in the specified time frame so you have a “T” or did you just guess? SMART often forces us to smoosh our work into a confining framework that often doesn’t fit the actual work to be done. Sure, sometimes our work is SMART-worthy in which case we should absolutely use SMART. But let’s not make everyone force fit their big chunks of work into a model that only works some of the time.
Myth #2: Everyone should have goals
If something is good for someone – it should be good for everyone, right? If only humans were that simple. Most people perform cycle work. Even highly skilled knowledge workers such as nurses, mechanics, and software engineers often do the same type of work every day. The context may change, but the work itself is doesn’t really vary most of the time. So, goals really may not serve them. Why then should people whose work doesn’t merit unique projects be forced to make goals?
Myth #3: Measuring goals indicates employee performance
The reason many organizations require employees to have goals is because they don’t consider what else they could measure. At least goals give us something. But how much of your employee’s time at work is spent working on the work outlined in “goals”? And does having more goals really mean more productivity? It’s rare an employee’s entire job is spent working on super specific, well planned out work. We have three big chunks of our jobs:
- Job responsibilities – when was the last time you looked at your job description?
- Projects – the real “job responsibilities,” which we try to use goals to capture
- “Other duties as assigned” – the catch all for everything left off the original description to cover everything else that comes up
Track your time for a week and see how much time you spend on your “goals.” I bet it’s not much, if at all. You are no different than your employees.
That leaves us in a pickle. In an ideal form, goals are a great way of setting an objective and keeping score. If we don’t mandate that everyone has goals, what do we do? Start by thinking about goals this way:
- If someone has SMART goal worthy work, then by all means create a SMART goal. But be wary of mandating that everyone has SMART goals, especially if the model starts to behave less smartly when applied.
- Don’t make goals mandatory if goals don’t apply to the role. If employees have truly countable work, then count. Don’t make up something to do the job of counting that is not needed.
- Work isn’t always super specific and perfectly mapped out. Things come up. Projects change. Fires need putting out. If you want to be real about the real world of work, measuring employee performance isn’t a job for goals.
All that talk of goals and we still haven’t dug into how to create alignment, get the right work done nor measure performance. Never fear, in my next post I’ll tell you what to do instead of goals. Stay tuned!
This article was originally published on ADP SPARK.