Good Goals

This piece also appears in the book Scaling People by Claire Hughes Johnson.

Having led goal-setting processes with teams of 1 to 500 people, at all stages of product maturity, I find I get more or less the same questions, and the same pushback, every time. This is my answer to those questions. While you can easily find lots of tactical advice online about goal-setting processes, here I want to focus on the spirit of what we’re actually trying to achieve and how to know if we’ve done it well. To that end, this post covers: (1) why set goals, (2) what good goals look like, (3) heuristics for testing your goals, (4) FAQ.

Why we set goals

These are the goals of the goals, if you will…

Define success. Goals are statements about successful end states: what are you trying to do, and how would you know if you did it? Plans are sets of activities. Executing on a plan may help you achieve a goal, but it’s not itself the goal. To maximize your odds of achieving a successful outcome, start with the end in mind and work back to the activities most likely to get you there.

Focus. There are always far more reasonable things we could be doing than we have capacity for. Productive teams clearly distinguish the most important things from all the other good ideas, and they relentlessly focus on those top priorities. This also helps ensure all the different parts of the team are operating in concert, rather than independently working on related things.

Allow for autonomy. Aligning around and committing to a shared definition of success creates accountability. Doing it without mandating specific activities allows that accountability to coexist with autonomy and creativity.

What good goals look like

Remember: F.O.C.U.S!

Focused, concise, and comprehensible

• Everyone on the team should be able to easily memorize the team’s goals. This is important, since the progress you make in a quarter or a year is the result of thousands of independent decisions. Too many goals, or too many details, interferes with this. People can remember about 3–5 things.
• Focus on the most important things. Your goals should help you identify and avoid the distractions.
• Use plain English, easily understandable to anyone with a passing familiarity with your team’s strategy. This helps with strategic clarity, memorability, and communicability. Jargon often masks strategic gaps.

Objectively assessable

• Everyone on the team should have the same understanding of what success looks like and what it doesn’t. Goals don’t need to be quantitative, but they cannot be subjective.

Challenging but possible

• Your goals needs to be credible. If people consider the outcome unimaginable, they’ll simply ignore it and give up.
• Your goals should also stretch the team, inspiring and challenging people. If you ask your team to stretch, you’ll often discover it finds ways to deliver more than you expect.
• A good rule of thumb is to shoot for about a 70% success rate. (However, some goals may be considered a stretch, and some may be considered a must hit—be explicit if so.)

User oriented

• Never organize team goals by function (Engineering, etc.). Success depends on all team functions coming together to deliver great products, and a single set of goals helps force alignment of efforts. Even if some goals presumably depend more on one function than another, allow for the team to flexibly organize its capabilities and solve problems creatively.
• Don’t organize goals around features you’re delivering. Thinking about your expected activities and working forwards is likely to leave gaps.
• Instead, focus on the customer problem you’re solving, and set your goals as close to the customer as possible

States not activities

• If you detail specific activities to pursue, you’re removing the opportunity for teams to solve problems autonomously, creatively, and iteratively. Instead, focus on the outcome you want. How would you describe the state of the world in a success case?
• Define these outcomes as precisely as possible. Sensitivity: your goals should allow for the outcomes that you would consider success. Specificity: your goals should rule out unsuccessful outcomes.

Testing your goals against these guidelines

Some heuristics you can use to assess your goals

1. Does your goal start with a verb (launch, build, refactor, etc.)? You probably have an action, so reframe it to describe the outcome you want. Often this takes the form of translating “X so that Y” into “Y via X” (and consider if you need X in there at all). A helpful trick to figuring out the proper framing is to read the goal out, ask yourself “why?,” answer that question, and then do that a couple of times until the true goal comes into focus. For example:
   • Refactor backend → Backend supports 5+ teams concurrently adding features
   • Launch v2 product → Double conversion rate via new payment integrations
   • Add infinite scrolling to search→ X% of search queries receive result clicks
