The real problem is setting "hard but not so hard as to be impossible" goals at any level is really more of an art than a science. If leadership has a strong vision and their finger on the pulse - OKRs will work great, as will any other framework (eg. simply sending an email to everyone stating that the goal is X by Y date). If nobody has any clue what they're trying to accomplish and no shared vision - following the OKR method won't save you.
Making goals hard is a case of sloppy thinking. There is no reason to believe hard work is a money maker in software, or that teams working harder leads to more money. Software is mostly a communication and coordination problem; there are lots of dysfunctional software companies and it is rare that the cause is people choosing easy problems. Usually it seems to be key managers believing things that are not true.
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.
Achievable and valuable definitely more valuable than hard. I do suggest it's healthy not to 100% know how you might achieve the goal over the period - its good to be open to options and look for evidence you are making progress. I think this is different than trying for a moonshot every quarter :)
>"hard but not so hard as to be impossible" goals at any level is really more of an art than a science
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 :)
This article feels very "business book of the week" to me. It's a laundry list of changes you can make so you as a manager can feel like you're doing something but there's absolutely no evidence whatsoever that any of them will improve anything. It's just "here's what the leading thinkers on OKRs are doing". What makes them the leading thinkers? Why is this good? What's the evidence that works?
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.
I haven't yet seen an organization that benefited from OKRs. I'm not saying they don't work, I've just never witnessed them working.
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.
Management should communicate at a high level the direction the company is going in and why. They need to set a vision, explain why it's good, then break that down into larger targets. Workers underneath management should come up with specific ideas for meeting those targets. They should all meet and then align on the specific ideas to implement.
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.
Might be semantics as the changes I describe are fairly substantial compared to how many companies implement them. I did think of not calling it OKRs anymore at the time but the effort to rebrand it internally didn't seem worth the payoff. I like your suggestions - anything that increases clarity, alignment and debate. If a team wanted to align based on a memo or other doc we could debate I'd go for that as an alternative to OKRs. Documenting what you tried, what worked and why and what you intend to do makes sense to me!
> Set high level goals for the company (e.g. revenue, customer acquisition and employee retention).
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.
I think they are different. They’re simply targets for your business, the way it’s been done way before OKRs we’re a thing (e.g. target revenue for the year is $20M, churn should be brought to 5%). OKRs have a methodology and format attached to them and tend to trickle down multiple level in the organization.
There isn't really one way to do OKRs - you can read a dozen different descriptions and have a dozen variations. It's not a formal methodology but rather an approach that for a long time was passed around organically based on some key adjustments to MBO (Manage By Objectives) which came before it.
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.
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.
input = available expendable resources?
output = created resources?
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.
Not the OP, but to me inputs would either be leading indicators or something like “shoot 1000 3-pointer/ every day” and not “get an NBA championship ring”.
I've experienced several variations of this at different companies. It's never mattered as far as I can tell.
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.
Almost every experience with OKR’s has been an unmitigated dumpster fire.
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.
Bad leadership will make a meal of any approach to work, its true. OKRs are not easy - they take good leadership, discipline and a culture which is open to feedback and committed to learning and adapting to what it learns. I wouldn't even say OKRs is the best way to work this way, just the most popular (hence why I wrote about the complimentary things we paired with it).
They just feel like “busywork for objective setting”.
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.
You can do things the hard way and build a good product, or take shortcuts and build a not-so-good product. Most OKRs encourage leadership to take shortcuts and be cheaper (AKA more efficient). You can improve OKRs as much as you want, but most companies benefit more from problem solving than number chasing.
Our startup recently started using OKRs and gotta say, I'm not a fan. OKRs were set to be quarterly objects, but things move fast and priorities change. What once was important 2 months ago is now irrelevant.
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.
How some tool providers describe OKRs it can be over-engineered I agree. You need to adapt tonyour context. E.g. startups can use OKRs but should be very lean about it. OKRs aren't really a framework - there's not lots of things you must do.
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.
Can someone explain the leading and lagging indicator in this paragraph?
> 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 leading indicator predicts something about the future, e.g. an OKR of cutting spend predicts that you will indeed cut spend. When you set a new OKR it will take a while before it shows results—it leafs ahead of them.
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.
This is very interesting. This is similar to how Big Tech runs tech projects in a vastly different way than the “good practices” for agile/scrum commonly adopted by the industry at large.
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. :)
Never seen cascading work either. Just ends up in endless wasted time formulating 5th level deep okrs, that become so specific they are quickly irrelevant as the organization changes and pivots over the year.
No one should be writing OKRs that deep. If your organization has five levels, the fifth level should be writing their own top level OKRs. They don’t take that long unless the company is critically indecisive. They’re for companies that are capable of executing and need to focus or change directions.
Agreed, the only time I ever saw OKRs work in my professional life was a (sadly) brief ~6 month period during which cascading OKRs were strictly enforced from CEO down.
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)
