OKRs will never be enough(edge.ceo)
edge.ceo
OKRs will never be enough
https://www.edge.ceo/p/okrs-will-never-be-enough
99 comments
All these frameworks for managing people matter much less than creating a team of quality people. Think of it like sports. Sure a good manager or coach can get the most of the players on the team. They might even add tactics and play above their level. But when it comes down to it, what matters the most in the skill set of the players. The best coaching in the world isn’t going to help me and my friends beat a pro sports team. Same thing for teams inside companies. Strategy does matter, but quality matters much more.
> The best coaching in the world isn’t going to help me and my friends beat a pro sports team
No, but a good coach will start with you team, replace single player and get slightly better results. Replace another player and get better results. Rince and repeat until you and all your friends are long gone but your team plays in the NFL.
Being able to detect, attract, nurture and retain talents is exactly what the coach is doing on a daily basis.
No, but a good coach will start with you team, replace single player and get slightly better results. Replace another player and get better results. Rince and repeat until you and all your friends are long gone but your team plays in the NFL.
Being able to detect, attract, nurture and retain talents is exactly what the coach is doing on a daily basis.
Yes but the MBA, Management Consulting, Agile Coaching industries are based on this not being true. So there will be an endless stream of propaganda to convince people otherwise.
Strategy can matter a lot.
Tactics is mostly irrelevant.
Unfortunately the latter is much easier to change so leaders like to modify it constantly to seem like they are adding value. And since it’s mostly irrelevant it’s hard to prove that this is bad.
Tactics is mostly irrelevant.
Unfortunately the latter is much easier to change so leaders like to modify it constantly to seem like they are adding value. And since it’s mostly irrelevant it’s hard to prove that this is bad.
I was using tactics and strategy interchangeably, as in the sports sense. Probably should have been more clear, but I agree with your point. Also business is much more complicated than sports, where the rules are concrete. I was just using it as an example that what matters is using the talents of the team instead of a framework for management.
In my experience you have it right but backwards: These frameworks exist to help management manage teams without quality people. Scrum/agile is exactly the same thing. The stricter and more documented the process, the more fungible actual team-members are.
That's important in places like bodyshops and non-software business where no self-respecting engineer with options would want to work, and places where monotonous quality matters more than brilliance. Keep em as far as I'm concerned.
That's important in places like bodyshops and non-software business where no self-respecting engineer with options would want to work, and places where monotonous quality matters more than brilliance. Keep em as far as I'm concerned.
> Scrum/agile is exactly the same thing. The stricter and more documented the process
The Agile manifesto specifically says "Individuals and interactions over processes and tools." If teams are forced to work in a certain way (e.g. scrum) then your organization isn't actually doing Agile.
The Agile manifesto specifically says "Individuals and interactions over processes and tools." If teams are forced to work in a certain way (e.g. scrum) then your organization isn't actually doing Agile.
Maybe. But "Scrum" and "Agile" are now mostly used exactly for what OP said. So it doesn't really matter what the original intention of the word was, unfortunately the meaning has changed.
I am tired of "you are doing Agile wrong" arguments. I hear it all the time. What's the point of a manifesto that only works when done perfectly right. A manifesto/process that isn't robust to imperfections has no role in a real world, which is always going to be imperfect
There's a difference between "doing something poorly" and "doing the exact opposite of something and claiming that you're doing it"
Agile is robust because it ISN'T a strict process.
Agile is robust because it ISN'T a strict process.
> Individuals and interactions over processes and tools - and we have mandatory processes and tools to control how those individuals interact
https://www.halfarsedagilemanifesto.org/
https://www.halfarsedagilemanifesto.org/
It's literally not a process yet you keep referring to it as one.
What's the point of defining something that only works when you follow the definition?
Are you really asking that?
The problem with most uppercase Agile implementations isn't that they are slightly off from the manifesto, but because they completely ignore what the manifesto is trying to say.
Are you really asking that?
The problem with most uppercase Agile implementations isn't that they are slightly off from the manifesto, but because they completely ignore what the manifesto is trying to say.
[deleted]
I’ll make sure to pull that one out next time someone tells me we have to implement agile in our origination. Ideally we could avoid making any changes at all.
The problem is that most management probably doesn't actually want Agile.
The goal of Agile is building the right thing for the customer, which is done by having the people who do the work talk to the customer (frequently!) to see what their needs are and how their needs are being met by what they have already.
The problem here is that this turns the organization from top-down to bottom-up. Those at the top of the company are now servant leaders who support those at the bottom, as opposed to people who give orders and tell those at the bottom what to do.
The real problem with Agile is that managers are rarely willing to give up that power.
The goal of Agile is building the right thing for the customer, which is done by having the people who do the work talk to the customer (frequently!) to see what their needs are and how their needs are being met by what they have already.
The problem here is that this turns the organization from top-down to bottom-up. Those at the top of the company are now servant leaders who support those at the bottom, as opposed to people who give orders and tell those at the bottom what to do.
The real problem with Agile is that managers are rarely willing to give up that power.
Management doesn't care if it's agile or not - they want something that works and delivers economic value for customers and will help them continue to innovate and deliver EVA for them in the future. One huge problem is that a lot of times, what people think is what the customer wants isn't what they want or need. One way that happens is sales brings asks (in the form of solutions often) to product and it goes downhill from there. Obviously, the people doing the work aren't talking with customers in that case, but it's tough to talk to customers in an enterprise environment. If you're doing something for a small external client or an internal team it's fine.
In addition, customers aren't a monolith. When you reach sufficient size, you have competing priorities for customer needs and even some asks that work for one customer but break some sort of process for another. They can be mutually exclusive. This is also heavily predicated on the customer even knowing what they want. Everyone knows the famous Ford quote “If I had asked people what they wanted, they would have said faster horses.”
Agile is great but scaling it can be rough dependent on a lot of variables, so reducing it down to management probably doesn't like Agile due to inability to give up power (to me at least) is a bit too simple.
In addition, customers aren't a monolith. When you reach sufficient size, you have competing priorities for customer needs and even some asks that work for one customer but break some sort of process for another. They can be mutually exclusive. This is also heavily predicated on the customer even knowing what they want. Everyone knows the famous Ford quote “If I had asked people what they wanted, they would have said faster horses.”
Agile is great but scaling it can be rough dependent on a lot of variables, so reducing it down to management probably doesn't like Agile due to inability to give up power (to me at least) is a bit too simple.
"Management [...] wants something that works and delivers economic value for customers and will help them continue to innovate and deliver EVA for them in the future."
You're confusing "owner" with "manager". Most managers just want to get promoted, which usually means increasing their HC/budget, making sure credit for a project's success is their's, failures are blamed on others, getting trendy internal projects, doing endless re-orgs (knowing they'll move on before any true costs/benefits are realized), etc. "Economic value for customers" is an afterthought at best.
(Speaking as a former very-large-company manager.)
You're confusing "owner" with "manager". Most managers just want to get promoted, which usually means increasing their HC/budget, making sure credit for a project's success is their's, failures are blamed on others, getting trendy internal projects, doing endless re-orgs (knowing they'll move on before any true costs/benefits are realized), etc. "Economic value for customers" is an afterthought at best.
(Speaking as a former very-large-company manager.)
I'm not confusing owner with manager - I'm thinking of things through the lens of the principal-agent relationship and of upper management's goals (which was what the OP was talking about) rather the middle management's.
> That's important in places like bodyshops and non-software business where no self-respecting engineer with options would want to work, and places where monotonous quality matters more than brilliance. Keep em as far as I'm concerned.
Based on my experience that is happening in a lot more places than what you listed. Doesn’t help that price tag of experienced devs pushed dramatically upwards in the recent years
Based on my experience that is happening in a lot more places than what you listed. Doesn’t help that price tag of experienced devs pushed dramatically upwards in the recent years
Scrum is there for the people who’ve never read the Manifesto, and don’t want to.
I deeply disagree.
If you have a team of quality people but they're all running around in their own direction doing their uncoordinated thing, they add up to basically zero. While if they're all working towards the same thing in the same direction, their efforts reinforce each other so the whole is much greater than the sum of its parts.
The expertise of people on a team provides a ceiling for what they can accomplish, that's true. And so you need to make sure that if you've got a task to achieve by a certain date, that it's below their ceiling. The best manager can't raise that ceiling.
But you still absolutely need to manage them in order for them to get anywhere even close to that ceiling. And to go back to your sports metaphor, when an amazing coach replaces a terrible one on a sports team, it's astonishing the difference it makes -- you almost can't believe it's the same team. It's astonishing what happens when a sports team plays "as one" instead of each player doing their own thing no matter how great they are. But that simply doesn't happen organically. It requires a coach, the same as a great team of employees doesn't get there without a great manager.
So ultimately it's not that either matters more than the other. You need both individual expertise and management. Think of the total resulting effectiveness as a multiplication of those two values.
If you have a team of quality people but they're all running around in their own direction doing their uncoordinated thing, they add up to basically zero. While if they're all working towards the same thing in the same direction, their efforts reinforce each other so the whole is much greater than the sum of its parts.
The expertise of people on a team provides a ceiling for what they can accomplish, that's true. And so you need to make sure that if you've got a task to achieve by a certain date, that it's below their ceiling. The best manager can't raise that ceiling.
But you still absolutely need to manage them in order for them to get anywhere even close to that ceiling. And to go back to your sports metaphor, when an amazing coach replaces a terrible one on a sports team, it's astonishing the difference it makes -- you almost can't believe it's the same team. It's astonishing what happens when a sports team plays "as one" instead of each player doing their own thing no matter how great they are. But that simply doesn't happen organically. It requires a coach, the same as a great team of employees doesn't get there without a great manager.
So ultimately it's not that either matters more than the other. You need both individual expertise and management. Think of the total resulting effectiveness as a multiplication of those two values.
I actually agree with you a good amount. I was never saying that you don't need management, just that first you need quality people. I do think you can have a good team with poor managers that still preforms, but I can't think of any examples of great managers with bad teams that excel.
Well first I would say that a team of quality people wouldn't all run in their own direction. They would know they need to coordinate to achieve a goal. Quality doesn't just mean being good at programming, it means the whole process of delivering software.
The sports metaphor is starting to break down, but just to have a one more go. Sports is different because the top teams all have top 1000 players in the world. This won't really happen in software. So with software it's more about putting together the right team. One where people enhance the whole, and that's what I think the biggest role of management is about. It's helping coordinate quality people.
The thing I was speaking out against was that you could have a good manager with a good process and not great people. The idea that the process can hide the problems of the team is something I don't believe. It doesn't matter how you organize if thats the case, nothing of real value will get made.
I do like the idea that the total result is a multiplayer of the two values. I just think the team quality is a little more of a multiplier than the other :)
Well first I would say that a team of quality people wouldn't all run in their own direction. They would know they need to coordinate to achieve a goal. Quality doesn't just mean being good at programming, it means the whole process of delivering software.
The sports metaphor is starting to break down, but just to have a one more go. Sports is different because the top teams all have top 1000 players in the world. This won't really happen in software. So with software it's more about putting together the right team. One where people enhance the whole, and that's what I think the biggest role of management is about. It's helping coordinate quality people.
The thing I was speaking out against was that you could have a good manager with a good process and not great people. The idea that the process can hide the problems of the team is something I don't believe. It doesn't matter how you organize if thats the case, nothing of real value will get made.
I do like the idea that the total result is a multiplayer of the two values. I just think the team quality is a little more of a multiplier than the other :)
>Well first I would say that a team of quality people wouldn't all run in their own direction. They would know they need to coordinate to achieve a goal. Quality doesn't just mean being good at programming, it means the whole process of delivering software.
That's probably an optimistic view of even quality people. They're not magically going to know what their goal--presumably aligning with business interests--is. They may not know company priorities. They may personally be more invested in some aspects of the process than others.
As far as sports analogies, it probably varies by sport. Coaches are important in general but, if you put a really good basketball team with one or two superstars on the court, they'll probably play a given game pretty well on their own. The same is almost certainly not true of even the Superbowl-winning football team.
That's probably an optimistic view of even quality people. They're not magically going to know what their goal--presumably aligning with business interests--is. They may not know company priorities. They may personally be more invested in some aspects of the process than others.
As far as sports analogies, it probably varies by sport. Coaches are important in general but, if you put a really good basketball team with one or two superstars on the court, they'll probably play a given game pretty well on their own. The same is almost certainly not true of even the Superbowl-winning football team.
I don't think you're negating what GP is saying. I like how managing engineers seem to be associated with coaching competitive players in sport. I think it makes a lot of sense, you get the same kind of personalities (team players, solo players, etc.), you have to deal with the different people temperaments, life, etc.
If I learned anything watching "the playbook" on Netflix, is that great coaches don't seem to follow any kind of playbook at all. They're flexible, and managed to create strong relationships with their managees over time, while forcing them to be team players.
If I learned anything watching "the playbook" on Netflix, is that great coaches don't seem to follow any kind of playbook at all. They're flexible, and managed to create strong relationships with their managees over time, while forcing them to be team players.
I agree with you but the sports metaphor undersells your point. Coaches usually don't matter all that much unless you are going from a truly terrible one. Bad management isn't like not a great coach, it like having a team where all the players are playing different sports, there is no score board, and people get paid based on how much the coach likes them.
You should watch "the playbook" on Netflix, I think coaches matter much much more than what you think, at least that's what I realized watching the documentary.
> I deeply disagree.
Wow, really? You must have never been part of a strong, productive team.
Wow, really? You must have never been part of a strong, productive team.
Getting the right people on the bus is only one component. See Jim Collins' map for the others.
https://www.jimcollins.com/concepts.html
https://www.jimcollins.com/concepts.html
In small companies, I agree with you. However, in a big company the quality of individual work doesn't matter much at all. Most of the time will be spent on communication, prioritization, compliance, and oversight overhead. On top of that you have everyone just performing for a promotion instead of what actually helps the company. Improvements to reduce any of this overhead will dominate how good the team is.
Sounds like you have never worked in a bigger company.
Despite having great people, coordination challenges greatly increase over time. This is a good summary:
https://komoroske.com/slime-mold/
Despite having great people, coordination challenges greatly increase over time. This is a good summary:
https://komoroske.com/slime-mold/
The people upvoting this blog can’t have read it, since an HN audience would not possibly think the solution to OKRs is to supplement them with a reductionist income statement and traffic light scorecards
Yeah, it's too bad the author didn't choose the title "OKRs don't work for Sales targets" or "You need Sales KPIs separate from (Engineering) OKRs". We would have gotten different discussion.
The problem with all of these performance management frameworks is the same.
You start with objectives that make sense and are aligned to the organization's mission.
Then you come up with metrics that attempt to measure how successfully those objectives are being realized.
Then you tie manager and executive compensation to those metrics.
Finally everyone proceeds to game the metrics, often in ways that completely contravene the original objectives, in order to maximize their bonuses.
Rinse and repeat.
You start with objectives that make sense and are aligned to the organization's mission.
Then you come up with metrics that attempt to measure how successfully those objectives are being realized.
Then you tie manager and executive compensation to those metrics.
Finally everyone proceeds to game the metrics, often in ways that completely contravene the original objectives, in order to maximize their bonuses.
Rinse and repeat.
The interesting thing is that in Measure What Matters (the Book about OKRs) they specifically call out _not_ tying bonuses and compensation to OKR results. It’s such a shame that this critical part of the methodology gets lost in the implementation.
Another serious problem with these, at least to me, is that an employee's performance within these frameworks is often graded against an ideal implementaion and not the actual implementation.
I don't care what managers do as long as it's managers doing their own fucking jobs instead of forcing it on everyone below them. Individual engineers shouldn't have to plan objectives, their own or otherwise. That's literally what management is for in the first place.
Here here!
I've worked with people saying that, and others really wanting to influence upwards and for which defining their own objectives was primordial.
To each their own.
To each their own.
I find the same people who think its never worth planning anything are the ones who spend all their time making worthless crap and never get anything done because they think having a goal is beneath them.
My experience is that people that plan all the time are the ones that get nothing done.
Want do get something done? Only plan some of the time!
False dichotomy avoided.
False dichotomy avoided.
I'm an architect (software, not houses). There's a gigantic fucking chasm of difference between architectural design planning and OKRs.
What are your thoughts on some of the trends/buzzwords I find among Architects' communities these days, like "Evolutionary Architecture" or "Just Enough Architecture"?
Note: I don't mean to lower their values by calling them buzzwords, but I truly see a peak of usage in the last 12-24 months, that gets me curious.
Note: I don't mean to lower their values by calling them buzzwords, but I truly see a peak of usage in the last 12-24 months, that gets me curious.
Unrelated to any specific subject, I dislike all buzz phrases everywhere everywhen, because they tend to only make sense to people after you explain what they mean. And if you have to explain what they mean, then the phrase wasn't helpful and you can just skip that part and get right to the explanation.
But it especially doesn't help anyone to say pithy business guru shit like "build only what you need". Sure, ok, but that's not the part people really need help with in the first place. Put up a poster that says "make the company more money than you cost it" with a picture of a cute kitten or something and move on with your day.
99% of all software engineers need to be told exactly what functions to implement and where and how to name them and how to organize them in order to not produce something disgustingly oppositional to use and maintainance because they completely lack any aesthetic sense whatsoever for their craft. So management can decide which bridge they want to prioritize safety in and let an architect plan it first before the wrench jockey who doesn't know a cantilever from their elbow starts bolting holes.
I don't know if I answered your question as expected or not.
But it especially doesn't help anyone to say pithy business guru shit like "build only what you need". Sure, ok, but that's not the part people really need help with in the first place. Put up a poster that says "make the company more money than you cost it" with a picture of a cute kitten or something and move on with your day.
99% of all software engineers need to be told exactly what functions to implement and where and how to name them and how to organize them in order to not produce something disgustingly oppositional to use and maintainance because they completely lack any aesthetic sense whatsoever for their craft. So management can decide which bridge they want to prioritize safety in and let an architect plan it first before the wrench jockey who doesn't know a cantilever from their elbow starts bolting holes.
I don't know if I answered your question as expected or not.
Proper
Planning
Prevents
P*s
Poor
Performance
Managers are accountable for seeing this is done, but the whole team should be co-responsible for setting goals.
I worked as a software engineer for 12 years before becoming a manager and I can promise you that a team works better when everyone has input on what goals the team commits to and how the team plans to achieve those goals.
You never never never NEVER want to work on a team where your manager decides all of that and then just throws tickets at you. Screw that sideways.
I worked as a software engineer for 12 years before becoming a manager and I can promise you that a team works better when everyone has input on what goals the team commits to and how the team plans to achieve those goals.
You never never never NEVER want to work on a team where your manager decides all of that and then just throws tickets at you. Screw that sideways.
I did understand the comment differently. More that at some level OKRs are not important and the decision that a product/module is needed is everything a good working development team needs to do it’s job.
That has nothing to do about the creation of tickets imo. Ofc the team will find a way to organise ITS OWN WORK.
That has nothing to do about the creation of tickets imo. Ofc the team will find a way to organise ITS OWN WORK.
Exactly. Thanks for this.
I don't know what the rest of the comments are on about but this is a pretty reasonable proposal. In particular, it's heinous to couple customer acquisition to engineering projects. Maybe customers don't want what you're selling, or maybe the economy is taking a down turn, or the sales pipeline is broken.
OKRs can absolutely be useful, but like so many other things, a system is what it does. If you measure bug rate, then you'll get no bug reports, even if there are bugs.
OKRs, when done correctly, aren't about accountability necessarily, but course correcting early and often. It's a tool to combat scope creep and a feedback loop for triggering pivots when progress towards laid plans aren't yielding returns.
These are things engineers should love! They keep engineers focused on the right things, aligned with the business and most importantly keep the business aligned with them.
Politics and bureaucracy are rampant everywhere, but like everything else, when used in moderation these tools can be really good.
OKRs can absolutely be useful, but like so many other things, a system is what it does. If you measure bug rate, then you'll get no bug reports, even if there are bugs.
OKRs, when done correctly, aren't about accountability necessarily, but course correcting early and often. It's a tool to combat scope creep and a feedback loop for triggering pivots when progress towards laid plans aren't yielding returns.
These are things engineers should love! They keep engineers focused on the right things, aligned with the business and most importantly keep the business aligned with them.
Politics and bureaucracy are rampant everywhere, but like everything else, when used in moderation these tools can be really good.
I am so happy to work in a company that does not work with this business voodoo (and still delivers great results).
All goal frameworks I have worked in, OKRs included, were a colossal waste of time.
The blog nicely states that OKRs are just a part of a solution. I've seen when OKRs actually worked, and the emphasis was put on the objectives part and later the indicators produced a set of initiatives. Unfortunately, I've also seen really stupid low level "OKRs" (like unit test coverage) absolutely detached from bussines goals and the whole process was just a cargo cult managment.
What size is your company? What else can we do when a company has reached 1000+ employees?
> a colossal waste of time
Oh, that's when they work on the least bad way. They can become much more than that, all it takes is somebody intent on gaming them.
Oh, that's when they work on the least bad way. They can become much more than that, all it takes is somebody intent on gaming them.
While the article may be good at explaining organizational goal setting, personally I f*g hate anything about this HR bullshit. It's simple: make goals, do them. Don't overcomplicate and annoy people who actually do smth compared to those that just talk.
It is almost always the people who "just talk" (managers) that are being measured by OKRs, though.
It's just that these managers often respond by relaying their OKRs to their teams and making them constantly-aware-of and responsible-for achieving them, rather than having the OKR be something private to the executive level that informs the manager's decisions, while they continue to run the team the way they would without OKRs.
It's just that these managers often respond by relaying their OKRs to their teams and making them constantly-aware-of and responsible-for achieving them, rather than having the OKR be something private to the executive level that informs the manager's decisions, while they continue to run the team the way they would without OKRs.
You’d probably be faced with ‘but why are we doing this?’ from the levels ‘below’. Damn if you do, damn if you don’t.
Yeah, personally I like to know what the team & I are being evaluated on.
I've been in the opposite situation, where there are priorities and goals that aren't communicated to me until way too late, and I ended up wasting a lot of time on stuff that didn't matter.
I've been in the opposite situation, where there are priorities and goals that aren't communicated to me until way too late, and I ended up wasting a lot of time on stuff that didn't matter.
That's in theory. In practice I knew of no ICs w/o OKRs assigned to them.
I don't know what you mean by assigned to the IC, but at my last job our team's ICs wrote the OKRs for our team.
> When a startup is small, it can be sufficient to run a fairly simple objectives-and-key-results (OKRs)
When OKRs were first used at Google it already had tens of thousands of employees. Why would any startup use a tool created by a big org and designed for a big org? Should we give infants medicines that were created for adults?
Startups need to stop copying BigTech because they're not like BigTech.
When OKRs were first used at Google it already had tens of thousands of employees. Why would any startup use a tool created by a big org and designed for a big org? Should we give infants medicines that were created for adults?
Startups need to stop copying BigTech because they're not like BigTech.
I don't think that's accurate. They got OKRs early on from a VC John Doerr connected to Intel ("High Output Management").
Intel was huge when they started OKRs, but Google wasn't, in 2000.
https://rework.withgoogle.com/guides/set-goals-with-okrs/ste...
Intel was huge when they started OKRs, but Google wasn't, in 2000.
https://rework.withgoogle.com/guides/set-goals-with-okrs/ste...
The business scorecard just seems like it is measuring a set of key results. If it’s a KPI the team is trying to achieve then how is that different than a key result?
In my opinion, one of the best parts of the definition of key results is that when done right, meeting all key results should result in the objective being accomplished. If you can hit all the key results and still not have met the objective, there was an issue in the definition process.
The answer lies in the frequency of updates across the org. KRs in most orgs are reviewed on a quarterly basis, whereas marketing spend, conversions and similar need a weekly cadence. We are currently reporting on KRs on a weekly basis, but that requires a lot of indoctrination for new hires.
I think it’s best practice to monitor your top-level KRs in your weekly/bi-weekly leadership meeting. I have never heard anyone recommend to only use OKRs for retrospective evaluation of a quarter/half.
For example I’m sure Doerr recommends regular syncs on the status of your KRs.
They are intended to be both a way of reviewing the work in a planning period, and also determining what is red and needing attention within the planning period.
Tactical/team-facing KRs could be measured daily if you need to, though the CEO wouldn’t want that report.
For example I’m sure Doerr recommends regular syncs on the status of your KRs.
They are intended to be both a way of reviewing the work in a planning period, and also determining what is red and needing attention within the planning period.
Tactical/team-facing KRs could be measured daily if you need to, though the CEO wouldn’t want that report.
> OKRs inevitably become at odds with business results and the OKR system becomes bloated. It becomes hard to focus on the priorities that matter most while ensuring that every area of the business is running as expected.
Is practically begging the question. If the business results are not matching up, what's going on? Are are your OKRs in conflict with running the business as expected?
The title "will never be enough" is business dystopia to my ears. OKRs are bad enough — and you want more? OKRs as implemented where I've worked is the "O" is often BS, everybody skips the "KR" step completely, often naming abstract wibbly-wobbly goals in its place, and by Q3 it's all been forgotten about.
Is practically begging the question. If the business results are not matching up, what's going on? Are are your OKRs in conflict with running the business as expected?
The title "will never be enough" is business dystopia to my ears. OKRs are bad enough — and you want more? OKRs as implemented where I've worked is the "O" is often BS, everybody skips the "KR" step completely, often naming abstract wibbly-wobbly goals in its place, and by Q3 it's all been forgotten about.
Is your company successful? Or is their failure at OKRs a symptom of their problem?
This is the framework beneath the language that as an engineer has gone above my head for a long time. Large tech companies often fail to bridge this language gap, and maybe that contributes to some friction overall.
On a slightly different note, it would be great if organizations had no expectations for engineers to learn or know about any of this... and also get promoted. I went to school for so long to be a technical person but it seems every org expects engineers to learn everything about business operations, management etc. It's just a strange expectation, like being a plumber but then you also have to take care of the plants outside and do some gardening.
On a slightly different note, it would be great if organizations had no expectations for engineers to learn or know about any of this... and also get promoted. I went to school for so long to be a technical person but it seems every org expects engineers to learn everything about business operations, management etc. It's just a strange expectation, like being a plumber but then you also have to take care of the plants outside and do some gardening.
If you do not contribute more to the business than the job you originally took, why should you be promoted? I can imagine you getting a raise as you demonstrate more proficiency in the job, but promotion seems to imply that you do a different job for the business.
Fair point, although remaining in the same position without promotion is usually discouraged and not a real option in the long run. Yes, promotion means more value added, but that can be defined many ways. In tech companies it usually includes having more management and/or other non-technical skills (for technical workers). The value could be more aligned with just having more technical skills. It could even be formally assessed by reviewing code and even test, yet from my experience more technical skills had little impact on promotion chances.
At this point, I'm full "sickos.jpg" watching organizations switch goal setting frameworks to fix issues stemming entirely from communication, planning, and accountability problems. I'm not even going to get started on how silly these scorecards are considering the metrics shown are a minimum for running a business.
Funnily enough, the point of OKRs is to provide a framework for communication, planning, and accountability.
Particularly the last 2. Most companies, if they actually sit down and talk through their objectives honestly, and then get buy-in from the stakeholders and doers on the actual KRs and initiatives, will be forced to face and figure out the big issues in communication and accountability, at least by the time you have done OKRs for a year or so (your third or fourth planning cycle typically starts to feel like you have the hang of it).
And writing down your main goals ahead of time, with a clear owner, then reviewing after, is a good planning and accountability framework, no matter what name you give it.
As with anything good, there is snake oil to be had, and idiots will do OKRs wrong like they do everything else wrong. But I think it’s a useful tool in the hands of a competent and well-run company, particularly for startups that are getting into the stage where they need to start planning seriously, and don’t have an existing framework, say around 25-50 people.
Particularly the last 2. Most companies, if they actually sit down and talk through their objectives honestly, and then get buy-in from the stakeholders and doers on the actual KRs and initiatives, will be forced to face and figure out the big issues in communication and accountability, at least by the time you have done OKRs for a year or so (your third or fourth planning cycle typically starts to feel like you have the hang of it).
And writing down your main goals ahead of time, with a clear owner, then reviewing after, is a good planning and accountability framework, no matter what name you give it.
As with anything good, there is snake oil to be had, and idiots will do OKRs wrong like they do everything else wrong. But I think it’s a useful tool in the hands of a competent and well-run company, particularly for startups that are getting into the stage where they need to start planning seriously, and don’t have an existing framework, say around 25-50 people.
From wikipedia (https://en.wikipedia.org/wiki/OKR)
> Key results should be measurable, either on a 0–100% scale or with any numerical value (e.g. count, dollar amount, or percentage) that can be used by planners and decision makers to determine whether those involved in working towards the key result have been successful. There should be no opportunity for "grey area" when defining a key result.
In a lot of places that use "OKRs" the metric is something non-specific, like "get more users" or "have a great UX". This means your bonus now depends on politics, instead of a defined metric of success. When the metrics are clearly defined, work can be a pleasure.
> Key results should be measurable, either on a 0–100% scale or with any numerical value (e.g. count, dollar amount, or percentage) that can be used by planners and decision makers to determine whether those involved in working towards the key result have been successful. There should be no opportunity for "grey area" when defining a key result.
In a lot of places that use "OKRs" the metric is something non-specific, like "get more users" or "have a great UX". This means your bonus now depends on politics, instead of a defined metric of success. When the metrics are clearly defined, work can be a pleasure.
> This means your bonus now depends on politics, instead of a defined metric of success.
The process of defining a concrete metric in advance is just front-loading that politics process to the planning stage instead of at the back end. (Which may be better! But it doesn't eliminate politics.)
The process of defining a concrete metric in advance is just front-loading that politics process to the planning stage instead of at the back end. (Which may be better! But it doesn't eliminate politics.)
That is a good angle. Let me elaborate.
I am not so much talking about the correctness of the metric, but about the certainty that you will get it, if your results are good.
If there is no specific number someone can always say you performed bad one day before, for pretty much any reason (you did not care enough about the customer). This can destroy morale.
Instead, if the metric is quantifiable and easy to check on a dashboard there is no way to deny it. By the time the evaluation comes there is no manipulation possible.
I am not so much talking about the correctness of the metric, but about the certainty that you will get it, if your results are good.
If there is no specific number someone can always say you performed bad one day before, for pretty much any reason (you did not care enough about the customer). This can destroy morale.
Instead, if the metric is quantifiable and easy to check on a dashboard there is no way to deny it. By the time the evaluation comes there is no manipulation possible.
You can use a different framework here, but you can also just use OKRs too. I argue mixing OKRs and KPIs just muddies the water for little value.
Even within engineering, some teams are more geared towards “sustaining quality” than “expanding capabilities”.
You can just as easily set a “maintain quality” or “sell our product” objective that may or may not have explicit initiatives, and call the KPIs from the article KRs instead. There is really no difference.
You often see this within teams too; it’s best practice to have a quality metric as a guardrail to any growth metric (eg “add users, but don’t increase churn for existing” or “build new functionality, but don’t impact API uptime”). So you end up needing to represent these non-initiative-driven metrics that the article wants to call KPIs in your OKR system anyway.
KISS!
Even within engineering, some teams are more geared towards “sustaining quality” than “expanding capabilities”.
You can just as easily set a “maintain quality” or “sell our product” objective that may or may not have explicit initiatives, and call the KPIs from the article KRs instead. There is really no difference.
You often see this within teams too; it’s best practice to have a quality metric as a guardrail to any growth metric (eg “add users, but don’t increase churn for existing” or “build new functionality, but don’t impact API uptime”). So you end up needing to represent these non-initiative-driven metrics that the article wants to call KPIs in your OKR system anyway.
KISS!
I’m so fucking over everyone spending time trying to re-invent the methodology in which work is accomplished.
Just do the work, do it well, make it measurable, and hit 80% of your aspirational goals
Middle management needs to find something else to do, like complain about single panes of glass and metrics
Just do the work, do it well, make it measurable, and hit 80% of your aspirational goals
Middle management needs to find something else to do, like complain about single panes of glass and metrics
I don’t see the difference (and frankly the need for) scorecard and OKR.
I am one of these managers the majority of the comments here complain about. I lead teams and tried to implement twice OKR. Overall the idea I think is good as it makes everyone start thinking how to work with outcomes instead of objectives. The major problem is that without a good strategy doing OKRs is very difficult.
But back to the problem: Objectives (O) should be inspirational and Key Results (KR) are measurable outcomes. The examples given for scorecards can very well be KRs. Instead of a weekly review we just use dashboards where everyone can see how we perform and we review OKR quarterly.
But back to the problem: Objectives (O) should be inspirational and Key Results (KR) are measurable outcomes. The examples given for scorecards can very well be KRs. Instead of a weekly review we just use dashboards where everyone can see how we perform and we review OKR quarterly.
By their very nature OKRs are terrible. It’s purely for the benefit of management/executives because they’re asking rank and file employees to go above and beyond their job duty all in the name of squeezing out more performance with the same amount of resources.
Supposedly it’s the leadership’s job of steering the company in the right direction but in the end they throw their hands up and ask the people doing the REAL work to simply do more.
Supposedly it’s the leadership’s job of steering the company in the right direction but in the end they throw their hands up and ask the people doing the REAL work to simply do more.
The author gets the headline right: OKRs will never be enough. You need talent. Management talent and individual contributor talent. OKRs are a communication framework. The author thinks you should communicate more detailed information than what OKRs contain by default. Seems fine, but honestly a big nothingburger.
OKRs in practice look suspiciously like waterfall software development. When you find yourself assigning ICs programming tasks by economic quarter, you've f-ed up.
So the simple modified MBO framework that Andy Grove era Intel used and then later Google used . . . just won't scale as startups get bigger?
Something smells fishy.
Something smells fishy.
I imagine both companies also have a financial plan and some kind of process for monitoring baseline KPIs, which seems to be the main point of the post.
A business should track its financials, goals and performance?
You don't say :)
You don't say :)
Does anyone use OKRs for themselves? How does it work?
Yes, for settings personal goals it can be helpful.
KRs are just "things you can do to achieve the goal", so my process goes:
- What do I wish was different? - What would happen if that thing changed? - What's stopping it from changing? - How can I get over those obstacles?
The answers to "how can I get over those obstacles?" become the KRs that help achieve the O ("What do I wish was different?").
KRs are just "things you can do to achieve the goal", so my process goes:
- What do I wish was different? - What would happen if that thing changed? - What's stopping it from changing? - How can I get over those obstacles?
The answers to "how can I get over those obstacles?" become the KRs that help achieve the O ("What do I wish was different?").
KR stands for "Key Result". They're definitely not "things you do to achieve your goal".
That's kind of the point of OKRs (in theory): To stop upper managers from dictating process to lower managers. (Which is a big problem.) Instead, ignore their process and evaluate them on how well whatever process they chose delivered. IE, give someone an objective, let them find their own solution, and evaluate them on only how well it worked.
That's kind of the point of OKRs (in theory): To stop upper managers from dictating process to lower managers. (Which is a big problem.) Instead, ignore their process and evaluate them on how well whatever process they chose delivered. IE, give someone an objective, let them find their own solution, and evaluate them on only how well it worked.
Use it to keep track of personal goals and I use the KR to break it down into chunckable and measurable steps. Have done that intuitively in the past, but now have formalised it a bit more. It helps that for my job we OKR regularly for both the Performance but also the Growth part of the job.