Specifically here the fixed-ness of Objectives and friction in changing Key Results. These are the stable business-centric goals that should NOT be schizophrenically changing after the last customer meeting or if the CEO has some genius new strategic lightbulb moment.
Sten does a great job framing these 3 levels, starting with these statements:
Related to impact you have on your customers.
and
Teams can double-down on projects that work
Objectives
The way you phrase the top-level objective has the potential to kill or inspire teams to launch projects to meet that objective – afterall people/teams naturally obsess over such a concise directive.
Bad example: “integrate with Stripe” – only related to dev team – can’t help Sales/Marketing get on with their work. The Key Result is also very binary: “Ship or Not Ship”.
Better Objective: Get Paid Customers. This empowers each team to flush out their own Projects:
Product: find a way to charge them (that might still be Stripe but it is in concert with other possibilities and team Projects)
Sales: what markets can I tackle?
Marketing: what initiatives will drive growth?
Support: how can we reduce churn or convert trial to paid?
Moving down to Key Results –Â these “really focuses the attention of people on what is important”. A sensible selection is not the binary Stripe result but Revenue. Suddenly things are quantitative and not binary – its more trackable.
In the bad example: The Product team say “we really need to ship that integration”.
In the good example: Marketing can get great progress by surveying customers on purchase intent. The big contrast here is that waiting 2 months for the Stripe integration won’t move the needle if there is NO purchase intent.
So the Stripe integration is downgraded to a Project. If that project looks like it will fail or run over the 90 period – the better OKR helps teams ask: “how can we charge people today?”, “can we do it manually” etc.
Bad OKRs can derail a company. Good OKRs align teams in achieving one big thing for the business.