OKR Hierarchy - Detail not Distance

OKRs are a very popular goal setting technique in startups. Despite this, they seem to either be loved or hated. In theory, they help to ensure every person, team and department is spending their time on things that help move the company towards its goals. In practice, I've seen many companies roll out layer upon layer of OKRs without ultimately making any useful progress towards their top level goals. There are plenty of reasons this can happen but the one I want to talk about here is around how goals cascade. Companies that layer OKRs well create lower level goals that are smaller and smaller pieces of the work. Companies that layer them poorly tend to use each new layer as a level of abstraction.

Firstly, its worth questioning whether cascading goals are a good idea at all. I'd argue that they are. They help to provide people in the business a more tangible link to how they can help the company achieve its goals. If your company has a goal to grow revenue to 100M ARR and you're an IC in a development team, it can be hard to understand how anything you do directly can make that happen. When goals are cascaded well your day to day work has a direct line back up to that revenue number.

It's easy to look at that example and think of the 'Draw the Owl' meme. Getting to a point where an IC can feel connected to top line revenue isn't an easy process. Despite that, it's an exercise worth doing. It can be time consuming and will likely end up feeling like you're going in circles but the work of ensuring goals cascade well is half the value. You'll learn a lot about how your teams interact and sense check minute details of your plan and its assumptions. If you get to well laid out OKRs that's a great outcome, if you don't you'll likely still be in a better place.

A question that often comes up in the process is how many levels are right. I've heard arguments that team or department level is best, others argue that you should cascade all the way down to the individual. I think the answer depends on the size of the company and your confidence in running OKRs.

If you're working in a startup things move around quickly. Setting OKRs down to the individual level for a quarter can be counter-productive. Chances are you don't have a quarter's worth of foresight about what's important other than at a very abstract level. Where I've seen this go poorly is when these OKRs are set, become irrelevant and then have no mechanism for adjustment. This slows teams down in a frustrating and bureaucratic way.

If you're working in a very large company then stopping at a department or team level can result in the same disconnect that happens when you only have top level goals. If your team or department is big you can still feel that your day to day doesn't have a connection back up to the goals.

Practically, I'd suggest you keep moving down until you feel uncomfortable committing to the goal for the quarter. You need to put trust in your managers for this to work but when you reach the point that managers feel uncomfortable committing then it's time to either workshop or stop. If you end up at a higher level than you'd like then aim to go deeper next OKR refresh.

Now lets assume you're committed to cascading goals down at least one level. How do you do that well? The best version of a cascade is breaking the goals into smaller pieces. If you look at the goals and can easily recombine them back into the higher level goal then you've done well. Each lower level goal should be a single piece of the higher level goal. Additionally, when you sum all the parts there should be no gaps. If you can't combine your lower level goals back up to your higher level goal then there's still work to be done.

If you do end up finding a gap in your lower level goals that's a good signal. You've found something important that doesn't have a natural home. Without deliberate change that portion of the goal is unlikely to happen. That also means your top level goal is now unlikely to happen. This is another reason that it's important that lower level goals are pieces of the higher level goal. If your process is more indirect these gaps can be difficult to spot.

Cementing this, the key thing to avoid is lower level goals that feel like a level of abstraction. This is easy to do by mistake. It most often happens when the goal above is naturally disconnected. You can't find a way to link your team's work to the higher level goal so you opt for something tangential. You think "well, if we do this then things are better for everyone so that connects."

In some sense, this is true. If your teams or staff get better then its likely that things will improve. On the other hand, its a lack of focus that most often plagues startups. Having people, or even a whole team, focused on work that isn't in line with the company's goals should raise some questions. Either you have picked the wrong company level goals or the team in question needs to align more with the current objectives of the company.

A question that often comes up here is whether it is relevant for all teams or staff to be involved with the OKRs. Some teams may be more 'business as usual' compared to the more aspirational feeling of the OKRs. I've got mixed views on this.

On the one hand, there is a very real need for business as usual, especially as companies grow. You can't have everyone in the business focused only on new initiatives. Someone has to process payroll and fix bugs. Given this, it can be tempting to designate that certain teams or people live outside the world of OKRs.

Personally I'm not convinced this is the right approach. You run the risk of disenfranchising teams or individuals if they feel like they're not part of the company goals. An alternative to this approach is to realise that OKRs don't encompass 100% of your requirements.

OKRs are the 'objectives' that relate to new initiatives. Things that push the envelope of last year's results to move the business forward. There should always be an assumption that there is work that happens that isn't part of an OKR. You'll need to carefully control the balance between BAU and pushing the envelope but if you structure things this way you can work to ensure everyone feels connected to the company's top level goals.

Admittedly, getting this right is very difficult. There are plenty of very reasonable sounding reasons why OKRs end up deviating from being proximal to the goals above them. Often goals are presented that are good, reasonable and worth doing but are ultimately somewhat a distraction. Time spent on those goals seems good on the surface but if you're in a startup you're more likely to fail from a lack of focus than from choosing to work on things that are objectively bad.

Teams, often driven by pain they are acutely feeling pain, will put forward goals that if completed will make their day to day better. This in general is not a bad way to pick what to work on. In the case where you have limited time or resources however – AKA all startups – it can be a fatal distraction. If you start with low level goals like this you'll end up with a mix of positive sounding goals that may not necessarily solve the top level objectives.

Saying no to these goals can be difficult because they are genuine. Teams put them forward because they are feeling the pain or can see the value. If you're a founder or in senior leadership and don't set the agenda of focus you're going to have to tell people that their good ideas aren't going to be worked on. If instead you set the expectation from the start that goals need to be optimised for proximity to parent goals you can avoid some of the heartache.

Instead, as leaders, you need to set the example and the expectation that lower level goals are proximal to ones above. Each goal should sum up to the goals above, covering them completely and ideally not covering anything more. The first few rounds of this may feel like a chore but eventually people will be in the rhythm.

Sadly, you're never quite off the hook when it comes to reminding and reinforcing this. It's easy to fall back into setting goals that seem good but are multiple steps away. This is especially true as you add more layers. While you can enforce this fairly well at the top, if you expect goals to continue to be set all the way down to individuals you will need to check in and make sure the trend continues.

To that end, it can be useful to limit how far down you go. Each additional layer is more work to review, monitor and update these goals. As a rough rule of thumb you can probably get away with one layer per order of magnitude of staff you have. The first ten people don't need more than the top level goals, the first one hundred can deal with two layers and so on.

There's an additional benefit to breaking goals down this way in that reporting becomes simpler. When each sub-level goal is a clear part of the goal above you limit the number of things you need to report on. People reporting at lower levels naturally add to the reporting of the layers above. From experience, reporting on OKRs is an area that often leads to their failure.

The work in reporting means that they only get looked at right before the next reporting interval, meaning they're not really being used. If they're not really being used then they're probably more effort than they're worth.

Overall, I still think OKRs can be a great mechanism to align teams. If done well they let teams run on their own while ensuring everyone is running in the same direction. There are, however, plenty of ways to 'do OKRs' that don't really provide the value they promised.