SMART Goals…Aren’t
I love goal-setting, and I’ve always found it valuable. I’ve used it personally to help me focus and grow, and as a manager, it is always part of team process.
I’m often skeptical, however, of “best practices” when setting goals. Time after time, in an attempt to guide the process, I am asked to use the SMART framework. These goals are Specific, Measurable, Achievable, Relevant and Time-Bound, but they are not always useful.
I struggle to use the SMART framework to drive important outcomes, and I am often frustrated with the goals my team members end up with. Some goals depend on the roadmap and are out of their hands (“Lead a major project to successful delivery”), some goals are basically just their job (“Complete 4 bug fixes each month”), and some goals feel like extra-curriculars on their college application (“Read 8 blog posts about TypeScript this month”).
Instead of SMART goals, goals should chart a direct path to where engineers want to go. Goals should be useful, which means they result in actions that wouldn’t have taken place otherwise. Good goals should never sacrifice accuracy for measurability or time-constraints. Instead, let’s get back to the basics, by trying to help engineers answer the question:
“What can I do that will help the company, and also help me grow, that I wouldn’t do if I hadn’t set it as a goal?”
What do goals accomplish?
First, goals should help engineers change their behavior. This may not be easy — engineers can get far by doing the work that is handed to them. Students who do well on their assigned schoolwork go on to get high-paying jobs in software. Junior engineers focus primarily on completing tasks as they learn to operate in a real job.
Effective goals should clearly state an outcome and list behaviors that are different than if the goals weren’t set. This means, to some degree, they need to be “off the roadmap” in order to be useful. Goal-setting needs to start with a baseline for what the week would be like without this goal-setting exercise entirely. Engineers need to ask themselves, “What am I trying to accomplish that I wouldn’t accomplish otherwise?”
Second, individual goals should align with company goals, and should not conflict with the team’s main priorities. We can hold engineers to a high standard of execution on their main work, while still giving them ways to level up. We want engineers to ask the question, “What can I do that will complement my work and help me grow without distracting me?”
Lastly, goals should be a shortcut to growth. Many engineers succeed without setting goals, so it is disingenuous to say that goals are necessary for growth. Instead, I want to know how you can reach the “next level” in two years instead of three. What sort of small “growth hacks” will make you extra successful?
Caveat: Goals shouldn’t be explicit targets for compensation or promotion
Measuring software output is hard, and goals that align directly with engineering work can usually be gamed. It is generally unadvisable to tie goals directly to compensation and title (i.e. “if you complete these 4 SMART goals, you will get a promotion to senior engineer”). If we try to maximize Velocity Points, minimize Bugs or accomplish a fixed Number of Tickets, our goals become counterproductive. I am operating on the assumption that goals are vehicles for growth and not core job metrics.
SMART…isn’t
Let’s work through some problems with parts of the SMART framework, as we aim for goals that change behavior and drive growth.
Measurable
I often find myself trying to shoehorn a relevant goal into a quantifiable metric. After an engineer clearly articulates what they want to accomplish, we try to retrofit a number to match. We end up corrupting a list of useful actions with arbitrary numbers.
For example, perhaps a newly-hired senior engineer wants to become more comfortable in the codebase quickly (a clear, useful goal). Should they ride along on 2 code reviews a week and spend 30 minutes each morning reading documentation? What if they do 1 code review, have a pairing session with another engineer, and solve a challenging bug fix? Have they failed?
Furthermore, if we agree that we aren’t using goals as strict requirements for promotions or compensation, do we really need a result that is continuous, or even discrete? If goals are for the benefit of engineers, shouldn’t we be comfortable asking them, “Do you feel that you have accomplished your goal?”
Achievable
We want to set a high bar, so that we level up faster than we normally would. Instead of focusing on whether or not we can definitively achieve a goal, we should focus on how setting the goal changes our behavior. Achieving 20% of an “impossible” goal may be a huge success, and represent a small first step toward long-term growth. Since we’re not tying goals to core job metrics, let’s focus on making goals directional and useful, and leave the scorekeeping aside.
Time-bound
Since goals are “off the roadmap,” and since we never want goals to conflict with team priorities, we should never assume we’ll have time to work on our goals in a given week. Software is full of surprises, so goals should help us move in the right direction over time, rather than dictate our actions day-by-day.
Additionally, tomes have been written about the complexities of estimating software projects. We can’t reliably predict whether a project will finish in 3 months, so how on earth are we supposed to predict when we will complete challenging goals that tie deeply to our core abilities?
To be fair, it is discouraging and counterproductive when a goal has no urgency, sitting on the “goals list” for weeks or months. However, this is a function of how goals are used on the team and not a function of the goals themselves. If goals are reviewed, re-upped and pruned regularly, we get the freedom to choose more flexible and useful goals that don’t fit neatly into a time-estimated box.
Instead, keep a monthly accounting by simply asking each engineer, “Which of these goals are you still focusing on?” and “Which of these goals are complete or no longer relevant?”
Specific / Relevant
Some parts of SMART may actually be “smart,” — we’ll keep these two.
So what should good goals look like?
If we’re not using a snappy acronym to guide goal-setting, what should we do instead? I say we use a new acronym!
Specific
A goal should lay out a specific desired outcome, whether it is measurable or not. When you review the goal each month, you should be able to help your team member answer the question, “Do I feel like I have achieved this goal, am I still working on it, or is it no longer important to me?”
Off-the-roadmap
A goal should supplement core job functions, and should give engineers a chance to go “above and beyond” in an impactful way.
Actionable
A goal should include a list of concrete activities that an engineer can do on a weekly basis that further that goal.
Relevant
The goal should be the most important thing that the engineer wants to improve on, and shouldn’t conflict with team priorities.
Using these guidelines, we can create useful and actionable goals to help engineers *ahem* SOAR!
A final caveat: We’re talking about goals for individuals, not OKRs
Most individual goal-setting tenets are antithetical to good team-wide OKRs. OKRs connect many people, and incentivize them. Concrete metrics are a great way to align people across many job functions. Aggressive, time-bound goals help inform strategy. Meanwhile, individual goals are about growth and initiative, and don’t derive the same benefit from being measurable or time-bound.
Thanks for reading! Stay tuned for Part II, where I will go into specifics on how to develop SOAR goals (goals that SOAR? SOARt of good goals?), and walk through some examples.
