3 ms·

my experience with OKR's is that it doesn't really apply to the product or specifically software engineering teams like, whatever the CEO is doing and whatever

my experience with OKR's is that it doesn't really apply to the product or specifically software engineering teams like, whatever the CEO is doing and whatever the HR team is doing or whatever the sales team is doing are not processes that affect or should include the engineering teams in that way. The OKR process - in its unfalsifiable glory - doesn't really have the utility to all teams. for example "don't do binary goals" is just a waste of time then there are some implementations where personal OKR's are the final end of the cascading concept of OKR's, and that's a waste of time too. oh like learn rust? or like go hiking? pass leetcode hards so I get the f* out of here? its not the company's business but done on company devices or collaborative tools for all or an admin to judge then there's the "if you meet your goals then you weren't ambitious enough", okay tell that to the product manager who is reducing the story points per sprint every two weeks because the team as a whole can't meet any goal and that's the PM's most innovative reaction and then you're going to spend half the quarter doing OKR rituals on top of that, christ

koliber 3y ago
Often OKRs are forced into engineering teams and the result is that they don't deliver value. However, there are ways of doing OKRs in engineering teams as well. I recently wrote up a little account of how I used an OKR around linter errors to get a team to take quality more seriously. It worked surprisingly well: https://koliber.com/articles/reduce-tech-debt-with-okrs https://koliber.com/articles/reduce-tech-debt-with-okrs It's not that OKRs such. It's that they are often done in a ham-fisted fashion.
- yieldcrv 3y ago
  That tale is inspirational, the OKR aspect of it seems not important. You were having weekly engineering meetings regardless. You were giving positive reinforcement regardless. Its like because your team were subjugated by a hamfisted OKR feifdom, you conformed a goal into an OKR. Would you have ignored this issue if the OKR didn't tell you to go find something to be an issue? Was the maturity of your development team driven by your drive to find a problem, and then the root of the problem, because the OKR told you to find something?

koliber 3y ago

Often OKRs are forced into engineering teams and the result is that they don't deliver value. However, there are ways of doing OKRs in engineering teams as well. I recently wrote up a little account of how I used an OKR around linter errors to get a team to take quality more seriously. It worked surprisingly well: https://koliber.com/articles/reduce-tech-debt-with-okrs https://koliber.com/articles/reduce-tech-debt-with-okrs It's not that OKRs such. It's that they are often done in a ham-fisted fashion.

yieldcrv 3y ago
That tale is inspirational, the OKR aspect of it seems not important. You were having weekly engineering meetings regardless. You were giving positive reinforcement regardless. Its like because your team were subjugated by a hamfisted OKR feifdom, you conformed a goal into an OKR. Would you have ignored this issue if the OKR didn't tell you to go find something to be an issue? Was the maturity of your development team driven by your drive to find a problem, and then the root of the problem, because the OKR told you to find something?