OKRs when scaling your organization

I recently held a short talk on OKRs, and how their usage develops over time when used in a scaling organization. Here’s a summary of the talk, which was in Norwegian. The original slide deck can be found here. Sadly, it wasn’t recorded, but here’s a summary in English.

So, the starting point here is that I saw a recently released old interview with Steve Jobs in which he talks about how Apple is organized. He says that he has one person responsible for each area and that the teamwork between these people at the top will spread to the rest of the company. The prerequisite for this to work, he says, is trust.

[..] and teamwork is dependent on trusting the other folks to come through with their part, without watching them all the time.
- Steve Jobs

So this is obviously about culture, both within teams and in the organization as a whole. How might we build an organization where everyone trusts each other in delivering what’s needed? That being said, despite trusting others we still might need to know what others are focusing on, and how that’s going. In short, we all want to know:

1. What’s the main focus within my team?
2. What’s the focus of other teams?
3. Are what we and other teams are focusing on aligned so that we are going in one direction?
4. How are we all moving along in that direction?

This is where management by objective with a model such as OKRs might be useful. It can be traced back to the 1950s with Peter Drucker’s book “Management by Objective” His point was that you get more engagement and higher performance when employees and leaders set goals together. Later he made it clear that this is a tool, and it doesn’t make it easier to set the goals themselves. Nevertheless: In 1974 Andy Grove implemented MBO at Intel when he was CEO there. He established it as OKRs - Objectives and Key Results. John Doerr brought it to Goole around 1999 and wrote the book Measure What Matters which was released in 2018. This brought OKRs into companies in Silicon Valley, and over the last 2-3 years Norway as well.

What’s the model about?

Objectives and Key Results consist of:

• Objective – an ambitious, qualitative, and time-bound goal
• Key Results – measurements for knowing if we’ve reached the goals

Read more here. That reference mentions something that in my experience is often forgotten: Initiatives. Where the Objectives give direction, Key Resultsmeasures progression, and the initiatives are the concrete actions we take to get us there. This is usually tracked in portfolio management or JIRA tasks for teams. One set of OKRs can have all its initiatives in one team or multiple initiatives across teams. Each team does not necessarily need its own OKRs.

What’s the problem?

This would be a sort of boilerplate for how to implement OKRs:

1. “Someone”, such as a management group or board, communicates an established strategy. It might consist of:
   1. A description of the business the company is in
   2. The challenges/threats that the company has to overcome
   3. Some policies as to how those challenges are to be met
   4. And some high-level but quantified goals to reach for
2. Teams create their goals with that strategy as the context
3. Leaders meet with teams where they do not see how the goals match with the strategy

In my experience, the process becomes difficult because:

1. Missing strategy, in the one or more sense of the word “missing”:
   1. There is no strategy
   2. There is one, but it’s too difficult to communicate
   3. It’s not updated often enough, so it’s not relevant to the business
   4. It’s created in a waterfall manner, rather than as a platform others can build upon
2. The teams do not recognize themselves in the strategy, i.e. they cannot work on the goals they set based on the strategy because there’s a delivery “they just have to deliver”
3. If it’s not in the OKRs, the team thinks it’s out of scope, e.g. technical debt.

This brings us to heartbeat work.

Heartbeat work vs. strategic work

In her excellent article called “Not Everyone Needs Objectives and Key Results (OKRs)” Christina Wodtke established the concept of Heartbeat Work.

She places work into three categories:

1. Strategic work: Identified big-ticket challenges that will create necessary change within your company. Either to stay afloat, or capture a new market. To do this, we need to focus on, and measurement of, that improvement. Tracked with OKRs.
2. Continuous improvement work: Established products needs continuous improvement to make sure that you do not lose the market or the customers. This is everything from improved features to post-mortems. Best tracked with Kanban-boards, pipelines for improvement, roadmaps
3. Heartbeat work: Work that “just needs to be done”, or the business will stop. It can be associated with established revenue streams, but it also functions such as HR and law in large corporations. Operations and making sure IT systems run are a part of this. Some capabilities are so that we need them, and their work is continuous. The work can usually be tracked with dashboards, metrics, or kanban work.

I find this model quite useful, as it explains why shoehorning your goals into the OKR model might be difficult. OKRs are not a silver bullet for tracking work.

How the use of OKRs can change as you scale

So, let’s say you’re a small startup company with a great business idea. You use OKRs to give direction and measure progress and might follow the processes described in Radical Focus.

Over time, the amount of heartbeat and improvement work will increase, as your company becomes more established. This is because it takes some resources to keep your established revenue streams. Within IT, this means that you’re focus shifts away from finding product-market fit and building new features only, to maintaining

A lot of that maintenance would be heartbeat work and continuous improvement. You’ll struggle with your team and colleagues to fit “everything” into your OKRs. It’s not just meant for that.

So, as you scale, be mindful of how you use OKRs over time. It might be a good idea to establish Service-Level Objectives from the start, or at least make sure you can measure performance in the future. Sooner or later you’ll have a discussion on the pros and cons of fixing that piece of technical debt when your OKRs say that’s not in focus. You’ll need some metrics that say that maintenance is needed.

Advice on implementation in your organization

So, based on my experience, the following advice might be useful for teams and organizations that want to implement the OKR model:

1. Be clear on why you want to use OKRs in the first place. Hopefully, it’s not just because of the hype.
2. Connect OKRs directly to your strategy, i.e. make sure that Objectives are based on your strategy.
3. Focus on what you can measure, instead of spending lots of time discussing whether it’s the best measurement
4. Don’t fret too much about the framework, instead focus on why and how it’s useful to you and your company

Long story short: Make sure how you track work is fit for purpose. As I’ve written before: OKRs are not a silver bullet for tracking work.

Good luck!