3 ms·

"Let OKRs highlight a special focus. Don’t try to cram everything you do into them" Then link compensation to OKRs then everybody just focuses on bending the r

by gbin 2y ago

"Let OKRs highlight a special focus. Don’t try to cram everything you do into them" Then link compensation to OKRs then everybody just focuses on bending the reality to meet the letter of the OKR and nobody is interested in doing their job. After the "oh shit" moment, we cram everything we do into them. Then everybody ignores OKRs.

osmsucks 2y ago
The most insulting case is that of the retroactively-adjusted OKR wording so that you can always meet 0.7+ scores.
szundi 2y ago
I remember when reading about Intel and OKRs in every management execution book. I thought that's the time to sell the stock.
- Aromasin 2y ago
  They brought them back during my recent tenure at Intel, just after Pat joined. I was an application engineer, so my purpose was to debug customer support issues on our chips, filter between the customer and the engineering staff, write some User Guides and helpful collateral to developers, and open tickets with engineering when problems were severe enough. My OKRs could have just been "close tickets" and I think that would have been the best ROI for the company - there was never a point in my career where I didn't have tickets that needed working on that were halting multiple millions in revenue, but somehow my time was always spent having to work on other things. Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing. To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
  - PaulHoule 2y ago
    I worked at a startup where the main problems I saw were: (1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true. (2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle. The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't. The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business. My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business. I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.

by gbin 2y ago

osmsucks 2y ago

The most insulting case is that of the retroactively-adjusted OKR wording so that you can always meet 0.7+ scores.

szundi 2y ago

I remember when reading about Intel and OKRs in every management execution book. I thought that's the time to sell the stock.

Aromasin 2y ago
They brought them back during my recent tenure at Intel, just after Pat joined. I was an application engineer, so my purpose was to debug customer support issues on our chips, filter between the customer and the engineering staff, write some User Guides and helpful collateral to developers, and open tickets with engineering when problems were severe enough. My OKRs could have just been "close tickets" and I think that would have been the best ROI for the company - there was never a point in my career where I didn't have tickets that needed working on that were halting multiple millions in revenue, but somehow my time was always spent having to work on other things. Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing. To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
- PaulHoule 2y ago
  I worked at a startup where the main problems I saw were: (1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true. (2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle. The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't. The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business. My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business. I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.