Objective and Key Results
The Objectives and Key Results (OKRSs) framework needs no introduction: it is the most popular goal setting framework across tech companies. There are however many possible interpretations and ways to apply the framework in practice.
We will base this guide off the excellent Radical Focus by Christina Wodtke.
We use the Radical Focus case study of the TeaBee to illustrate how to configure Echoes to use with OKRs. TeaBee’s mission is to bring high quality tea to fine restaurants. They are undergoing a pivot to sell to restaurant suppliers.
Echoes lets you categorize work items across arbitrary dimensions. Dimensions are customizable trees of nodes, which we can use to map our company OKR.
We’ve put the company objective as a top-level node, with its key results as sub-nodes. As we will see, Echoes makes it easy to tie day-to-day engineering work to each of these nodes. But what about the activities that do not fit in any of them? Indeed, there are many things we do as part of a product-engineering organization which are about keeping the lights on and preserving our ability to deliver quality software sustainably (what Radical Focus calls “Health metrics”).
Separately, there may be changes we prioritize based on sales opportunities or customer demands. They are not part of our goal setting cycle, but ignoring this part of the work would make for an inaccurate understanding of our reality. How you want to call these is again up to you (e.g., disruptions, unplanned work): in this guide we will call it “fast-track”.
We will therefore use three additional intended outcomes:
- Fast track: user-visible changes (e.g., features, fixes) prioritized outside our goal-setting cycle.
- Throughput: all changes intended at preserving our own ability to deliver software safely and sustainably (e.g., testing, automation, maintainability).
- Risk mitigation: all changes intended at mitigating risk (e.g., fixing security issues, managing dependencies, legal compliance).
Keep in mind that these definitions are yours! Some companies choose to rename “Throughput” to “Maintenance”, others discard “Risk mitigation”. What matters is that these outcomes have the same meaning both to contributors (who will categorize their work accordingly) and to consumers of the reports (who will use the data to make decisions).
Each of them get published by Echoes across your product-engineering tools on which Echoes is enabled, such as:
GitHub repository labels
GitLab repository labels
JIRA custom field options
Linear issue labels
Echoes provides a consistent way to materialize the link between day-to-day work and the OKRs, regardless of how individual teams choose to operate locally, and with minimal overhead.
Should key results (the KR part of the OKR set) be mapped in Echoes? The answer depends on how your key results are written. The deciding factor is whether engineering work is expected to directly influence the key results, or whether engineering work only ever contributes to the objective itself.
- If we stick to the book definition of OKRs where key results exist solely to measure if the objective has been met, the answer is likely no. The work contributes to the objective, and its achievement is measured thanks to the key results.
- If however your key results are “inputs” to the objective, such as a deliverable or an intermediary step to get there, the answer is likely yes. The work contributes to key results, which in turn contribute to achieving the objective.
The “Framework” section of Radical Focus covers why, even in the most successful companies, the thing we have determined must happen often doesn’t. We will illustrate Echoes value proposition in the context of OKRs using three of the reasons mentioned by the author:
- We haven’t prioritized our goals.
- We haven't communicated the goal obsessively and comprehensively.
- We give up instead of iterating.
From Radical Focus:
With so many people running around, you are sure you can get many goals to move forward. But the reality is, running a company takes work all by itself. Each day people are running hard to stay in place: fulfilling orders, stroking customers, minding hardware. Add to that the background noise of a half-dozen goals, and you assure very little beyond the bare necessities will happen.
Echoes ties engineering work to purpose, providing insights into our direction as a group. This makes Echoes uniquely capable of making a lack of focus visible by highlighting teams chasing multiple goals over the course of a single week, or switching focus across goals from one week to the next all while keeping the lights on.
If Echoes will not help you make the right prioritization choices, it will however reveal whether priorities are clear all the way to the field.
From Radical Focus:
Once you have picked the goal you want your team to focus on, you have to reiterate it daily. […] To set a goal and then ignore it is an easy recipe for failure.
We have seen how Echoes materializes the goal in your product-development tools (for example as GitHub labels, GitLab labels, or a JIRA custom field).
More importantly, Echoes makes every work item (i.e., ticket, GitHub pull request, or GitLab merge request) an opportunity to think about the “why”. Echoes puts the purpose of work on top of everyone’s mind, making explicit which activities do and do not contribute to the goal.
From Radical Focus:
The most common failure is not tracking efforts toward OKRs. I’ve seen any number of companies set OKRs, then ignore them the rest of the quarter. When the last week of the quarter shows up, they seem surprised when no progress has been made.
Tracking efforts toward the goal is Echoes core feature: we help associate all work items to their intent. Echoes surfaces the allocation of efforts of the team and in real time, making it impossible to realize too late that we’ve been working on the wrong things.
Radical Focus recommends a single company objective:
I believe the one thing that makes the difference between excelling and flailing about in mediocrity is focus. Focus is hard, but it’s necessary. Doing the hard work to decide on one company Objective is key.
Following this advice isn’t required in order to use Echoes with OKRs as it is possible to configure as many OKRs as you need. Keep in mind that the purpose being to connect engineering work to business goals makes it unnecessary to map in Echoes company OKRs which wouldn’t be related to product or engineering.
Although Echoes supports mapping an arbitrary number of OKRs, we advise against mapping team-level OKRs for the following reasons:
- Each node of your intended outcomes will be published to your product-development tools as labels. Keeping the configuration simple therefore makes it easy for the teams to properly tag work items, which in turns contribute to better data quality.
- Echoes treats all repositories equally. A given repository is not assumed to “belong” to any particular team, therefore Echoes assume that work in any repository may contribute to any goal. Materializing team-level OKRs may result in many labels being created across repositories, hurting the ease of tagging for contributors.
If Echoes can help materialize the link between engineering work and business outcomes, perfect is the enemy of good. Aiming for too much details will hurt the ease of tagging for contributors, and the readability for consumers of the reports.
Echoes initiatives can capture a milestone (such as a major release), a project, or the delivery of a sizable cross-team feature. The composition of an initiative captures which goals it contributes to. Let’s capture a “Replatforming” initiative which is about breaking up a historical monolith. We’ll define this initiative as contributing to both our throughput (our ability to deliver software sustainably) and to risk mitigation (as we believe we are at risk of a significant outage any day on the current platform), with respective weights of 80% and 20%.
Like our OKRs before, this initiative will get published to your product-engineering tools in each platform’s most appropriate way. Work items labeled with the initiative will see their efforts ventilated on its components according to their respective weights, providing an additional layer of detail in our understanding of the activity.
OKRs are time-bound goals which commonly change on a quarterly basis. As your goals change, your Echoes configuration should naturally follow.
Past goals can safely be removed from Echoes configuration: this will not delete any past annotation of work so that your history of efforts is not lost. Deleted outcomes will however disappear from your product-engineering tools, such that no new work items will be tagged for these archived goals.
Echoes is a great companion to the OKR methodology as it helps avoid common pitfalls: failing to prioritize the goal, failing to communicate the goal, and failing to track efforts toward the goal.
Like with the OKR methodology itself, focus makes all the difference: few properly mapped shared goals is a better use of Echoes than a complex tree of team-level OKRs.