Why do engineering companies set goals? Because they create focus and allow us to make sure we’re not tackling too many problems at once. They provide opportunities for innovation and creative thinking. And they introduce a powerful source of intrinsic motivation.

Many engineering teams manage their goals using the Objectives and Key Results (OKRs) framework. First, teams define a few objectives (the things they want to achieve and the value they want to deliver to users). For each objective, they also define a couple of key results (metrics or milestones that measure their progress towards the objective).

When OKRs are well set, the work feels natural and teams move organically towards achieving their goals. But I learned the hard way that getting OKRs right can be a challenge. Here I’m going to walk you through my team’s journey with OKRs and outline the five key mistakes that we made, in the hope that you can learn from our experiences.

1. Somebody from outside the team set the OKRs

Our first mistake was letting somebody who wasn’t doing the actual work set the goals for the team. OKRs should encourage team autonomy and create a sense of ownership. If the engineers had set their own goals, they’d have truly believed that achieving them would lead to success for the team. But because they were set by someone else, there was a lack of intrinsic motivation.

In my team’s case, we set ourselves up for failure the moment our OKRs were set, long before we started doing the actual work. This is because we allowed our product owner to set unrealistic objectives without pushing back. We should have explained why the goals weren’t achievable but we were avoiding a difficult conversation and it was easier to simply agree. We also lacked the experience to be able to estimate how long it would take to achieve the proposed goals.

It’s important to note that product owners should play a critical role when setting the team’s OKRs. In an ideal world, they should present what the business needs and give priority to different goals so that the team can pick the most impactful ones. Before starting the actual work, the team should also think of some potential ways they could theoretically achieve the goals and provide rough estimations to make sure the plan is feasible.

When folks own their goals, they care about them. They feel inspired and motivated. Goals set from the outside have the exact opposite effect. They decrease morale and create a feeling of dictatorship, playing against the team's autonomy. So this was our first learning: empower the people who do the actual work to set the goals for themselves.

2. Framing the key results as a to-do list

Another mistake we made was formatting our key results as a to-do list. We framed them as a set of actions describing how we would achieve our objectives, when we should have been identifying ways we would measure our progress.

Inevitably, halfway through the quarter, we found a better solution that would allow us to achieve our objective – a smarter way to get there without having to do the work described in the key results. Again, we’d failed our key results the moment we set them: instead of having them measure the progress towards the objective, they were describing a particular way of getting there.

The lesson here is: don’t describe a particular solution; let the team innovate around the solution. An objective should be inspirational and encourage the team to be creative, innovative, and look for the easiest path to achieve it. Prior to starting work on an objective, try running a discovery phase where the team can generate ideas for impactful things they could do. But remember, these ‘how-to’ ideas should be kept separate from your key results.

3. Creating binary key results

Our third mistake was creating binary key results. These are KRs that you either achieve or you don’t. It’s a matter of ‘yes or no’, rather than measuring the specific progress towards the objective.

For example, one of our KRs was something like, ‘Switch to our new component library, based on the design system’. At one point during the quarter, we realized we didn't have time to finish the migration, meaning we’d completely failed the key result. It would’ve been wiser to formulate it so that if it wasn’t entirely achieved, it wouldn’t lead to a complete fail. For example, we should’ve said, ‘100% of the frontend components are migrated to the new component library’.

The learning here? The way key results are formulated matters.

4. Setting objectives that depend on each other

Now onto our fourth mistake. We set objectives that depended on each other. For example, in order to achieve objective two, we needed to achieve objective one first. At a certain point during the quarter, we realized we wouldn't be able to deliver on objective one. And because the next objective depended on it, we weren’t able to start working on that either.

We soon realized that objectives should be independent. You should be able to achieve any of the defined objectives and key results without first having to achieve the previous ones.

It’s important to remember that OKRs provide a framework for goal setting, not a tool for planning. When creating a plan, the different parts have to depend on each other. It’s not the same when setting goals.

The learning here was two-fold: objectives should be independent, and goal setting shouldn’t replace planning!

5. Setting an ambitious number of OKRs

Last but not least, our final mistake. At this stage, we’d been through several OKRs cycles. Because we’d failed the objectives for the previous quarter, the pressure had started to build from our stakeholders (this is common when a team doesn’t deliver on what they promise). In order to make our stakeholders happy, we didn’t just promise to deliver objective one, which we weren’t able to deliver in the previous quarter. We also added objectives two and three.

After two sprints, we realized we wouldn’t be able to deliver all of the promised work. We’d only been able to deliver 80% of objective one. We decided that in the remaining four sprints, we’d focus on objective three and drop number two completely. Our product owner informed our stakeholders so they could adapt their plans. Of course, they weren’t happy, and the morale within the team dropped.

Once again, we realized that we’d failed our OKRs before doing any actual work, this time because we didn’t set a realistic number of them. Each objective itself should be ambitious, but the number of objectives should be realistic.

To avoid overpromising and underdelivering, you could assign each key result a grading to describe what it means to partially achieve an objective. For example, what does it mean to achieve 30%, 70%, or 100% of the objective? You could also qualify the gradings by saying achieving 30% must happen (a commitment towards your stakeholders), 70% can happen, and 100% may happen but isn’t likely. And of course, remember to communicate this to stakeholders beforehand.

Why is it important to be realistic when setting goals? Because missing OKRs can have a negative impact on the entire organization. Missing goals can create an atmosphere of distrust. And when folks see that the teams they depend on have missed their goals multiple times, they’ll realize they can’t plan for their own future goals.

So, the lesson here is: set ambitious goals, but also make sure that what you set is realistic.

Reflections

Setting goals can be hard, but it’s incredibly important to give your team direction and push them towards success. If you’re thinking about introducing OKRs to your team, just remember the five golden rules: let the people doing the actual work set the goals; make sure the key results genuinely measure your progress towards the objectives; don’t set binary goals; objectives should be independent; and finally, set a realistic number of goals to create trust within your organization. Good luck!