Software EngineeringOKR Examples

What does a software engineer do?

A software engineer, also often referenced as a software developer, is typically working on building various types of software. This can range all the way from software being used by millions of users, which we all have installed on our phones, to software that sits inside physical items that we rarely notice.

In web development, you often talk about backend - and frontend development. Generally speaking, you’re like working in one of these, but there are also plenty of software engineers who are what’s called “full-stack”, meaning their competencies are spread across both disciplines.

Why software engineers should work with OKRs

Software engineers who are not yet using OKRs can definitely benefit from having a look at the framework. It laser-focusses on what’s most important (more on this below) and makes it very easy to reject tasks and projects that are not helping software engineers and other people in their team achieve their goals.

What’s important for software engineering OKRs

One of the benefits of the OKR framework is that it helps teams focus. Focus on what’s important and zoom in on, optimally, a single goal for each OKR cycle. This is very relevant in engineering disciplines, as people can often just opt to focus on working on what they like or “what would make sense to do next”.

When are software engineers a success?

Related to the primary goal of Software Engineering, it’s important to define when Software Engineering efforts are considered a success. This will help clear any doubt about whether some project added value or not, as it will be very clear, due to the nature of OKRs if it was achieved or not.

For example, if you're a software engineer working in a SaaS business, the business likely has both high-level company goals, and usually also goals for the technical teams. As such, it's important to be aware of these and know how to contribute to their success.

What makes a great software engineering OKR

As you can see from the examples above, there are plenty of ways to create and formulate OKRs. But there are key requirements that OKRs should pass.

Why software engineering key results should not be binary

If you google “key result examples”, a lot of times you’ll stumble across many sites suggesting that you could create key results like “Launch new feature X”. Don’t! Why? Because what if you launch that feature and it’s a failure?

The purpose of Key Results is to enable you and your team to track progress on them, objectively. You should be able to pull in a person from the street, give them access to your data and have them answer how you’re doing.

But if your Key Result is binary, you’ll only be able to answer the progress questions once you’ve finished the OKR cycle. That’s a problem and it’s one that lots of teams who work with OKR face.

A great exercise that will enable you to get rid of binary key results is to ask yourself “Why do we want to do X?”. Maybe your team has observed a problem and plans on doing something to fix it. If you do, what state will that put you in? What will the desired outcome be? That should be your key result.

How often should I track key result progress?

You should track progress on your key results as often as you expect there to be changes in progress. If you’re hoping to see weekly progress on your key results, update them weekly.

On the other hand, if you only expect there to be noticeable progress on a monthly basis, reporting on it every week makes little sense. You should instead use the time to make sure that the initiatives you plan for are adding true value to the progress.

How ambitious should software engineering key results be?

In short, key results should have a probability of being achieved by 50%. But why 50%? One of the requirements for key results is that they should be very ambitious. 

The reasoning here is that people very often overestimate what they can do in a day, but underestimate what they can achieve in a month or quarter. And so, setting ambitious targets often lead to extraordinary results. This is one of the reasons why the OKR framework is so popular.

In addition, when scoring your key results, it’s usually told that achieving 70% of your target goal is enough to call the goal “achieved”. This is again one of the reasons why key results shouldn’t be binary as you’ll then only succeed or fail. Nothin in-between.

How Many Key Results Per Software Engineering Objective?

You should create as few key results as possible to achieve your objective. The overarching benefit of OKRs is laser-focus. Creating too many key results will spread focus and you’ll likely have too many initiatives not being related to each other. Also, improving on one key result should ideally not affect progress on another. If so, then they’re likely too dependent on the same things and should instead be merged into one.

We usually say that unless your objective is covering a larger team, sticking to 1 or 2 key results should be enough. Remember, the key here is to be very focused on moving in the same direction.

Large corporations often have more key results, but that’s usually also because each department or team is responsible for one each. This makes great sense, but if you’re creating them for your own small team or yourself, stick to as few as possible.

How Many Key Results Per Software Engineer?

If you’re setting key results on an employee level, you should aim to stick to as few as possible. The reason is that employees are likely also working on team or company OKRs and their focus should be as tight as possible.

Companies like Spotify chose to ditch personal OKRs because the overhead was too big. They essentially spent too much time creating them. So if you’re going to use them, make sure they’re as few as possible.

Prioritize Outcomes Over Outputs

Working in Software Engineering, it’s easy to get caught up in focusing your day-to-day work on the outputs of what you do. Doing X gets us Y. You shouldn’t do that.

OKRs are meant to force you to think about your desired outcome. The happy place where you’ll be once you’ve done the necessary work to get there. Think: “If we succeed with this, which things will have changed and to what?”.

Then activate the people in your team and democratize how you’ll get there. The key way to turn output-focused goals into outcome-focused goals is to ask “why?”. “Why do we want the output you’re describing?”.

The Software Engineering Initiatives Is What Will Get You Over The Finish Line

OKR initiatives are day-to-day tasks that you do in order to achieve your OKR objectives. The results are measured by your Key Results and will ultimately determine whether your initiatives were the right choice or not.

Initiatives are super important because they make sure that everyone involved is working towards the same goal; achieving the objective. Whenever you start planning your OKR cycle, make sure that you immediately start brainstorming on initiatives as well. This often gives people a great idea about whether you’re stretching too far or if you're being ambitious, but also realistic.

How Software Engineering OKRs Should Be Structured

When you create your OKRs, they should include these elements at minimum:

1. Objective

2. Key results

3. Owner

Before the cycle, it’s important to have these three defined, as they’ll help set direction and keep people accountable.

Ideally, as mentioned earlier, you should also start brainstorming early on initiatives that you think could potentially drive the OKR forward.

Criteria For Software Engineering OKRs

Overall, a great Software Engineering OKR should follow the SMART guidelines of being:

1. Specific

2. Measurable

3. Achievable

4. Results-oriented

5. Time-bound

1st Software Engineering OKR Criteria: Specific

Your OKR should be specific enough so that when other people within the organization, that aren’t necessarily on your team, knows what you’re working on. No one ever got punished for having an OKR that was a bit too long. Instead, writing fuzzy or unclear OKRs is a definite no-go.

2nd Software Engineering OKR Criteria: Measurable

Because OKRs are usually working with specific metrics, it’s a lot easier to check the box that the OKR is measurable. We measure things that are relevant to progress within SaaS.

3rd Software Engineering OKR Criteria: Achievable

It’s important to have achievable OKRs. They should always be ambitious, but nothing is more demotivating than unachievable goals. A rule of thumb is that the chance of achieving a Key Result should be around 50% from the start. If you reach 70% and above, it’s considered a success.

4th Software Engineering OKR Criteria: Results-oriented

Being focused on results is a very important aspect of OKR. It’s so important, that we’ve dedicated an entire section to describing why you should focus on outcomes over outputs below.

5th Software Engineering OKR Criteria: Time-bound

A key part of defining a goal is also defining when you’re expecting it to be met. For OKR, your goals are usually divided into different cycles and your goals should of course be reached within the end of the cycle.