I spent a good part of my career in the Continuous Integration (CI) and Continuous Delivery (CD) space (g'day Atlassian Bamboo, hello Bitbucket Pipelines 👋). One thing that was clear to me when we built Tability is that we'd have to borrow some ideas from Engineering to solve the OKRs problem.
I highly recommend Christina Wodtke's book, Radical Focus, as it illustrates one of the common pitfalls of OKRs: people forget.
Here's how the story goes. A team has grown past the point where the founders can keep track of everything. They start looking for a better way to organize work. They hear/read about OKRs. They love it! They define the first set of OKRs, put it all in a spreadsheet. Everyone is excited. They start working on the top priorities.
A month later: no one can remember what the OKRs were, and folks are going in different directions again. They put all their efforts into planning and forgot to define a way to track progress.
Work is paradoxically a powerful generator of distractions. Every project seems to be growing a set of extra features, becoming a giant squid holding the team hostage. Every week is producing dozens of calls, hundreds of emails, taking your attention away from your main priorities. Every task has its own unknown unknows taking you down the rabbit hole.
So, coming back to our OKRs, they're doomed to fail unless we have some sort of framework in place to support them. Not because the team won't care, but because the team won't have the time to think about it — unless we push it back to them.
Here's a definition of Continuous Integration taken from Martin Fowler's website.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Right — this is super tech-centric. So this is not so much about enabling CI in your spreadsheets but more about understanding why it's a popular approach to software development.
Product teams around the world have adopted CI/CD because they realized that fast iterations produce much better results than doing some grandiose planning with a waterfall approach to delivery. Checking progress early and often reduces the cost of being wrong and allows you to validate your direction by getting feedback from your customers.
Things get even more interesting when you look at the 5 principles of Continuous Delivery published by Jez Humble:
I absolutely believe that you can and should apply these principle to the OKRs process.
"It's much cheaper to fix problems and defects if we find them immediately"
Don't wait until the end of the quarter to realize that one of your Key Results has gone off-track. A daily rhythm for OKRs is too much, but you should check progress on your Key Results every week (ideally a Monday to refresh things after the weekend). Get on top of every KR that has been in the red for more than 2 weeks.
"It reduces the time it takes to get feedback on our work, makes it easier to triage and remediate problems, increases efficiency and motivation, and prevents us from succumbing to the sunk cost fallacy."
Phrases like "we can't track progress before next month" are red flags. The work done to make progress on the Key Results should start producing an impact in a matter of weeks and not months. Don't go for big bangs. Do your best to get incremental progress through the quarter.
"The goal is for computers to perform simple, repetitive tasks, such as regression testing, so that humans can focus on problem-solving"
This one is a cautionary tale against too much automation with OKRs. I've seen cases where teams wanted progress on Key Results to be automatically updated via scripts or integrations, without any human intervention.
This kills the benefits of OKRs as you lose the problem-solving part. The value of OKRs comes from (1) people being reminded of the top priorities, and (2) people actively thinking about the gap between where they are and where they're supposed to be.
Full OKRs automation removes the human touch. Computers should help you collect the data, but only your team can interpret it and use it to make critical decisions.
"Don't treat transformation as a project to be embarked on and then completed so we can return to business as usual."
I think OKRs suffer a bit from their history. It's a process that is often associated with C-suite and large companies, and it sounds a lot like strategy jargon. That can make it a hard sell for some teams that take it as a different way to do micro-management (and sometimes they're right!).
OKRs should empower teams and encourage bottom-up innovation — but you need to have the right culture. It means creating space for people to try and fail, and it means investing in the right tools and processes to let your team grow.
"Everyone works together to achieve the organizational level goals, rather than optimizing for what's best for their team or department."
OKRs are first and foremost about alignment. The goal is to create a shared North Star and define a common language to describe what success looks like.
This is also why OKRs should be team-based rather than people-based. It's about doing what's best for the customers and the business, not what's good for each member of the organization.
In a normal Continuous Delivery flow you'd want code to be integrated every day. That's going to be too much for OKRs, and a weekly cadence is more than enough.
Update progress on Key Results on Monday, then let the team focus on work during the week. They'll have the right context in mind and should be able to make a dent for the next OKRs meeting.
You need a simple way to understand when things are getting off-track. In software it happens when the build goes red. You can get similar results by using traffic lights to indicate your confidence level for each of the Key Results.
Make sure to keep the history of your checkins! Don't replace existing values in your spreadsheet as it'll prevent you from seeing trends.
Avoid binary Key Results (it's shipped/not shipped) or vague statement (users love our product). If you want your team to be effective, you'll need to have concrete ways to measure progress.
Continuous Integration requires the build to be fixed as soon as it's broken. Things have to be a bit more lenient with OKRs as progress can fluctuate, but I'd recommend having a serious chat on the 3rd red update.
It won't always be about getting the team to drop everything to focus on one goal. Sometimes you'll realize that perhaps you were too ambitious, or it was the wrong KR to begin with. But — you must have that discussion to get everyone on the same page.
Continuous Delivery is only possible if deploying code to production is a breeze. Same goes for updating the OKRs.
If it feels like a chore or takes people hours to update their KRs, then they'll stop doing it. And if they stop updating their KRs, then they'll soon forget about them. You'd be back to square one.
Of course, this is the end of the article where I tell you that we built Tability precisely for that purpose. Anyway, give it a try, it's free and you get unlimited users on every plan!
Startups need to be focused and flexible. OKRs can help a lot with the former, but they'll quickly stiffen your team if you start cascading your goals.
You can't just throw OKRs in a spreadsheet and expect your team to be outcome-driven. You need first to get the right culture to create an environment where teams can iterate to reach their goals.
You need to focus on value rather than deadlines for OKRs to be successful. Adopting a Now, Next, Later format for your roadmaps is a simple way to achieve that.