Reimagining OKRs for designers and design teams
Goal setting and performance reviews have been around for a while and despite its many limitations, are a hard to live without, especially for large companies. This article explores the OKR-based model for goal setting and reviews, specifically for UX teams, and provides both guidance for and limitations of using this approach.
Introduction
Objectives & Key Results (OKRs) are probably the most commonly used performance review framework around the world. From their origins at Intel and subsequent popularity at Google, it will be unsurprising if your organisation, much like mine, use them to conduct performance reviews at both the group and the individual level. Design teams are often indirect contributors to an organisation’s success and their contribution is harder to appraise, especially when compared to functions such as sales or service. Yet, as a design manager or a designer, you will likely be asked to set OKRs, and as a leader, align your team to OKRs in order to measure success. This is an extremely difficult job in my experience, especially if you try and do it sincerely. While a case can be made to do away with OKRs and performance reviews in general, especially for functions such as design, the reality is that it is often not our choice, and therefore, this article focuses on how you can do a better job with this, albeit imperfect, system of quasi-performance management.
Performance reviews
While a historical review of how performance review and management techniques came into being are outside the purview of this article, it is worth briefly understanding the genesis of this phenomenon. In the industrial world, which gave birth to what is known as Taylorism or scientific management, workers were considered to be an input into the production process. Therefore, in order to establish which workers (almost in the same way as machines) are performing well vs. those that aren’t, a system of review was developed. Unlike today, when human capital was abundant, a simple way of trying to establish who should remain (and continue working) and who should be let go was established. The US army was one of the early adopters of a ‘merit system’ and this was followed by large American corporations, most notably GE. Similarly, GM and later IBM created complex systems to appraise the performance of its staff.
The nature of the modern corporation has shifted significantly since, changes that have been reflected in how organisational theory views employees in the first place, with modern theories looking at employees as partners in the success of an organisation. In the last twenty years, several companies actually did away with company-wide goal setting and performance systems; notable among these were Kelly Services, Adobe, and more recently Accenture.
The main arguments against performance reviews were and are:
- They take a lot of time and energy. For example, by 2015 a report from the Harvard Business Review revealed that at Deloitte it took 1.8 million hours across the firm. Adobe scrapped the practice after calculating that 2,000 managers were in for some 80,000 hours when dealing with performance reviews. Talk about a counterproductive way to spend the workday (Dishman, 2018).
- Their impact on team members is debatable. Considering that the objective of a performance review system is to reward those who perform better and improve the others, OKRs are not a panacea that many make them to be. For example, a Gallup study argues that only 14% of employees feel inspired to improve after annual reviews (Sutton, 2019).
- They work better for certain roles. If your objectives are highly tangible, it consequently easier to track them and set meaningful OKRs. However, for more supporting functions such as design, it becomes harder to do so and sometimes to the point of absurdity in my experience. However, I suggest some workarounds to assuage to this challenge in the following sections.
So, it can be argued that like Taylorism itself, performance reviews are an anachronism from the era of large, mechanised workforces, and have limited utility in the modern corporation.
However, the reality is that as an individual designer or even a design manager, you will find yourself working for an organisation that uses the OKR-based model for performance reviews and therefore need to come up with meaningful OKRs to succeed.
OKRs
Almost counter intuitively, OKRs were not originally conceived to be a performance measurement system. They were meant to create alignment and push boundaries; the idea was that people should set ambitious targets and seek to measure them rigorously. However, if they become the sole input into performance reviews, then employees start thinking much more defensively, which defeats the purpose of the OKR model in the first place. Recent studies have argued that they only make sense at a team/group level, and not an individual one (see Gothelf, 2020). This is a serious health warning that I’d offer to anyone involved in the evaluation of individual employees: do not use OKRs as the sole source of input into a performance review process.
What are they?
If you have never heard of OKRs, I suggest reading about them first as this article is not the best resource for a general introduction to OKRs (or performance management).
From their origins at Intel in the 80s, OKRs have now become synonymous with goal setting and performance reviews. This is probably because Google adopted the framework, and many others sought to emulate Google by doing so as well. John Doerr, one of the most successful venture capitalists, introduced Google to OKR, has a formula for setting goals: Doerr’s Goal Formula: I will (Objective) as measured by (this set of Key Results).
So, an OKR has two components, the Objective and the Key Results (KR): Objectives are memorable qualitative descriptions of what you want to achieve. Objectives should be short, inspirational and engaging (and technically, don’t have a number embedded in them, but this is rarely true in practice). An Objective should motivate and challenge the team. Key Results are a set of metrics that measure your progress towards the Objective. For each Objective, you might have a set of 2 to 5 Key Results. All Key Results have to be quantitative and measurable. As Marissa Mayer, a former Google’s Vice President, said:
“If it does not have a number, it is not a Key Result.”
Example
A simple, non-design example of an OKR will help set the context.
Objective:
Improve the bank’s customer service by the end of Q4 2021.
Key Results:
- Achieve a Net Promoter Score of 50 or above
- Resolve critical customer issues under 1 hour
- 40% faster data processing on the banking app compared to Q3
In summary, a proper goal has to describe both what you will achieve and how you are going to measure its achievement. The key words here are “as measured by,” since measurement is what makes a goal a goal. Without a way to measure it, you do not have a goal; all you have is a wish.
OKRs for designers
So far so good? The challenge for designers, in my experience, is that OKRs are often top down and related to the organisational or business unit (BU) objectives.
As designers, our jobs are often harder to quantify and measure, which makes it both harder to claim success, but also be accused of failure.
Recognising this limitation, which makes it much harder to set and achieve stretch objectives, let’s stick with the example above around improving a bank’s customer service. You might be a UX or UI designer working in a BU (likely a service-oriented one for this example) at the bank that is responsible for this objective. How do you contribute and measure your success in helping achieve it? Clearly, it needs to be broken down to make it more relevant to you.
Objectives — Activities—Key Results (OAKRs)
To help break down organisational OKRs to an individual level, I propose a slight modification to the OKR model, that of adding activities. In my experience as a leader (and a student of management science), I’ve seen that one of the tendencies that individuals have when writing OKRs is to define the activities or things that they’ll do, and conflate them with Key Results.
Let me give you an example. Let’ say you are a designer in a eCommerce mission or team and your manager asks you to set OKRs (often, you’ll be left to fend for yourself). They might suggest 1–2 OKRs that are at the mission level, a third that is related to the design team and perhaps a fourth that is personal growth focused. Now, let’s say that your mission has several imaginary objectives (which you have no say in):
- Increate the sales revenue through the digital channel by 20%.
- Launch XYZ new products by Q2.
- Re-platform the website’s CMS by Q3 saving $XYZ in annualised savings.
Sound familiar?
It is very likely that you’ve found yourself staring at something like this, if your mission had a set of objectives. Even worse, you might work for a mission that has not really defined their own objectives, which makes your job of defining OKRs, especially those that focus on the mission, harder.
The first question that confuses people at this stage is what is MY objective? Is it the same as the mission’s? Or is it a different, design focused one? If it is the former, what’s the purpose of having two sets? If it is the latter, how does it relate to the mission objectives? It gets confusing. There is no uniform way to solve this conundrum. However, my guidance is that:
The objective, usually at a mission level, is the same for everyone in that mission.
The ways in which you will support those objectives will vary, for your contributions will be design oriented. Let’s spend a minute on this fundamental premise. Think of a football team. You have players who play different roles, such as a goalkeeper, midfielder or a striker. What do you think is the goalkeeper’s objective for a game? And what about that of a striker? If you answered to save goals and score goals respectively, you might be making the same mistake as people do when thinking about mission or group level objectives.
The objective of every player in a football game, whether a goalkeeper or a striker is the same: to help win the game.
You might protest that this isn’t true, which is because we are wired to think about what they do (differently). The roles are different, which means the results that they seek to achieve, and be measured against, differ, but roll up to the same overarching objective, i.e. winning the match.
Building further, what could be the goalkeeper’s key results?
- Concede no goals
- Achieve a goal kick pass accuracy of 75%
- Save at least 75% of the attempts on target from within the penalty area (this will offset performance if a goal is conceded but the GK was not really to blame).
Similarly, the midfielder’s key results could be:
- Achieve a pass rate of greater than 90%
- Create a minimum of 3 goal scoring chances
- Number of assists
- Score a goal (stretch target)
You should now be able to see how individual, role specific key results will differ, even if the objective remains the same.
Activities vs. Key Results
Previously, I introduced O-A-KRs, because it is easier to think about things we’ll do in pursuit of the goal. From there, you can then set out KRs to monitor whether the activities that you undertake are helping achieve the stated objective(s). In case of the football team, there are several things that a striker will do in an attempt to help achieve the objective. For example, they might:
- Make cross-field runs to invite passes
- Not get caught offside
- Run at least 7 km during the game (running itself is not a result but it is likely a pre requisite to being able to score)
- Train 5 times a week to maintain fitness
However, the fact that you did something does not imply it was valuable; it is not a measure of success, i.e. a key result.
Getting the gist of it? Let’s go back to the OKRs we discussed above for an eCommerce mission. Your objectives are in fact the same, as exemplified in the football example. The things you’ll do to support these objectives will differ. This is where activities come in.
So, as a designer, first define the things that you will do in an effort to help the team achieve the objectives:
- Produce and deliver design artefacts in a timely manner
- Produce and deliver high quality designs based on an established design process, which includes user research & testing where needed
- Work with business stakeholders to ensure designs help drive business outcomes
- Solicit feedback during the design process from technology to ensure feasibility
- Standardise components to include delivery speed and reduce build costs
If you look closely, the activities above capture both your ways of working as HCD-professional as well as the relationship with the mission objectives. It is easier to think in terms of such activities before delving into the measurement of whether these activities yield the appropriate results. Before we define potential key results, I’d like to point out that I’ve seen several OKRs that actually cease at this stage (of having defined activities), at the most with a slight sprinkling of numbers to make them look more data-led.
Anyhow, let’s assume you are interested in building on these further; what would be some of the ways to measure the success of these activities, defined as key results? There, usually, isn’t a 1:1 mapping between the two, and often a key result can encapsulate multiple activities. But for illustrative purposes, see the following KRs that loosely relate to each of the activities above.
- Deliver designs as per the sprint schedule, maintaining a >90% rate of on time delivery (potentially measured using Jira tasks/Sprint burndown).
- Maintain a 100% rate of usability testing for new designs, unless an exception is made.
- Run at least two cross-functional alignment workshops during the project lifecycle, where appropriate.
- Conduct reviews with technical architects and development engineers at the appropriate phase for all design work that is not minor in nature (you’ll need to define a ‘when’, based on how your organisation designs)
- Create at least 5 new reusable components in Sketch that meet usability and accessibility standards. (This could be turned into a shared KR with front-end engineers if you could include the coding of the components).
With such KRs, you are in a position to go back to your manager and not just share your OKRs, but also be clear on how they relate to mission OKRs and your personal, role specific, contributions.
What if I don’t meet my KRs?
There are many reasons you might not meet your KRs; however, in the context of this article, if you define your activities and base your KRs on them, you should also be able to reverse analyse if you struggle to meet the KRs. That is, in principle, if you don’t meet your KRs, you should revisit the activities that you have been conducting to check whether they indeed contribute to the KRs. This looping process will help refine your activities and KRs on an ongoing basis (as against setting them up once every few months).
Summary
There are many ways to skin a cat. The best approach for defining and measuring progress using an OKR-based model will be contingent on a few issues:
- How your organisation uses OKRs and the overall maturity
- Your profession (in this case design, which is a supporting function)
- The rigour which you personally seek to apply
We saw, using the footballing analogy, that objectives are best thought as being shared. Using the O-A-KR model allows you to understand the relationship between the overall objectives and the things you do to help achieve those goals and the measures that you can put in place to capture value creation. Our minds are much better equipped to think in this manner, rather than to directly define measures of success, and hence it is useful to define the activities first before seeking to define the KRs.
OKRs or any KPI management system is only as good as its implementation. The popularity of OKRs has made them fairly ubiquitous in the tech industry, unfortunately, in many cases, without having the necessary organisational maturity and frameworks to do it any justice. As leaders, we must understand this to both manage expectations of your team (it will be harder to justify high performance) and also recognise the limitations of an OKR-based approach for performance management, even if implemented well.
What then, can and should be used to measure the performance of designers, and more generally individuals, is an open question, and perhaps a topic that I shall explore in a subsequent article.
References
- Dishman L. 2018. Available at: https://www.fastcompany.com/90260641/the-complicated-and-troubled-history-of-the-annual-performance-review
- Sutton R., and Wigert, B. 2019. Available at: https://www.gallup.com/workplace/249332/harm-good-truth-performance-reviews.aspx
- Gothelef, J. 2020. Available at: https://hbr.org/2020/12/use-okrs-to-set-goals-for-teams-not-individuals