2. Do you have “engineering goals” and “business goals” or similar? STOP IT.
3. Are your goals more than one page, more than 3–5 objectives, or more than 3–5 KRs per objective? No one will read, let alone remember, them.
4. When you (or your team) look at your goals, do you wince and think “what about X? I was really hoping to get to that this quarter.” If not, you probably haven’t focused enough, and your goals are not adding value.
5. Could one team member think a goal is achieved and another one completely disagree? Then your goal isn’t specific enough. (By contrast, if everyone feels it’s mostly successful but the assessments range from 60% to 80% done, who cares?) Look for wishy washy qualifiers like “better” or “delightful”—How much better? How do we know if it’s easy or not?
6. Can you imagine a scenario where the goal is achieved but you’re still dissatisfied with where you ended up? Then your goal isn’t specific enough, or an aspect is missing.
7. Could you be successful without achieving the goal? Then your goal is overly specific, and you should rethink how to define success.

FAQ

Where do the goals come from?

The goals represent the progress we want to make on our strategy in a specific period of time. You have a strategy, right? If you aren’t clear about where you’re going, you can’t set meaningful milestones on the way there.

What process do you use to set the goals?

There are no doubt lots of reasonable ways to set goals, but here’s how I generally go about it. I find that the process always takes exactly as long as you allow it to, so timeboxing is critical. If you actually know what your strategy is, it’s usually quite straightforward, and never really needs to take more than two weeks of calendar time.

1. Think about what you consider the most important things to accomplish in the time period. If you know what your strategy is, this should be straightforward (less than an hour).
2. Ruthlessly limit this list to the top 1–5 priorities
3. Talk about this list with your team, as a casual conversation of priorities. Know what you think, but be open to alternatives. Ask them if they have other ideas. Give them a few days to talk with other people outside the room. Gather the results back into a shared list of priorities.
4. Phrase your priorities as descriptions of the state of the world at the end of the time period
5. Simplify by removing any redundancy, unnecessary phrases, jargon, etc.
6. Ask yourself if you could actually be happy even if these statements didn’t come true, or if you could actually be unhappy even if these statements came true. Iterate until false.
7. Assign each item named owners. Ensure explicit commitment from the owners that it’s the right goal and they plan to deliver on it. If you sense hesitancy, talk in person to resolve it.

What tools do you use for capturing & tracking goals?

A one-page document. If you need more than a simple document, you’re doing it wrong. Perhaps you’re engaged in work planning rather than goal setting.

What if your team is too big to have such a concise set of goals?

It isn’t. A five person team and a 100,000 person company can each communicate their top priority goals on a single page. However, once your team grows over 30 or 50 people you may have sub-teams that reasonably need their own more detailed goals. In this case you’d still have goals for the whole organization, and each sub-team would have their own lower-level goals as well.

How do you manage against the goals?

If you set good goals, and have real buy-in, then the whole team should have a set of shared goals you can use as a foundation. As you talk about team performance, meetings, sprint planning, challenges, progress, frame those conversations against the goals you set. Organize your activities around the goals, talk about them constantly, frame the day-to-day in terms of how they will help achieve your goals. Keep them top of mind for everyone, all the time.

How do you score goals?

I usually do a lightweight mid-quarter and end-quarter review with green/yellow/red color coded scoring (representing success/mixed/failure). The mid-quarter review is a helpful checkpoint to refocus everyone on the goals where we may have gotten distracted. The end-quarter review is mostly to help us recalibrate how aggressive we were and highlight areas we are regularly failing to make progress at. If the reviews require a lot of effort or feel like they need to be done more often, then your team probably hasn’t fully internalized the goals and isn’t using them to guide day-to-day activities.

What do you do if the goal changes before the time period ends?

Sometimes strategies change, or we learn things that change our priorities. That’s fine. Start working on the new goal immediately. Take a zero with an asterisk or whatever when you go to score the old one. Who cares? If this happens to you all the time, you may be setting too specific goals, or incorporating activity planning into the goal setting process.

How aggressive should the goals be?

