I’ve had some form of regular goal-setting at most of my jobs, and it’s always been a pretty lackluster process. The purpose of setting a goal was unclear, I wasn’t sure what a “good goal” was or how to figure that out, and sometimes I was required to make it relevant to the company’s goals which didn’t always connect to what I wanted.

Now that I’m a manager, I don’t want to pass that same lackluster experience down to the folks on my team. Like many companies, we expect our people to create quarterly goals and quarterly accomplishments, but we hadn’t done a great job of explaining what we were looking for in those documents. So I gave a presentation to help folks understand how to write better goals and accomplishments, and to help managers coach their teams on those things! This is the article I wish I’d been able to read when I had to create goals, and it’s the article I needed to write as a manager to help me clarify goals and expectations for my team.

Goals or OKRs?

Let’s get this out of the way first so we can focus on the good stuff 😄

“Goal” and “OKR” are often used interchangeably, and the general idea is similar. But OKRs are top-down objectives, where the company objectives inform department objectives, which then inform team objectives.

Individual goals are about an individual person’s growth and impact, and shouldn’t have to adhere to that top-down structure. Because of this, “objectives” are for the OKR framework and “goals” are used at the individual level to differentiate the purpose and make expectations a little clearer.

Okay, on to the good stuff!

Defining Your Goals

So… what is a goal, anyway?

A goal is your high-level desired impact or outcome - the thing you want to accomplish. This isn’t an exhaustive list, but goals can relate to overall professional growth, career development within the current company, career development within your industry, improving technical or leadership skills, team initiatives, and department initiatives* (with caveats - more on that in a minute).

One of the most important things to remember about goals is that YOU drive your own goals. In a RACI chart, managers would be Consulted and you would be Accountable. Your manager can ask guiding questions, help you figure out what your goals might be, offer feedback using the SMART approach, and check in with you to see how you’re progressing. But your goals are YOUR goals, and you’re accountable for defining them, tracking progress and blockers, and ultimately meeting your goals.

This is not to say that you’ve failed if you don’t meet your goals. Like my grandpappy says, experience is what you get when you didn’t get what you wanted! So if you end up missing a goal, learn from that experience and use the lessons for next time.

*The caveat for department-level goals: if someone’s personal goal is tackling work at the department level, there needs to be some additional scrutiny and due diligence ahead of time. Some things to think about:

• Is it really a department priority?
• If not, why not? Maybe it’s already been considered and rejected, or it’s dependent on other things to be completed first.
• If it is a current priority, is it already being worked on? You want to be aware of overlap, unnecessary rework, or impinging on someone else’s territory.
• Does it require a level of effort, buy-in, social capital, or specialized knowledge that is beyond your current ability to accomplish?

Writing Structure

My preferred format for writing goals has three main sections: Goal, Key Results, and Risks. We defined Goals in the previous section, so let’s take a look at Key Results and Risks.

Key Results are the measurable steps that enable you to reach your goals. This is where the SMART approach comes in! SMART is an acronym that helps you create clearer, more defined Key Results:

• Specific: Get into the details to add clarity and understanding
• Measurable: Quantify the work as much as possible
• Achievable: It’s great to challenge yourself, but we also want you to succeed!
• Relevant: Make sure your key results relate to each high-level goal
• Time-bound: We often work with quarterly goals - keep that timeframe in mind

I love a good example, so let’s take a look at the typical kind of goal and figure out how to define the Key Results!

Goal: Increase automation coverage for $PRODUCT-API.

As a desired high-level outcome, this is good! So in order to set the Key Results for this goal, you should ask yourself what you need to do in order to accomplish that?

• Goal: Increase automation coverage for $PRODUCT-API
  • Key Result: Write automated tests

Okay, that’s technically correct but it doesn’t fit into our SMART approach - it’s definitely relevant, but it’s not specific enough, it’s not measurable, and there’s no real indicator whether it’s achievable. So let’s try again!

