When Rick Klau, formerly of Google Ventures, left Big Tech for a role in California state government, he brought OKRs to the new team. One crucial conversation surfaced a big misunderstanding. Learn how OKRs helped the leaders get buy-in from the team and instilled the confidence to take bigger swings.
The Objective was clear. The Key Results were also clear. The date by which the most important Objective needed to be completed? That was very clear. “It was circled on the calendar — and circled again,” says Rick Klau, who was then California’s Chief Technology Innovation Officer. Klau had recently joined the state government’s Office of Enterprise Technology from Google Ventures and introduced the team to the concept of OKRs.
This first Objective was to migrate the state’s many websites to one platform — more specifically, relaunching 3-4 of the 70+ sites by the end of that quarter. “Literally the first week I joined, somebody spent an hour giving me the backstory on the various attempts at standardizing the hosting of these sites,” says Klau. “So we all knew this Objective was important — and we knew it was going to be technically hard.”
Klau also learned that the biggest challenge was probably going to be sticking to the March deadline. New priorities were constantly entering the queue. “If I heard it once, I heard it a thousand times,” says Klau. “‘We are firefighters. When the phone rings, we do the thing.’” On the one hand, the ability to respond quickly was great. On the other, firefighting didn’t allow employees to say no to last-minute requests. That was just one reason Klau and his deputy, Phoebe Peronto, had committed to implementing the OKR process. It would enable the staff to focus on meaningful longer-term goals — especially the migration that future improvements would depend on.
Leveraging a lesson from Larry Page
Cut to six weeks later: The web team’s lead had been called away for a family emergency and Klau had joined their weekly check in. A staffer explained when they looked under the hood, the team had discovered a bunch of unexpected problems to address before the migration. This wasn’t a huge surprise — dealing with legacy technology always involves hiccups. So, they said, the first site would not go live until June. Without raising an eyebrow, the team moved on to the next agenda item.
But Klau’s eyebrow raised. June was not this quarter — it was the end of the following. The organization was new to OKRs, sure, but hadn’t they all made a commitment to March? It was only February, and the team was abandoning a key tenet of the OKR process: If an OKR is in danger of failing, we commit to prioritizing a “rescue plan.”
Klau says that the team’s assumption that an Objective could be postponed without any rigorous discussion revealed that the OKR process hadn’t fully taken root. The reason why became clear: Klau and the team had different ideas of what a commitment to the goal meant. “In January, I heard that we were going to do everything we could to deliver,” Klau says. During the team check-in, he realized the team had heard something different (i.e., “If everything goes right, we can deliver…”). When the staff discovered a host of not-right things, they made the decision to push back the launch. For them, it was a no-brainer.
Klau found himself in the middle of a pivotal conversation. He was the new guy, filling in on someone else’s team. He knew he couldn’t be a top-down boss, because the success of OKRs depends on bottom-up adoption. But he also knew they had to make a big shift — away from working a problem incrementally forward to working backward from their goal.
When the group outlined what needed to be done, it was clear they weren’t wrong to push the deadline — the new tasks did significantly increase the scope of work. But that was more like typical project management, not the true discipline of OKRs.
Klau remembered the time he’d been in the same position at Google. He was mapping out a timeline for a major YouTube project for Google co-founder Larry Page. “Larry said, ‘I love that you’re going to do this, but you’ll have three months to do it,’” says Klau. “My engineers had told me it would take six — and they weren’t sandbagging.” When Klau began to explain the challenges, Page made clear he understood how hard, messy, and complicated the project was. Then, he asked one simple question: “What would have to be true to change your estimate of when you can deliver?”
OKRs help teams lead themselves
Klau now asked the same of his team and then asked what beliefs were they holding that were the biggest roadblocks? The team quickly zeroed in on one assumption: There were only a handful of staff available — the four or five on the project — and those folks couldn’t possibly do all this work. If nothing changed, the team was absolutely right.
“Phoebe and I said, ‘You may be right, but we’re not willing to give up on the commitment, just because we have new news.’” So, they asked the team to consider another perspective: What did they need if they absolutely had to deliver by the end of the quarter?
“What if there were more people?” asked Klau. The team realized they’d assumed finding more resources meant finding more dollars or more headcount. “And that was what unlocked the ‘we as a team,’” said Klau. “This project was one of [our] most important things. So if we go to the engineering team, and we ask them for their help, I’m going to be thrilled if they prioritize things on their list to free up people to meaningfully add to your capacity.”
Then Klau and Peronto stepped out of the process. “What was more important at this particular moment was that the team learned how to talk to itself without us in the room,” Klau says. The staff worked through knotty topics such as: “What can our engineering team take on?” or “Could the vendor offer solutions for some of these items?” With OKRs as a framework, the team could identify solutions more effectively and quickly. As they re-negotiated resources to serve their shared priorities, everyone began to understand the power of the OKR process.
Using OKRs to “de-politicize” conversations
To be frank, this wasn’t how teams usually collaborated. Anyone who’s ever lived through a budget deathmatch knows what that can lead to: people equating resources with their team’s value (e.g., the web team is more special than engineering, because they get more people or more time).
“With OKRs, there’s a shared understanding that these are the few things we actually all care about,” says Klau. “Without that framework, the conversation just becomes horse-trading.” Instead, this team was creating agreement about what the most crucial tasks were and collaborating to assign resources and support them, no matter whose “team” it fell under.
Unfortunately, even after the initial round of discussions, the math still did not add up. The March deadline was at risk. “I vividly remember the spreadsheet of what was needed to match environment-for-environment,” says Klau. But no one was ready to give up on the commitment. To untie the knot, Klau asked for each line item to be supported with data, explaining to the team: “That tells us how important it is. I’m not going to second guess your engineering decisions — you all are the experts — but if you tell me that particular plug-in is used eight times a quarter, I don’t think that should hold us up.”
This data-focused approach allowed the team to surface more hidden assumptions — for instance, an engineer would very reasonably say, “No, we can’t do it, because that plug in will throw eight error messages over three months.” Together the group weighed the cost-benefit, making informed decisions on whether it made more sense to launch on time (with a few users getting an error) or hold up the migration of the high profile, high traffic, or high impact sites at the top of their list.
Within two weeks, the team had identified the most important tasks, shifted priorities in service of their common goal, and course-corrected to keep the migration on schedule. They even realized they didn’t need more engineers. Simply re-evaluating critical and non-critical functions, and eliciting help from the vendor, opened up enough capacity to get the first set of sites across the finish line on time. Thanks to the OKR process, the team was orienting to the right questions, and that’s what truly freed up the resources they needed.
In retrospect, Klau says the talking-past-each-other conversation was not the disaster it had first appeared to be. Instead, it demonstrated two different mindsets: incrementally delivering a project or working backwards from an outcome. After launching the first set of sites on time, they reached 20 more before their original “push-back date” in June. The experience of an early win helped build momentum — shifting perspectives in favor of working from backwards from the desired outcome. In a parallel universe — the one where the team worked from an incremental mindset — only one site would have been live by June.
“The team saw that we actually did the thing we promised, and all hell didn’t break loose,” says Klau. These quick wins were especially powerful and created a positive feedback loop. The team built momentum and gained a degree of confidence to take on increasingly bigger swings. That led to a dramatic acceleration in how quickly they migrated additional sites and a radical decrease of the time between identifying an issue and resolving it. “It was pretty great when you could see them lean into that and get excited about the process,” says Klau.
Thanks to OKRs, he says, “They had started to see what they were capable of.”