This is more of a cultural thing. Some teams like being very aggressive and don’t get discouraged if they only achieve half their goals. Other teams feel they should be getting around 80% of the way there. I like the rule of thumb that you should get about 70% of the way there, and if you’re hitting all your goals, you’re probably not being aggressive enough. But I don’t think it really matters that much… the important thing is to ensure the right work happens, with the right focus and a shared definition of success.

What about quantifiable measurability?

Goals generally benefit from using clearly defined, measurable metrics. For example, “median latency is under 200ms” is obviously a much better definition of success than “latency is reduced.”

However, sometimes people get hung up on enforcing quantifiability and can lose track of what really matters. It’s fine for some goals to have no numbers, as long as it’s clear what success looks like, not a subjective question. A goal like “MVP is up and running on production hardware and multiple external companies have tested it and provided early feedback” has no numbers, but it’s very concrete. The important thing is that the whole team assesses success and failure the same way. As Andy Grove said about goal assessment, the important thing is that “at the end, you can look without any argument and say ‘Did I do that, or did I not do that?’ Yes. No. Simple.”

What if I can’t measure the thing I want to optimize?

Generally I say use the metric in your goal anyway and try to assess it by proxy. Better than setting the wrong goal entirely. “Far better an approximate answer to the right question, which is often vague, than an exact answer to the wrong question, which can always be made precise.” -John Tukey. Plus, nothing motivates development of the right metric like using them to actually measure success across the team!

What if I have a metric, but I don’t know what the right target is?

Quite often you’ll agree on what a good way to measure success is, but you won’t know exactly what a reasonable target is since you don’t yet have a baseline. Generally I say who cares? Take a guess at a reasonable number, be honest that it’s a stab in the dark, work towards it, and update your target along the way as you learn more. Better to set the goal in the right direction and not be sure quite how far you should get than to risk going in the wrong direction entirely.

What if you can’t agree on what the goals should be?

There are any number of reasons this could be the case. Let’s assume you’re dealing with a reasonable set of people working together in good faith and trying to do what’s best for the team (if you aren’t, it’s not a goal-setting problem). The first step is to stop arguing and try to diagnose why you’re stuck. If you can figure that out, you can almost always find a good resolution.

Here are some common issues people get hung up on. Work from the top down until you find the place you fall out of alignment, and work through that question while holding everything else to the side. Then continue down one step at a time.

1. Different assumptions about vision or strategy. If we aren’t aligned on what we’re trying to do as a team, there’s no effective way to figure out the milestones along the way.
2. Different assumptions about priorities. Similarly, if you think that we should do A first, then B, and I think we should do B first, then A, we can’t align around goals.
3. Different interpretations. Tease this out by talking through concrete scenarios and seeing if you agree on what success is and what it isn’t.
4. Incomplete success statements. If your goals don’t capture something important for success, you may see people trying to pull things up a level into very broad statements. Try adding additional, very specific statements to narrow down the range of good outcomes until you’re on the same page, then simplify as appropriate.
5. Different assumptions about feasibility. If someone feels the goal is fundamentally not possible, or cost-prohibitive, it’s good to name this explicitly and dig into it.
6. Different assumptions about capacity. Try expanding the timeframe a bit and see if you all agree on the overall plan, and are simply disagreeing on how far we should get in a specific time period.

Why “goals” and not “OKRs”?

OKRs are just goals with a particular structure, separating the thing we’re trying to do (the objective) from the concrete definition of success (the key results). I like that structural distinction, since I find it helps ensure we define success clearly, so I tend to use the OKR framework myself. As Andy Grove (who invented OKRs) framed it in High Output Management, OKRs separates out two key questions:

1. Where do I want to go? This answer provides the objective.
2. How will I pace myself to see if I am getting there? This answer provides the milestones, or key results.

However, lots of people have PTSD with OKRs, since you can use the same structure and break all of the rules discussed here. Many OKR processes devolve into detailed activity planning. My concern isn’t with the framework, it’s with defining good goals. So I just use the term “goals” in this document, since most people agree that goal setting is worth it (but not everyone!).