What We've Learned by Defining OKRs in Engineering

In the 1970s, Andrew Grove, then CEO of Intel, introduced objectives and key results (OKRs) to define measurable goals and track their outcomes within the company. The framework has received renewed popularity in recent years after being embraced by Google and other tech companies. According to former CEO and Google co-founder, Larry Page, "OKRs have helped lead us to 10× growth, many times over."

We decided at the beginning of 2022 to start using OKRs at Float to ensure that our company was aligned with the same shared objectives while providing latitude for different departments to approach goals with autonomy. In order to be flexible and adapt to circumstances (while keeping the overall strategy in mind), we've set annual company-wide goals and quarterly department-level goals.

Within the engineering department, in particular, individuals can trace the work they perform each day to the broader goals of the department and, ultimately, the company. This provides a sense of engagement, helps prioritize tasks and projects, and creates a shared context within which we can have sensible, nuanced discussions.

Having pre-agreed OKRs for the engineering department also allows us to allocate our time and resources more appropriately. For example, knowing our objectives for this quarter means we can spend time on technical discovery work and explicitly focus on customer issues while maintaining regular product feature maintenance and development.

"OKRs have helped make our crazily bold mission of 'organizing the world’s information' perhaps even achievable. They've kept me and the rest of the company on time and on track when it mattered the most."
Larry Page, co-founder of Google

In this article, I'll show how we've approached OKRs in engineering and share some learnings that can be applied to other teams and settings.

Five important takeaways from our experience

OKRs are a new approach at Float, and our objectives from the first quarter reflected some of this inexperience. Here's what we came up with:

1. Maintain an engaged engineering team
2. Deliver reliable code in deployment cycles
3. Improve the performance of our API services' response times

By the end of Q1 2022, it was apparent that these weren't the best selection of goals. Referring to Stacey Barr's excellent article ​How to Make OKRs Measurable, it was clear we had fallen into some of the common pitfalls she describes.

Here are the most important takeaways from our first attempt at OKRs and how we have improved the process in Q2 2022.

Make sure OKRs are appropriate

After reflecting on our Q1 OKRs, it became clear that the first two weren't really appropriate objectives as part of an OKR framework. The first is really just the responsibilities of the Director of Engineering (ahem, me!), and the second is table stakes for our application engineering division. As such, having them as OKRs didn't make much sense—they are goals that should be delivered regardless.

So, it's important to look at OKRs as something to strive for that go above and beyond the day-to-day. Think about your team's vision and how you'd like to take their work to the next level.

Be specific about what you're looking to do

In Q2, we've tried to be more specific when setting our OKRs. For example, rather than delivering reliable code, we're actively looking to improve the quality of the work produced. And similarly, rather than simply maintaining an engaged team, we are looking to reduce the number of distractions the team faces. It's resulted in the following OKRs for Q2:

1. Improve the quality of work delivered during cycles
2. Reduce noise and distraction from unnecessary alerting
3. Provide a service that can support a customer of 2x [our largest customer] scale

There's been a noticeable shift in how these objectives are framed and their general feel. Specifically, we've tried to have more aspirations in the objectives (hence, improve and reduce rather than maintain and deliver).

Be clear about how you define OKRs

When reflecting on Q1 and looking ahead to Q2, I used the following as a guide to ensure that our OKRs made sense and that we weren't confusing quotas with key results.

• Objectives are high level aspirations that are unlikely to have any hard numbers in them (numbers generally belong in the key results rather than the objective).
• Key results are numerical or at least data-based information that, when achieved, should be both necessary and sufficient for the objective to be attained. These numbers are measurable but should not be directly correlated with our own actions.
• Inputs are numerical data that we have direct control over. We should be able to increase or decrease these at will, time permitting. These represent our understanding of the levers at our disposal to influence the key results.
• Actions are what we intend to do to our inputs to get the resultant change we seek in the key results and ultimately in hitting the objective.

Here's a concrete example:

Objective: Reduce noise and distraction from unnecessary alerting

As always, there's a balance between what we want to achieve and how we do it. If I were to re-visit this objective, I would make it less about the alerting and more about providing additional focus time since that opens up the discussion to more than just alerting (e.g., number, length, and timing of meetings).

Key results: Number of Slack notifications to #tech-alerts-* channels over Q2 reduced from 48 per day to 24 per day

In this case, we chose a single key result since this encompassed most of what we want to achieve, and we're fortunate that the majority of our notifications and alerts are already funneled through this conduit. Note the numerical results here, which are straightforward to measure with some simple Slack queries.

Inputs: We have several integrations that feed notifications into these Slack channels, many of which are not actioned (or even actionable). So our inputs are the percentage of notifications that are acted upon. Our assumption here is that if we increase the percentage that are acted on, the overall volume will decrease over time.

Actions: Given the primary input we're going to focus on, there are two natural ways to increase the percentage of notifications acted upon. First, we can be stricter about what is worthy of a notification. Second, we can be more deliberate about acting on these notifications. The underlying assumption is that if we act on more, there will be fewer re-notifications.

Involve the wider team

One concern is how to involve the broader engineering team in the discussion. There are already several commitments competing for engineers' time, and, as a result, providing the space necessary for individuals to contribute to this goal-setting process has been a challenge. That said, we have recently created some extra structure within the department, which should allow smaller sub-groups to think about how they can contribute and what might make sense as OKRs.

Iterate as necessary

OKRs for our engineering department provide a shared context within which we can discuss and decide the best way to approach our goals. By deliberately setting these targets, we can have increased confidence that they are both achievable and contribute to our overall company goals.

Even so, as a small company, we need to stay agile to respond to opportunities as they arise. We treat OKRs as aspirations rather than demands and acknowledge that more important priorities can take center stage at our scale. Re-assessing our departmental OKRs every three months allows us this flexibility.

Conclusion

Creating, monitoring, and evaluating OKRs is a relatively intensive process, particularly at the end of each quarter. It is a challenge to move the needle on some of these OKRs without investing significant time and effort, and time will tell how successful we are in this endeavor. As we become more comfortable and confident in our abilities, I predict this will become easier.

Indeed, having other departments within the company also going through similar processes means there are opportunities to learn more from each other about what has (and hasn't) worked. Now that we've been through a couple of these cycles, this will become increasingly helpful and provide more opportunities for cross-department collaboration.

Creating OKRs and thinking about how we can potentially impact them has been a valuable exercise that's helped us uncover connections that might otherwise have remained hidden.

‍