I wonder if we’ll ever grow up as an industry and get over these MBA-enforced buzzwords like OKRs, SCRUM, etc.
It’s just sad to see so much energy from so many smart people poured into this crap.
It’s just sad to see so much energy from so many smart people poured into this crap.
OKRs just means you write down measurable goals in a place where people can see them. The word is popular since it is obviously a good thing to do, it is something everyone should do. In school your OKRs are your classes etc, having such short term measurable goals is really good for personal productivity and alignment.
So OKRs are like unit tests, you can do them badly but it is a thing you almost always want when you do software development, unit tests aren't just a "buzzword", and neither are OKRs.
The alternative to OKR is that your manager writes down your OKRs in a hidden place where you can't see them, the only thing that changes is that now you are less informed. Ignorance is bliss, but reality will smash you anyway.
Personally I thought it was good that I could see what goals my manager had, what goals his manager had, what goals that managers manager had etc. I don't see why people are so angry at that level of transparency.
It promotes menial tasks like "take a 2 day course in React". "Clean my desk twice a week" "write 10 unit tests" over "spending 100% of my time creating value for customers"
But when you find a manager/ place where people get it right, you'll love it.
But yeah OKR are usually done at higher level than individuals, I didn't write any OKRs just the people above me. In general it is something managers should do, the lowest level employees shouldn't have to.
I can agree that individuals being forced to write OKRs is a bad thing, but managers being forced to write OKRs is a good thing.
At higher level OKRs looks like "attract X more customers" or "reduce customer churn by Y%" etc, to achieve those they instruct people like you to create customer value, at your individual level such goals aren't as easy to write since they are the result of contributions from many parts.
Edit: But if you can come up with good measurable goals for you as an individual since you have enough individual freedom to do so, then yeah writing that down is good. But if you don't have any long term project and don't have control to plan what you work on then writing down an OKR is just hazing, you need to be responsible for the things your OKR measures, if you lack long term responsibilities then you shouldn't write down any OKRs.
What happened here was
1) that the techy guys convinced higher management that this is essential for success. (Replacing a fully functional CI/CD tool with another CI/CD tool)
2) The OKR deadline suddely got very close so instead of investigating how to do this step by step, it was decided they do it all at once without any detailed investigation how it affects all services. And without planning.
3) The customer feature teams of course did all the heavy lifting since it was their services that were affected.
4) 1.5 years later customer feature teams are still not done replacing the 150k lines of legacy CI/CD code with code for the new tool.
At what point do you hit the brakes?
In that case your manager has to decide, and seems they decided to ignore the customer in this case which is probably reasonable.
Anyway, not sure why that was due to OKR. Maybe the decision was rushed due to OKR deadlines as you say, maybe it would have been rushed anyway, but at least OKR makes these problems more visible and makes it easier to work with them.
OKR in general makes it much easier for managers to do their job, and you really want your managers to do their job properly.
In this case these were all internal priorities. But you are right, maybe it is not for me to be reaspn why or be upset about.
Both in terms of taking a shortcut in the priority queue because it was easily measurable, lived on it's own right without complex dependencies and "the platform guys also need an OKR"
But also in terms of how it was handled with regards to the OKR deadline, and possibly bonuses/performance reviews connected to how well it was achieved.
Yes, it was dysfunctional, but the OKRs enabled it IMO.
A huge company like google can swallow this because this fancy CI/CD tool was what they wanted all along, and there will always be another customer/project. But for a smaller company, this kind of shift in priorities can be lethal.
"Deliver product X" most of the time depends on so much more than my or the teams performance. Maybe it is not even a priority anymore?
Don't you have an OKR tree? If it isn't just your teams responsibility then just put it at a higher level in the org, and then the individual teams will have OKRs saying they should contribute to such efforts.
If you have too rapid pace of individual features, then an OKR can be to reduce latency when other functions need help from you to increase collaboration among teams etc, if that is a bottleneck to delivering features.
If a team you depend on often respond "we don't have time helping you, wait a week!", then that team should get an OKR to reduce that time since those delays are costing you a lot. Such delays are easily measurable so becomes excellent OKRs.
Other good OKRs could be to reduce time to review code etc, to help speed up coding iterations and make job more fun, waiting for a response isn't fun. We typically got code reviews in much less than an hour, for smaller things often within minutes, that is much better than waiting a day on it.
Edit: If your managers isn't doing these things then they are just incompetent, such an org will be dysfunctional regardless what you do, the OKR just makes that dysfunction more visible but they would work like shit regardless. OKRs really do help managers fix such organizations, as you can see from my examples above, those would really help you deliver features to customers in time.
So the organization/company that delivers on those - Wins?
I worked at a core library team at a big company, we had both OKR to improve the library and OKR to help people with issues in a reasonable amount of time. Both are important.
Anyway, in the end that isn't your decision to made, you were hired for a reason so a level or two above you should decide what is the most important here. So you disagreeing doesn't change that.
It is common for teams such as yours to prioritize the wrongs things, OKRs helps show such dysfunctions and makes it easy to fix. If you really are causing problems by deprioritizing customer requests then a higher level manager would go in and tell you to put that back on.
Say you're running an organisation if a few thousand people structured as a rough hierarchy. The goal is to move the stock price over a period of a few quarters. How should one do that?
Right now we're trying a combination of company-level objectives (not KRs) and Kanban, where the teams just work on the next most important objective they can.
Don't you have higher level umbrella targets that everyone can contribute to? OKRs are a tree, working on targets that aren't your teams but helps the bigger picture above you is also a feature of OKRs, you aren't meant to just look at your local OKRs.
Of course, it's better to be flexible, but when you give someone a goal, the goal is, well, the goal.
OKR shows you the state of the current organization, if the OKR are dysfunctional the organization is dysfunctional, it would be even if you didn't see the OKRs. The fix isn't to remove the OKRs, it is to align the OKRs with what each team is really expected to do as I said above.
If the team you need help from had an OKR to help you quickly, so they focused on that, do you really believe that would be a bad thing? That is the only way to do it, such teams are slow to respond and provide help everywhere that doesn't give them OKRs to reduce latency on responses, they always have their own things to work in regardless if they are visible or not.
Such OKR also makes life easier for that team, now they get rewarded for what they are supposed to do: provide support. And, if they don't have enough people to provide that support, now they have a good case to get more resources to enable them to provide that support.
That kind of “not my OKR” nonsense shouldn’t happen in a 15,000 person company, let alone a company where everyone’s OKR’s are, what, two steps from the corporate ones?
I believe it is accurate and constructive to say a 150 person company with OKRs producing counter-productive outcomes is doing it wrong, at least when replying to someone who seems to believe the problem is with the OKR model.
Aha. That’s an interesting take I never would’ve thought of. Thx…
Whilst I don't really like JIRA, I think this kind of tracking of objectives, initiatives and delivered results is a good way to capture OKRs based on reality rather than mission statements.
The irony is that OKR’s are nothing but a rehashing of Peter Drucker’s Management By Objectives (MBO)- invented in 1954 and already ignored by MBA programs by the 1970s. Management By Objective is useless until one is talking about the business unit level where folks have direct impact on profit and loss. If its not already immediately obvious what numbers are relevant to your job, there’s rarely anything to be gained by groping for them in the dark corners of a middle manager’s quarterly performance ritual.
Apologies in advance to who(m)ever posted this article or may have found it useful since I’m not trying to be a dick here… but… at least to this idiot… the article is a list of maudlin management cliches actually far more tired than even OKR’s or MBO.
As far as OKR’s, personally I find them a management charade at best, and destructive prob more often than not. Having wonderfully aligned goals and objectives is a good thing. But goals and objectives that aren’t wonderfully aligned? Not so much. Especially around self-driven folks- who most likely do the right thing in the absence of goals. And they’re especially bad if at all tied to compensation or promotion.
The fact that many in the tech world have both trotted out this old, tired, and often destructive technique; and then pinned the blame on the mythical MBA; is so rich with irony that I prob shouldn’t have bothered to even open my mouth on the topic.
p.s. Are MBA’s throwing around Scrum buzzwords these days? Man, we need to police our own… lol.
FYI, and this is just a tangentially related grammar remark, but "whomever" wouldn't be correct here, because the phrase "whoever posted this article" has the person in subject position here, even though the whole phrase is used in an object position (i.e "apologies to [whoever posted this article]"). You can think of it like "whoever" replaces something like "the person who," and "the person whom posted this article" sounds more obviously incorrect.
You could use "whomever" if it were something like "whomever your friend met," as the subject is "your friend" in that case, and "whomever" refers to an object. The equivalent noun phrase would be "the person whom your friend met."
Of course, most people just don't say "whom" ever, so it barely matters anyway.
The Objective part of OKR is the goal I guess you could say. The KR part are the measurable tactics used to achieve the goal.
But really, now there's "pre-work" for setting OKR's? Like it's not enough busy work already to just devise them.
If you’re part of the execution apparatus you’re just caught in the crossfire in trying to make some old fart’s powerpoint presentation green when showing it to other directors.
If you have a place where you write down goals you are basically doing OKRs, it is good to do in general.
I concur. But I personally have never seen that happen. Not to mention, instituting it organizationally means you don’t have much idea how it’s being applied elsewhere in the org.
It may look good on paper but in practice it always becomes a target and it’s considered a failure if you miss one. If it doesn’t work in practice the theory is wrong.
No true scotsman!
Do you even know what that means? I didn't say it isn't OKR if it is done badly, your response makes no sense.
In Agile it makes sense since they say if it doesn't work it isn't Agile, but I never said that badly done OKRs aren't OKRs.
And I’d never heard of Goodhart’s Law. Thanks for the mention.