• Goal: Increase automation coverage for $PRODUCT-API
  • Key Result: Write automated tests for one endpoint every two weeks

Aha! That’s much better - specific, measurable, achievable, relevant, timebound. But there’s rarely only one step to achieving a goal, so now you should think “what else?”. At The Zebra, we write test cases, so that’s definitely part of adding test automation. So let’s add that in:

• Goal: Increase automation coverage for $PRODUCT-API
  • Key Result: Create test cases for $PRODUCT-API automation
  • Key Result: Write automated tests for one endpoint every two weeks

And then I like to ask the question again - what else? Well, a test plan would probably be pretty helpful so you can track all of the endpoints you need to test and various scenarios that you’re validating. So let’s update one more time:

• Goal: Increase automation coverage for $PRODUCT-API
  • Key Result: Create a test plan for $PRODUCT-API
  • Key Result: Create test cases for $PRODUCT-API automation
  • Key Result: Write automated tests for one endpoint every two weeks

Could this get even more specific? Probably. But at some point there’s a trade-off of granularity where the documentation feels onerous compared to actually doing the work. The point of this process is to serve the people doing it - helping you think deeper about what you want to accomplish and what it will take to do so; and helping managers understand their teams’ goals, offer coaching as needed, and see how the work is progressing.

Thinking About Risk

I really like using goals to help people cultivate a risk-aware mindset. Knowing what you want to achieve is great! But effective planning also includes understanding the potential risks, so you can factor that into your plan.

Risks can be internal (things that you have control over) or external (things that someone else controls in some way). When you first start thinking about risk, you’ll probably be much better at anticipating internal risk. You know your energy levels, your motivations, your personal responsibilities, your availability and so on. You’re used to working with internal risk even if you don’t explicitly think about it that way, so those risks are much easier to predict.

External risk can be things like changing product priorities, major incidents in production, or a family member getting sick and needing your care. It’s also important to remember that not all risk can be predicted. Part of working toward a goal is understanding that risks can appear along the way, and being able to adjust your plan to account for those unknown unknowns. Looking at our example goal around automation testing, some external risks might be:

• Poor documentation of $PRODUCT-API, which means additional work figuring out what needs to be tested
• Code freeze due to a version upgrade for an engineering-wide tool, which prevents new automation from getting merged in
• Major feature change that requires updating existing test automation, which requires more time and effort that would have been spent on goal progress
• Family member diagnosed with Long Covid, which means they need extra care and the employee has more stress to deal with and less bandwidth to handle it
• Employee breaks their arm playing softball, which means their productivity is slowed way down and might mean they’re on short-term disability leave

You may be wondering about the personal risks, and whether they “count” for professional goals. I absolutely think they do. Employees are people, with personal lives that impact their professional work.

Some of these risks are just absolutely not knowable in advance - and that’s okay! The useful thing here is how learning how to handle with the risk once it comes up. Some of these external risks, like the lack of documentation, could have been planned for. This is how goal progression can be a learning experience - the person may not have thought about the state of documentation this time, but you can bet it’ll be part of the prep for setting goals next time!

Conclusion

You might be saying to yourself, This seems like a lot of work for just writing out some goals that my company requires. Well, maybe. But here’s the thing - the approach here isn’t just about quarterly goals. It’s about outcomes. And as you continue to advance in your career, being able to effectively plan for outcomes is an increasing part of the job.

The structure and approach here is teaching you how to set a desired outcome, and how to break that down into meaningful, incremental tasks. It’s teaching you to think about dependencies. It’s teaching you to think about risk - how to plan for known unknowns and how to adapt to unknown unknowns. So while setting goals may be the framework for learning those skills, you’ll use them well beyond that scope - writing test plans and technical design docs; project planning and backlog refinement; leading large-scale initiatives; setting your sights on a promotion.

What’s your desired outcome, and how will you get there? I hope this guide helps you think about, write, and set better goals for yourself! And if you’re interested in related content, I created a slide deck on Goals and Accomplishments for my department at work!