This post appeared on my free bi-monthly newsletter. You should sign up here and join 40k other readers.
In Part 1 of this series on scaling OKRs, we declared that strategy was the foundation for writing org-wide OKRs. In Part 2 we talked about how to extract an initial set of strategic OKRs from that now–widely understood and well-articulated strategy.
As we start to think about OKRs across the organization, in all likelihood our anxiety levels start to rise. Change is scary. And risky! Change at scale? Just thinking about the myriad of ways it can go wrong is enough to drive many companies to give up. The ironic thing about any kind of change at scale is that starting small, rather than with a broad company-wide rollout, helps us identify—and smooth out—the obstacles to scaling.
Start with one team
But we have 500 teams! I know. If you try to change all 500 of them “overnight,” you’ll end up with a situation like Sweden found itself in back in 1967 when they switched from driving on the left side of the road to the right side:
Kungsgatan in Stockholm on Dagen H. (Source: RealScandinavia.com)
The intention is good, but the transition is a disaster. As with any new idea, it will be interpreted differently by each team. This will cause conflict, chaos and probably a few tears. Instead, start small. Start with just one team. Keep that team small—no more than 12 people. Assign that team one specific objective and no more than 3 key results they helped determine. Give them a relatively short timebox (8-12 weeks). Then, give them all the support they need to make OKRs successful in their specific context.
This team will function like a minesweeper. They will find all the organizational “landmines” that will make deploying OKRs at scale difficult. They’ll run up against managers demanding linear planning and roadmaps. They’ll meet customers who want to know exactly what features are coming. They’ll likely get a call or two to the CFO’s office to discuss the “ROI” of their work.
This is all data. It’s a way for us to see what a broader rollout will struggle with. If we can figure out how to deal with the issues that come up for one team, we can start to think about dealing with it for 10, 20 and, eventually, 100 teams.
Essentially, we are running a process experiment. This “pilot team” is a way for us to mitigate the risk of a broad rollout. It’s “the smallest thing we can do” to test our hypothesis that OKRs will help our organization. We timebox the experiment and set explicit success criteria. We learn from this pilot team how to best staff for OKRs, support the process and adjust our organizational systems, and even our organizational design, for a future where multiple teams are working towards these human-centric goals.
Tip: Keep the experiment transparent
A few years ago I worked with a mid-level manager who had finally won over his leadership to build a cross-functional team that worked towards OKRs. They agreed to fly in team members from all over the world for one week. That’s all they had. He was excited. The team flew in and holed up in a conference room (aka “the war room”) for a week, collaborating, iterating and making progress on their initiative.
At the end of the week, the team emerged, triumphant, from the conference room with a huge “Tada! Look what we did!” type of fanfare only to be met with skepticism, disbelief and ultimately rejection of their ideas.
Why did this happen? No one else in the organization saw the process. They didn’t see how they got to this point. For all they knew they just made it up over the course of the week. My client was not only dejected, he actually received a negative review that quarter for a LACK of collaboration.
The moral of the story here is to ensure your pilot effort is visible to everyone. Err on the side of radical transparency. Over communicate. Don’t wait to be asked. Tell everyone what the team is doing and what the progress is. If you’re in the office, put the team in a central location everyone can see. Post updates regularly through comms channels. In short, show your work, regardless of whether it’s good, bad or otherwise. Make the process and the experiment obvious to everyone.
Stack the deck
Finally, as you decide who to put on this pilot team, consider stacking the deck. In other words, put your best players on this team. The goal is for this to succeed. You want to put your best folks on this challenge. If anyone can make this work, it’s them.
This isn’t cheating. This is setting yourselves up for the best chance of success. You want to show the organization the best aspects of this new way of working. At the same time, this crew of top players is identifying the processes, bureaucracy and systems that hinder their success. Their feedback will help simplify those things for future teams transitioning to OKRs.
Rolling out a new goal-setting framework to an entire organization is hard work and puts a lot at risk. Mitigate that risk by starting small. Prove the model with one team. Understand how to make 2 teams successful. Then start scaling to 5, 10 and beyond. Eventually everyone will be on board, and the organization will be ready to support all of them.