Improving OKRs
wioota.substack.com
wioota.substack.com
OKRs should be achievable and valuable. It is acceptable if they are hard, but that is an unfortunate source of risk and it is better if they are easy to achieve for everyone. You don't want to be in a position where success relies on hard work, great strategy is about achieving an embarrassing amount of success with ordinary everyday efforts that were always going to work out well.
I actually quite like the article because it doesn't seem to be promoting that sort of "goals should be hard" thinking for OKRs.
back then a woman in USSR army, a low level commander, when I asked about how she manages to maintain her authority in those conditions explained to me that you do have to run your soldiers hard, yet giving impossible to complete order is the fastest and surest way to lose respect of your soldiers and as result to lose real authority over them, and to walk that fine line the key thing is to truely know your stuff (they were some very technical radar service department).
I do live by her words - the fist thing I determine about my superiors is whether they know the stuff, and thus how much respect, if any, I should give to them and to their orders :)
Some of these are cultural such as it being safe to give feedback and a propensity to act on what is learnt.
The ability to capture and update the persistent model I mentioned in the post requires the leadership to be aligned on the direction.
Here's the number one thing I've seen at every institution that I've been at that uses OKRs (or V2MOMs which is salesforces method which I'm even less of a fan of for various reasons). You do a bunch of work planning, getting everyone on the same page on the OKRs for the quarter and within a week or two something comes along and changes everything deus ex machina and your plan is basically irrelevant and you're doing the new thing working on the hoof with no real plan. Mike Tyson's famous words "Everyone has a plan until they get punched in the mouth" really resonate with anyone who's worked in a startup.
Then you get to your quarterly retro and you've done at least one maybe two reorgs/pivots since the OKRs and you look back on them and they all fall into three buckets:
- About a third "yeah we did that"
- About a third "everything changed so that wasn't relevant any more"
- About a third "what on earth were we thinking?"
The reason for this is you aren't doing something where the scope of effort and the domain are really well understood. You're not digging a trench or making plastic spoons. You're trying to build a software business in response to a shifting marketplace and an ambiguous and often hard problem.
The activity of planning is useful for getting everyone on the same page, taking some time to think about what's important etc, but the plan itself ends up victim to circumstances every single time. It's just an example of the Eisenhower maxim that plans are worthless but planning is everything.[1] As such it just seems pretty pointless to focus on optimising the OKRs themselves in any meaningful way. The process is the valuable part.
What you're describing is reality but the thing is, once you've got enough bureaucracy, reality takes a back seat.
My main gripes with them:
- They focus on output, and I believe most organization (especially startups) should focus on input. In that regard, I'd spend more time figuring out your internal playbook rather than measuring the (invariably too many) goals you've set for yourself and your team at the beginning of the quarter.
- The don't reflect reality. As soon as you set measurable outcomes for anything beyond the hard success metrics (e.g. revenue, profit, churn, CAC...), expect people to try and game the system. This leads to either people hitting the numbers but missing the mark, or simply failing to report accurately.
- They're mostly useful for underperformers. I have the same feeling about 1:1s. Your top performers usually don't need OKRs to know what needs to be done or how well they're performing. This ends up being a lot of busywork, especially for those who want to get sh*t done.
I wouldn't "improve" OKRs. I'd drop them:
- Set high level goals for the company (e.g. revenue, customer acquisition and employee retention).
- Have leadership set TODOs for the company and teams, BUT use this mostly as a way to foster debate and alignment on what needs to be done. Expect them to change often.
- Focus on your inputs. And on that topic, I would invest in building a culture of documenting what you do and how you do it (for example through a playbook). You can't build on quicksand.
Same. But, I think it's a symptom of a bigger problem: lack of coherent strategy. And, I think a lot of companies suffer from this.
So OKRs frequently act as a suboptimal stand-in for strategy. This, instead of flowing from sound strategy and concrete tactics.
I'm not sure how well they'd work even if that was in place. But, without it, they don't stand a chance.
I think this doesn't happen because explaining why you're going in a certain direction is hard. Most startups don't really know if the direction they are going is correct and are just trying a bunch of things. This doesn't lend itself to management putting themselves out there and as such, try to push some of that work out to normal employees through OKRs and trying to make them more "autonomous". At the end of the day, there's only so much under our control and the OKRs don't help.
I think the changes you are suggesting are sensible, but I would still not use OKRs.
That sounds like OKRs by another name to me. Objective 1: increase revenue. Key result 1a: achieve $X revenue this quarter. Objective 2: increase customers. Key result 2a: number of customers exceed Y by this quarter. Objective 3: increase employer retention. Key result 3a: employee attrition stays below Z% this quarter.
E.g. How Measure What Matters and Radical Focus describe OKRs - two of the most popular books on the subject - differ quite a lot.
I think finally there's some consensus that cascading OKRs is a bad practice but unfortunately people keep.doing it because that's how it was described in MWM.
We tended to have goals / OKRs per team and longer term goals they could align to. Flatter the better when possible.
Any high-level goal becomes an O. Then any measurements of that goal become separate KRs under that O. Simple as that.
Formatting goals this way has its value. A vague goal that cannot be measured with have missing KRs; so this discourages writing vague goals.
Prioritizing your work. What you are doing, why you are doing it, what’s going to be the best return on your time, what is your capacity to actually accomplish things and are you overloading yourself so that you have to rush everything constantly.
Naturally, the output is constrained by the available input. If a KR doesn't take into account the available input, then it is prone to be unrealistic.
It’s there for accountability.
But the O should be the North Star.
"OKRs have helped lead us to 10x growth, many times over." --Larry Page, in his forward to the book "Measure What Matters"
--Me, in the post above.
Managers get required to look at it as part of a some process, and inevitably find a set of goals that make no sense, as priorities have completely shifted. They then ignore it.
Where I have seen it work well are in competitive markets such as SAAS companies battling for market share.
The maturity for using measurement for decision making is higher because to do otherwise means losing marketshare quickly to a competitor. Network effects often mean regaining a leading market position is tough.
The other element is the leadership treating it very seriously. That means investing in regularly communicating the state of the company's market position and engaging in giving feedback on goals and progress and looking for ways to support the teams.
Unfortunately these are traits missing in many companies.
Leadership sets some goal, usually something insane and physically unachievable. Some inane key result -usually no closer to reality- gets set. Management and PM’s spend inordinate amounts of time and effort faffing over the metrics and relentlessly asking “why hasn’t the number gone up by 2% today????????” No attempt is made at doing any actual work, or god forbid, actually contributing.
End of quarter comes and lots of numbers and reasons are thrown around. Leadership either celebrates nothing because “if you hit it, we weren’t trying hard enough” or berates you for not hitting the objective. Another, equally improbable goal is set for the next round. Beatings continue until morale improves.
If they involved candles and a pack of tarot cards, I wouldn’t even blink.
> they take good leadership, discipline and a culture which is open to feedback and committed to learning and adapting to what it learns
Those things that are notoriously reliable and common: discipline, good leadership and a culture of adaptation. Anything _relying_ on discipline is doomed from the start.
The other difficult things about OKRs is attempting to assign metrics. Most of the stuff worked at in a startup are new and exploratory. That means there isn't a sense of what a good number for success even looks like. What happens is arbitrary, and thus meaningless, numbers are assigned to OKRs just for the sake of adding metrics.
It seems to me OKRs are over-engineered for the purposes of achieving short-term goals. There's probably a better framework for this.
The only essential is can a team align on a sentence describing what is true if the goal is achieved and 2-3 measurable items of evidence of the goal being achieved or progress towards achieving the goal.
If things change, scrap the goal and write a new one. Presumably you learnt something that invalidated the previous one. If it's because of someone else's whim you've got a different problem.
The quarterly cadence is not essential but it is often helpful to periodically know when there is a great opportunity for alignment across teams.
When timing of goal setting is inconsistent across teams it's hard to be available to each other when you need support across teams e.g. maybe one team provides a service that another team needs to achieve a goal.
> OKRs, given they typically focus on change are usually leading indicators focused on shorter time windows and KPIs, which represent the health of what the organisation seeks to sustain, are usually lagging indicators focused on longer timeframes.
A lagging indicator is the result of something that took place in the past; 99.99% uptime over the last year indicates you probably had some good practices in place (redundancy etc). If those practices were to change, it would take some time for the kpi to actually change—it lags behind.
Hours worked is an imperfect predictor of output in a factory. Widgets delivered is a late confirmer. Leading and lagging indicators for productivity.
[1] https://www.amazon.com/Disciplines-Execution-Achieving-Wildl...
e.g. https://blog.pragmaticengineer.com/project-management-at-big...
Similarly the article on OKRs describes small but critical adjustments from the OKRs cannon (Measure What Matters) that only scale-ups and Big Tech seem to know about. Everyone else too often tries to:
1. Cascade OKRs down from the top, sometimes outside Product & Engineering (in teams that are more process- than project-based like sales), killing team-level autonomy in the process.
2. Write Objectives for time consuming activities, rather than having a non-OKR work / BAU section that captures it. This makes it much harder for other teams to rely on OKRs to understand the context of what’s changing and to have key cross-team alignment conversations.
3. Focus on OKR tracking and scoring, possibly through a dedicated tool. This misses the point that the primary value of a plan is in the planning, not the deliverable, and risks making OKRs a performance management tool (at which point teams discuss KRs endlessly to sandbag rather than setting stretch goals and moving on).
But when you say the local implementation looks both overkill and misguided compared to what works at other tech shops, people point to the OKR book as what drives their own implementation. :)
Throw that away, setting aligned SMART goals would achieve a similar effect as aligned OKRs.
I suspect folks don't like that because it forces middle management to actually decide, for real, who is doing what, rather than allowing multiple different teams to fragment off chunks of what should be a whole (which then lets them both claim personal victory and deflect blame for the whole actually failing)
https://longform.asmartbear.com/survivor-bias https://ludic.mataroa.blog/blog/leadership-is-a-hell-of-a-dr...