Matt Rogish talked about using Objectives and Key Results (OKRs) for company, team, and personal goal setting at the No Pants Festival 2015 in Antwerp, Belgium. This conference covers topics like remote working and working in distributed agile teams.
InfoQ interviewed Rogish about what OKRs are and how you can use them, their strengths and pitfalls, doing annual performance reviews and managing people with numerical goals, and starting with OKRs.
InfoQ: Can you briefly describe Objectives and Key Results (OKRs), what they are and how you can use them?
Rogish: OKRs, created by Andy Grove (CEO of Intel) in the late 1970s, are an attempt to provide public, meaningful goals and direction for an entire company. OKRs tend to mirror organizational structures: they are a tree where at the top most level, the CEO and executive team set broad, ambitious Objectives ("Expand into new markets"), and then the layer below helps fill in the Key Results ("Conduct Asia Expansion Feasibility Study", "Scout Site Visit"), which then get turned into the Objectives for the layer below, and so on and so forth.
The idea is that every employee should be able to draw a line straight up the tree to the top level corporate objective, and see how they fit into the overall bigger picture.
InfoQ: What do you consider to be the strengths of OKRs? What are the possible pitfalls of OKRs?
Rogish: OKRs are required to be public within the company. At a glance, you should be able to know everyone’s priorities, the status of each, and where they need help. It also helps provide guideposts as to whether or not an individual should take on a new project: does this fit with our overall company objectives? Does this fight against it? If so, should I really be doing this?
Since OKRs are an offshoot of Management by Objectives (created by Peter Drucker in the 1950s), there can be some drawbacks. OKRs should not be used for performance evaluation - it introduces fear, sandbagging, or worse. They shouldn’t be set as production targets. And, it does require a big picture view of the system to make sure it’s all working together. Deming explicitly warns us not to use Management by Objectives because of these risks.
Finally, OKRs are not a substitute for leadership and good management. You can’t get together at the end of the quarter and fire everyone that didn’t hit their OKRs. It doesn’t work like that. You should be continually providing guidance and course corrections; if anything, OKRs provide more workload for a manager (this is a good thing!) since now you actually have something to talk about rather than vague "I don’t think you’re performing to expectations" nonsense.
InfoQ: In your opinion how can OKRs support a Results-Only Work Environment (ROWE) company? Can you give some examples?
Rogish: In a ROWE, we focus on results and not things that we feel are corporate theater or ceremony. If you can meet your results while starting work at noon and ending in the evening, great! If your results are being met, I don’t care where you are.
Want to catch a movie with your family in the afternoon? Great. Work from the beach? Awesome. Go on vacation for two weeks? As long as your results are met (or we negotiate otherwise).
Your time is yours: do with it what you will.
OKRs provide the guidelines and results that you need to meet. It’s built right in. You’re an adult and you can manage your time and results.
InfoQ: Some say that traditional performance management with annual reviews doesn’t work for agile, it can even hamper agile. What is your view on this?
Rogish: I think traditional annual performance reviews don’t work at all; I think the failure is orthogonal to agile.
I believe in continuous improvement (kaizen) - the Plan Do Study Act cycle. In many ways, you can think of a performance appraisal as an improvement cycle.
Personal improvement works if the "Study" step happens shortly after the "Do" step. That is to say, waiting a whole year to evaluate performance is way too long. How can you meaningfully discuss someone’s work 11 months after it happened (and if you have 5-7 reports - you have to keep everyone else’s work in your head, too!)
As a CEO, I like OKRs as part of the "Plan" step. We plan as a team, I check in periodically with my leads in our one-on-ones (weekly or bi-weekly) and I give gentle course corrections. Repeat.
I also think that bonuses/raises should be handled outside of the review process. We setup personal OKRs that are tied to a public ladder and once you’ve been performing at the next ladder up for 3 months, you get the promotion! It’s a bit oversimplified, but that’s the high level.
InfoQ: Can you really manage people with numerical goals?
Rogish: No. Not at all. In Business school, there is an overall tendency in some of the classwork to try and boil people down to numbers, and manage-by-number; I had some of this experience myself. I’ve corroborated this with friends who have gone to top-tier B-schools, so it wasn’t just an isolated incident. I’d like them to be teaching more holistic, systems-based theory, but I wouldn’t be surprised if they weren’t.
Deming said "Eliminate management by objective. Eliminate management by numbers and numerical goals. Instead substitute with leadership."
Or perhaps more to the point: "Management by numerical goal is an attempt to manage without knowledge of what to do."
I wholeheartedly believe in this. People are too complicated and work too interrelated to judge a single person by a number or any combination of numbers.
As a manager, you need to understand the work, be able to evaluate the work, and be able to change the system to give your people the best opportunities to succeed.
We all have stories of the clueless manager who comes in and starts evaluating developers by KLoC or points delivered per week or some other such nonsense. This is what happens if you try to manage what you don’t understand: I see management-by-the-numbers as a key component in that failure.
InfoQ: If an organization wants to start with OKRs, can you give them some advice?
Rogish: Some general tips:
First of all, OKRs are not to be used in performance evaluation. Never, ever. No. Don’t. It’s very easy to accidentally have that occur. Tell everyone in no uncertain terms it will not be used in performance evaluation. And mean it!
Secondly, start small. It generally takes a couple of cycles to get it right. Plan on a quarter or two until you’re firing on all cylinders.
How to start with OKRs:
First, it’s important to instill a culture of planning, if you don’t have it already. Have your people set individual weekly plans, OKR style. This should be pretty straightforward and by starting small, on an individual basis, you can work out any kinks in your process and tooling.
After that is behaving well, roll that up into a team’s monthly goals. See how the team can work through the planning process. Do they need weekly updates? Monthly? Now’s the time to figure that out before you start coordinating with the rest of the company.
Now that you have the mechanics down, you can focus on the top-down aspect. Where do you want to be a year from now? What do you want to do? Where do you see your product going?
Set some goals, to the extent that you can define it that far in advance, and then work backwards quarter-by-quarter. If you want to triple revenue by the end of the year, what do you need to do Q4, Q3, Q2, etc. to make sure you hit that goal?
Then, it’s a matter of communicating this to your company, and performing the small-scale OKR effort but on a company-wide basis.