jtbd
okrs
goals
Objectives, Key Results - valuable tool or overcomplicated theater?
OKRs have become a staple with companies that shifted to the Product Model. The past few years have seen the development of OKR Consultants.
Between these two parties, OKRs have become too complicated with a hefty amount of product theater to boot.
We've seen three key pitfalls with how companies and consultants alike have taken a simple tool and overcomplicated them.
- Cascading OKRs, probably the biggest overcomplication
- Key results that aren't meaningful - vanity metrics
- Heavyweight process and theatrics around the OKR cycle
Cascading OKRs
While good intentioned, having cascading OKRs that start at the top and products and portfolios needing to ladder up to them is a signification burden to leadership and teams.
We all want to create value.
- First and foremost, at the top level, leaders should set the content for a broader timeline than a quarter.
- Poor product and team definitions reinforce a focus on delivery
- Teams spend precious time each and every cycle creating a story to ladder up to the top level OKRs
This should be a no-brainer, but it's a very common anti-pattern, top level product leadership creates OKRs on the same cycle as products and portfolios.
If these were truly strategic outcomes they are focusing on, they tend to be broken down into delivery focused Key Results.
It's certainly possible to look at incremental improvement, to want to improve a metric by single-digit percentage.
But this misses the point of using OKRs.
OKRs are intended to be used to create step-level change, not incremental change.
We're using the wrong tool for the wrong job, a hammer to pound in a screw.
Depending on the corporate strategy cycle which could be 1,3, or 5 years, the product strategy cycle should ideally focus on 1 year.
Product leaders can work with the executives to support the 3 to 5 year strategy cycle, while creating clarity for products and portfolios that is broad and ambitious enough by setting OKRs annually.
Products and portfolios then can look quarterly with their OKRs while thinking strategically on how to support the annual OKRs.
For product leaders, you should then expect product and portfolio leaders to think broadly on how this quarter fits with a broader annual focus.
(This is an opportunity for talent assessment and development.)
But what if the broader strategies change at some point?
Then change them, and ask the teams to determine the impact to their OKRs.
If top level OKRs are truly strategic, outcome oriented, there shouldn't be much change.
If they are tactical and delivery focused, that's possible there is a lot of change.
But you also aren't really doing strategic OKRs either.
Poor product and team definitions reinforce a focus on delivery
It's a common anti-pattern for product (or engineering) leaders create products and portfolios around "things" instead of anchoring to customer value.
A customer-centric approach is to organize teams around the Jobs-to-be-Done and assign a portfolio-level product leader to own a particular Job.
From an engineering perspective, this requires an 'inner source' working model where teams have open repos. (More on this later.)
What each portfolio will then need to understand is who the customer is and what is their Job-to-be-Done.
They need to understand how the customer measure progress on the Job AND be able to relate that back to how the company makes money.
The product portfolio leader needs to have a set of leading and lagging metrics.
From there the product teams within the portfolio can be defined.
Since this work isn't often done, teams will use 'engagement' and other vanity metrics to prioritize and gauge success against.
Heavy weight process and theatrics around the OKR cycle
OKRs are a tool to help the team, portfolio and organization to determine progress against broader goals.
They should be thought of milestones on the way to a 10x organization goal/outcome.
Use them to troubleshoot, not to punish.
Too often, at the end of the OKR cycle, there's a 'scoring' ceremony to determine what teams met or didn't their OKRs.
If our OKRs are meant to be achieved, versus going after a 10x outcome, how is this helping the team(s), and by proxy the organization make progress on meaningful organizational goals?
It's not. It's pure theater, it's about process and fake 'accountability'.
Teams therefore sandbag OKRs to what they know they can deliver each OKR.
Ultimately, this causes mediocre results and poor organizational performance.
This causes teams to focus on delivery OKRs. Not the right culture, mindset, and tool for delivery.
All this theater has spawned the need for 'OKR Coaches'.
More process, more waste.
The slippery slope to mediocrity.
What to do?
Anchor to what OKRs were intended to be: a tool to help focus teams/portfolio/organizations on 10x outcomes.
This requires empowerment of portfolios and teams to build a strategy and how to execute toward the broader organizational outcomes.
Empowerment is a buzzword that most organizations do NOT have as part of their culture.
This takes leadership to change and model new behaviors, which takes time and effort.
Don't accept 'accomplishment OKRs' these are the fastest path to delivery focus and mediocrity.
Look at adopting a cohesive, holistic Product Operating Model and not just a 'bolt on' of tools that a vendor said to.