OKRs? More like, R U OK?

Why OKRs do not work for engineering teams

I started my first job as a software engineer in the early 2000s. Since then, I’ve been part of nine different teams in companies of all sizes, including my own, and every single time, at some point, we would talk about objectives and key results, or OKRs.

At first, I was open and equally skeptical about trying it. I was open because, in principle, the idea feels sound: you have concrete objectives, and you have to implement measurable ways of tracking their progress. But, I was still skeptical, the same way every software engineer knows that just because a big, famous company implemented something and worked for it, it doesn’t mean it will make sense for your team. Still, in the spirit of being a good team player, I, most of the time, went along with it.

Most of these OKR conversations happened when the team was growing, and communication seemed to be breaking, or when a new manager would experience pressure from the top to justify priorities or improve alignment.

What I found fascinating about these conversations is that we rarely took the time to debug our underlying issues. Instead, we’d quickly commit to a new way of conceptualizing work.

I know some of you reading this post may have had great experiences with OKRs, so I aim to share arguments as to why I strongly believe OKRs do not work for engineering teams. If OKRs worked for you, please share the specific context that made them work in the comments. That way, we all learn from each other. Deal?

Here’s why OKRs do not work for engineering teams:

Incompatibility With Agile Principles

Notice I’m referring to Agile, not Scrum (I’ll leave my Scrum disappointment for another post). Agile is about prioritizing adaptability and iterative development. In most companies, OKRs are done every quarter, and assume goals will not change based on new customer insights, market changes, or technology breakthroughs.

When it’s your turn, you get to break down individual goals that are often only tangentially related to customer needs (if at all), and you have to achieve them no matter what, especially if they are tied to bonuses, etc. In my experience, most people set up easy-to-achieve goals and forget about them until they have to revise them again before reviewing and setting new ones.

It feels like assigning story points to “issues.” It is an imaginary exercise to try to control what you know you can’t control — estimating effort. OKRs that rely on accurate estimations can set teams up for failure or, conversely, set the bar too low. Good luck if one of the objectives depends on another team (or external factors).

Potential for Shortcutting and Technical Debt

The pressure to meet aggressive OKRs can lead to taking shortcuts, especially when they’re tied to compensation. People will take care of themselves first; if you ask people to set up a goal in exchange for money, they will achieve it whether it is good for the users, code base, or business.

Another scenario involves working just for the sake of work — it happened to me: one of my goals was to add a new provider to an existing billing system. When I asked why, I was told we needed to get it done because it’s part of my goals, and the product needs to support more billing providers. I was confused; if this were a priority driven by customer demand, it would be a part of our regular work stream, and we would have a clear reason for it. Instead, we ended up with half-baked code that would not survive first contact with a real user. But I got my goal done, so we’re all good, right?

Making Learning a Key Result

While companies invest in various software tools to track OKRs, these tools don’t necessarily track learning. The point of having goals is to create a sense of direction, but as we move along the path of trying things, as we experiment, we learn things that may challenge the direction altogether. OKRs are not about challenging the goals. Instead, they are about ticking a box.

But as you’d expect, learning ends up being one of the things that do end up being a part of OKRs. I’ve seen this firsthand when a person had to do a presentation about a piece of infrastructure they weren’t familiar with. That’s perfectly fine because they were interested in it and expanded the team’s knowledge, but… how did that exactly fulfill the objective? Which was… well, I’m not sure what it was exactly, something about making the team “better.” But what if that person did a presentation and got it all wrong? How do we score this? 50%? There was a result, but did their manager actually care about this?

Learning is a continuous process; it’s not something that happens because it’s being measured.

Before I wrote this article, I was curious to see what information was out there on OKR and engineering teams. As I expected, 99% of the articles supporting OKRs were written by companies selling OKR consultancy or tracking software. Fair enough, but if you search where the conversation is happening (Slack channels, Reddit, Hacker News, etc.), you quickly find that the general sentiment is one of disappointment and frustration, at least for the ones who shared their stories.

A lot of it comes down to the fact that OKRs are pushed down to the individual, and because of that, the “vagueness factor” explodes and makes people feel like it’s a complete waste of time.

According to Rick Klau — you’re supposed to set OKRs on a team level. Okay, but then… doesn’t it mean that the problem got shifted one level up, and whoever manages the team is now responsible for the OKR? It smells like a bad case of “you’re holding it wrong.”

The business world is filled with this type of theater, where teams adopt the latest best practices that work within a very specific context, and then behind the curtains, we all tell each other what a waste of time it was. Most of the time, teams have no power to change the fact that OKRs are part of their organization; perhaps we should push harder.

But Lukasz, How Do I Align My Company/Division/Team/People With the Business Goals?

Go back to first principles. Alignment is mostly a problem with communication and how decisions are made. I always look there first before implementing any framework or process. Talk to people, seek the truth, eliminate fear within the team, find what is confusing, and try to solve that. OKRs can wait.

We need to get better at managing technical debt, shipping fewer bugs, improving customer satisfaction, reducing attrition, developing new features, staying competitive, and more.

If you’re a leader — your job is to ensure that anybody in the organization knows where they are going.

There are millions of things to rally people around; attempting to translate the broad statement “We are a business and need to make more money” into a cascade of detailed goals and then assuming that this process achieves true alignment is misguided.… It ain’t gonna work out.

“The best companies don’t cascade goals; the best companies cascade meaning… Our people don’t need to be told what to do; they want to be told why.” — Marcus Buckingham, author of Nine Lies About Work

If you found this article helpful, you may also like what we do at Collie.

Collie helps engineering managers have better conversations and make the most out of every meeting.

OKRs? More Like, R U OK? was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.