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.
Wait, what's the problem with OKRs?
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.
Out of sight, out of mind.
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.
CI/CD principles to the rescue
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:
- Build quality in
- Work in small batches
- Computers perform repetitive tasks, people solve problems
- Relentlessly pursue continuous improvement
- Everyone is responsible
I absolutely believe that you can and should apply these principle to the OKRs process.
The 5 principles of OKRs
Build quality in
"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.
Work in small batches
"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.
Computers perform repetitive tasks, people solve problems
"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.
Relentlessly pursue continuous improvement
"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 is responsible
"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.
What it means in practice
Check progress every week
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.
Use red/yellow/green statuses to indicate your confidence levels
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.
Make your KRs measurable
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.
- It's shipped -> We go from 0 to 350 weekly active users
- Users love our product -> We increase our NPS from 20 to 60
3 reds = all hands on deck
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.
Keep it light!
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.
.png)
.jpg)
(1).jpg)
.jpg){kind=spacer}
.jpg){kind=spacer}
