Does anyone use OKRs for themselves? How does it work?
OKRs will never be enough
11–20 of 100 posts
Re: OKRs will never be enough
#12All 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 sp…
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.
Re: OKRs will never be enough
#13I 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.
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.
Re: OKRs will never be enough
#14While 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 wi…
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.
Re: OKRs will never be enough
#15You 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!
Re: OKRs will never be enough
#16All 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 sp…
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.
Re: OKRs will never be enough
#17I 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.
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.
Re: OKRs will never be enough
#18I 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.
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.
Proper
Planning
Prevents
P*s
Poor
Performance
Re: OKRs will never be enough
#19This 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.
Re: OKRs will never be enough
#20All 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 sp…
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.