What’s usually wrong with tech OKRs?

When I bumped into OKRs for the first time, it looked like nothing but a disturbance. Aligning goals with others? Looking at outcomes rather than outputs? Yet another planning meetings in my calendar? Nah, I only wanted to code features and deploy stuff.

Some time has passed. I had a chance to work with OKRs in three different companies. I heard stories from a few friends implementing the framework in their companies. And I’ve been using them to keep up with things I care about in my personal life. I got hooked.

I realized mistakes we make when starting with OKRs are kinda the same. I made them, and I seen them repeated in many teams. Here’re three challenges that I see common in tech teams.

Too much OKRs

Having way too much Objectives, Key Results, Actions, Dreams, Wishes, Expectations, Promises, and whatever else you can fit into that excel sheet. This is something I struggled with a lot, and I seen this repeated over, and over again out there in the world. People putting everything they may need to work on into OKRs. Getting themselves distracted, instead of focusing on the single, most important thing.

You will work on unexpected things, especially when starting with OKRs. Get the most important thing as Objective. And leave yourself space to welcome surprises with excitement.

As a starting point I’d go with one less Objective than team members, with a total cap of three Objectives per team. That is:

• one Objective for 2 people team, or solo contributors
• two Objectives for 3 people team
• three Objectives for 4+ people team

This makes you choose the most important stuff and focus on them. By having one less Objective than people you’ll have to work together. Which is a neat trick to promote team work.

Sounds scary, doesn’t it?

Actions, not results

Confusion between outcomes and outputs is common in tech, and it finds reflection in OKRs. Sometimes it’s hard to measure the real impact of tech activities. So we default to obvious ones, so often favouring personal goals over the team interest.

Things like „Implement 500 test cases for feature XYZ”, „Refactor codebase of ABC”, or „Build a new microservice” are exciting to developers, but they (usually) bring no value to company. In fact, delivering those can hurt. What if those 500 test cases are flaky, and it takes 2 hours to run them? Congratulations, KR delivered. Life made worse.

I’m sorry, but your CEO doesn’t care about number of test cases, and your customer doesn’t see your messy codebase. They care about stability, and ease of use of the product. Find a way to reflect that in the KRs.

Focus on outcomes, like:

• KR1: Decrease time for new feature QA step to 1 day (by having more automation)
• KR2: Improve response time of /xyz endpoint to 200ms (by extracting service XYZ)
• KR3: Maintain over 4.5 average score from customer satisfaction survey
• KR4: Have at least 1000 customer replies to satisfaction survey

Subjective Key Results

This often comes in pair with actions instead of key results, stuff like: — Clean up the codebase of the service FooBar — Improve work culture — Improve collaboration between Development and Customer Support — Have a consistent brand communication across social media

Those are great things to have, but how do you know if you delivered those, and how would you track them on weekly basis? Weekly percentages could be used on that, but they’re subjective feeling of reporting person. Cleaning the codebase can be 50% done for one person, but 10% for another one, exactly at the same moment.

Work culture can be amazing for a new hire who recently arrived from a terrible place. Yet it can be a nightmare for that burnout guy doing regular after-hours for the last 5 years. KRs must leave no room for debate. It’s either delivered or not. For everyone on the team, at the same moment.

When you bump into those hard-to-measure ones, pay attention. You may be looking at Objectives needing their own Key Results. Turning the last example into:

Objective: Improve work culture

• KR1: Get average score of employee satisfaction survey >4.5
• KR2: Reduce after-hours of C-level employees to 0
• KR3: 0 employees have worked over a weekend

Objective: Cleanup the codebase of service FooBar

• KR1: Maintain test coverage between 80 to 90%
• KR2: Keep Rollbar exceptions under 50 per week
• KR3: Decrease number of rolled back deployments to 0

Wrap up

Single Objective with meaningful, measurable results will bring more value than a year-long roadmap squeezed into that excel sheet. The first one can align the team working towards a common goal. The second becomes a list of failed promises that nobody wants to fill up anymore after the first month.

PS. You can change the OKRs during the quarter 🤯

To get notified about the next post make sure to hit that Follow button. Thank you!