As a system, OKRs can be flexible. We encourage every organization to adapt them to make them work for their industry, culture, and pace. From our work at WhatMatters.com, we've seen how different organizations tailor this goal-setting system to get that collective commitment and steer their organization. There's a handful of choices you can make, and I'm going to share what they are and explain how they affect one another. Right now, you have to make three major decisions: First, how many layers of your organization creates OKRs? Then how many OKRs at each layer should we be aiming for? Then we have to decide the cadence. In this course, we often talk about the layers of an organization as the organization itself, the departments, its teams, and individual. Your organization needs to decide how many of those layers should be creating OKRs. As you may have heard, Google has OKRs all the way down to the individual contributor. Allbirds, another successful OKR user, only has one set for the whole organization. Our advice is, if you're starting out, try them out at your level. That means if you're an executive taking this course, do it at the organizational level. If you're department leads, start there. If you manage a team, start there, or if you're solo, craft them for yourself. Once you've gotten through a cycle or two, you can start to add more layers when it feels right. What do I mean by "if it feels right?" Well, if you're a startup and it's just the five of you, you probably can fit your entire organization's goals on a single sheet of paper. You're going to have two to three OKRs and you'll likely see everyone's names attached as an owner to a handful of those Key Results. In this, creating OKRs for departments and teams probably doesn't quite make sense, especially since whole departments are just one person. But as you grow, you're going to feel this natural tension and urge to add another layer. You really want people to see themselves and be an owner of a handful of Key Results. If you're a large organization with more than 10,000 people, when you start out, it helps to model great OKRs at the top. It also reduces the pressure of getting that massive buy-in before rolling out OKRs to everyone. Do them well at the top. Show how they're guiding the organization's strategy. Use them in staff meetings and continue it again and again. I guarantee a handful of departments will try to mimic what you're doing, and they're going to start setting OKRs themselves. When you're ready to include another layer, it's going to feel so natural. Remember, when OKRs were introduced to Google by John, they only had 30 people. Today, Alphabet has over 100,000 employees. At every stage of their growth, they used OKRs. But what that also means is that every layer of their organization, they have people who know how to make OKRs work for them. When a new VP gets hired or a new salesperson gets hired, they can lean on 100,000 other people to teach them how it works for them. As OKRs travel through an organization, it's possible to inherit a Key Result from somewhere else in the organization. That Key Result is now your Objective. Once you've decided on the layers, it's time to decide how many OKRs each layer should create. Should teams have one, two, three, or even five OKRs? Or should they only be creating Objectives for the Key Results they inherit? If you only led a team create Objectives for the Key Results they inherit, you're going to have a pretty rigid OKR system. A crisis may demand that, if your organization is facing uncertainty or you're trying to right the ship, you may set top-level OKRs that get strictly cascaded through the organization. What we see more often is that every layer inherits one or two goals and is encouraged to create a few more themselves. This flexibility allows each team to express what they see as important priorities, really empowering bottom-up thinking. In moments of growth or exploration, you really want teams to be identifying their own priorities and opportunities. You can do this by setting fewer top-level OKRs and encouraging teams to create their own OKRs that are not explicitly inherited. But remember, encouraging too many OKRs to each layer can be overwhelming too. OKRs are meant to capture the most important priorities, not everything. Now that you know how many layers will be using OKRs and how many they should be creating, you can decide the cadence. The most popular cadence for OKRs is quarterly. Our team encourages you to pick the cadence that works best for your organization. Because at the end of every cycle, your organization is going to learn something very valuable from scoring and reflecting on your OKRs. Those learnings help your team be nimble and set a strong recourse for the future. We find that some startups want that cadence to be quicker. They pick every six weeks or even every month because they can't wait for a whole quarter to learn what goals they achieved or missed. We once worked with a major league baseball team and they split their year into four: the pre-season, two cycles during the season, and then one for the post. This allowed the end of each of those cycles to influence the next. At Kleiner, where I work, we decided on trimesters, because it made sense for us to approach the year as the start, the middle, and then everything we need to get done before the end. In addition to picking a good cadence for your organization, we also recommend you set a top-level organization-wide goal, one that looks a year out. We're going to dig into that more in the next lesson. To recap, you get to choose how many layers create OKRs. You then get to guide each layer on how many OKRs they should be creating. Finally, you get to set the cadence that keeps your organization moving.