Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OKRs might not work at your company

svpg.com

Post reply on HN
Print view View original

131–140 of 140 posts

Re: Why OKRs might not work at your company

#131

Post by jdm2212 »

User23 wrote: post #128
summerlight wrote: post #78

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=21873418 The author of that article completely confused about the goal of protobuf. Read this rebuttal comment, written by the previous owner.

Thanks for the link. It's quite a weak rebuttal however. For example "this inability to distinguish between unset and default values is a nightmare" is ignored. And, to me, "If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology" is the most damning criticism and that's also ignored. The so-called rebuttal basically amounts to "we're using it to make…

> this inability to distinguish between unset and default values is a nightmare

proto v2 and v3 let you distinguish set and unset default values (no idea about v1)

> If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology

It's a serialization format. It doesn't claim to be anything else. When people use it as their application's heap data model, they're misusing it. People are lazy and love to use their wire format as an internal data model (no one likes writing converters to/from the wire format), so this problem plagues everyone, but wire serialization is a fundamentally different problem from representing data within your application. When you conflate these problems, you get abominations like Java Serialization.

Re: Why OKRs might not work at your company

#132

Post by codemac »

keeptrying wrote: post #73

The downside of OKRs is that it incentivizes everyone to sandbag their efforts and then stick to that effort. Also no one is going to stick their neck out on goals which are ambiguous or lack clarity. There is just no incentive - in fact there's a massive dis-incentive. If you have a startup with less than 300 people and you have good communication and goal setting, don't use OKRs. Use KPIs and then nehlp your teams…

Considering High Output Management literally advertises Management By Objectives, I'm confused how that is a citation for your point about KPIs vs OKRs, they should not look that different.

If you're doing OKRs without some type of indicator, kpi or otherwise, I don't see how you're achieving key results.

Re: Why OKRs might not work at your company

#133

Post by User23 »

jdm2212 wrote: post #131
User23 wrote: post #128

Earlier quoted context omitted.

Thanks for the link. It's quite a weak rebuttal however. For example "this inability to distinguish between unset and default values is a nightmare" is ignored. And, to me, "If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology" is the most damning criticism and that's also ignored. The so-called rebuttal basically amounts to "we're using it to make…

> this inability to distinguish between unset and default values is a nightmare proto v2 and v3 let you distinguish set and unset default values (no idea about v1) > If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology It's a serialization format. It doesn't claim to be anything else. When people use it as their application's heap data model, they'…

> wire serialization is a fundamentally different problem from representing data within your application

I agree with this and the author of the criticism evidently does too, but his position is that failing to make this distinction indicates that protobufs are poorly designed. I don't see how "programmers are lazy and fail to work around the poor design" is much of a rebuttal.

In my mind a good design has one or more appropriate representations for each abstract type. The marshalled representation is certainly one, but one might also want more than one in memory representation of the same type depending on the problem domain. The old Lisp trick of representing an immutable linked list with a single contiguous block of memory is one example[1].

[1] https://en.wikipedia.org/wiki/CDR_coding

Re: Why OKRs might not work at your company

#134

Post by jdm2212 »

User23 wrote: post #133
jdm2212 wrote: post #131

Earlier quoted context omitted.

> this inability to distinguish between unset and default values is a nightmare proto v2 and v3 let you distinguish set and unset default values (no idea about v1) > If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology It's a serialization format. It doesn't claim to be anything else. When people use it as their application's heap data model, they'…

> wire serialization is a fundamentally different problem from representing data within your application I agree with this and the author of the criticism evidently does too, but his position is that failing to make this distinction indicates that protobufs are poorly designed. I don't see how "programmers are lazy and fail to work around the poor design" is much of a rebuttal. In my mind a good design has one or mor…

> failing to make this distinction indicates that protobufs are poorly designed

The author never offers any evidence that protobufs fail to make this distinction, just that people are lazy and misuse them.

You can't control what people do with generated types. I don't know how you'd even write a linter for Java or C++ that would know what an appropriate usage of protobufs is, to say nothing of writing such linters for every target language and then integrating them into every possible build system, CI framework, and code review application.

Those thorough Google code reviews you complained about earlier -- one of the things they taught me was not to use protos as the application data model. Read the proto off the wire, then convert it to another type or if you're in a hurry wrap it in another type that does validation checks and hides the proto accessor methods.

Re: Why OKRs might not work at your company

#135

Post by garyrichardson »

ck425 wrote: post #85
gregdoesit wrote: post #2

This is the key of the article: “ Those successful companies aren’t successful because they use OKR’s. They use OKR’s because it is designed to leverage the empowered product team model. And as I have tried to make clear with years of articles and talks, the empowered product team model is a fundamentally different approach to building and running a tech-product organization.” Amen to this. Google is an example compa…

Is Google success because it's a well run company in the first place? It's obviously not terrible (I'd personally love to work there) but life is a lot easier when you have the biggest cash cow ever plus a few smaller ones. In general I'm skeptical whenever anyone wants to copy Google as their advantages and disadvantages are so far removed from a typical company and always were. I don't think they're a particularly…

Back when it was popular to have a flat structure or no managers or whatever I started suggesting "Every type of management works until money gets tight." I think the principle still applies, but a more useful/general version is pick your structures and processes around resource availability (good vs bad times):

Good Times: pick something that can amplify abundant resources. There is going to be less bureaucracy around decisions and spending so move quickly and place lots of bets while you can.

Bad Times: pick something that works with meagre resources. You're going to spend more time justifying spending.

Re: Why OKRs might not work at your company

#136

Post by rukuu001 »

adamsvystun wrote: post #86
rukuu001 wrote: post #39

We just started using them. We're a small org that's mostly experienced consultants and contractors. They're energetic, proactive and independent people. We've adopted OKRs to basically get everyone pulling in the same direction, but without being prescriptive about how the work gets done. I'll report back at the end of the quarter on how it's working out, if anyone's interested :)

I am totally interested! But how will you report back?

I’ll reply here!

Re: Why OKRs might not work at your company

#137

Post by User23 »

jdm2212 wrote: post #134
User23 wrote: post #133

Earlier quoted context omitted.

> wire serialization is a fundamentally different problem from representing data within your application I agree with this and the author of the criticism evidently does too, but his position is that failing to make this distinction indicates that protobufs are poorly designed. I don't see how "programmers are lazy and fail to work around the poor design" is much of a rebuttal. In my mind a good design has one or mor…

> failing to make this distinction indicates that protobufs are poorly designed The author never offers any evidence that protobufs fail to make this distinction, just that people are lazy and misuse them. You can't control what people do with generated types. I don't know how you'd even write a linter for Java or C++ that would know what an appropriate usage of protobufs is, to say nothing of writing such linters fo…

> I don't know how you'd even write a linter for Java or C++ that would know what an appropriate usage of protobufs is

I wouldn't try to massage protobufs into satisfying that need, but I do agree that it's an area that should get more research and development. Looking at it from a linter perspective is making the problem way harder than it needs to be though. Verification is, generally speaking, a much more difficult problem than construction. For example it's much easier to construct a product of two large primes than it is to verify that a given number is a product of same. Anyhow, I'm not one of those people who thinks the theorists know everything and practitioners are all idiots, I'm just one of those people who think practitioners should learn from theorists and that, sadly, the former are often irrationally resistant to the notion. Not always though, TLA+ is a great example of a tool working software engineers use to build real systems that are theoretically verifiable.

I was being a bit cheeky about the code reviews. I do think that the reviewers delighted in the opportunity to be shitty to an unseemly degree, but I also agree that it was net beneficial. That said I did find the engineering quality in the SRE orgs was significantly higher than the SWE ones. Which is the complete opposite of every other company I've ever worked for.

Re: Why OKRs might not work at your company

#138

Post by tomhoward »

quanticle wrote: post #108
summerlight wrote: post #103

Earlier quoted context omitted.

Yeah, except one counterfactual scenario: Andy Rubin actually tried to sell Android to Samsung. Let's assume the deal was made; do you really think Android would grow into this dominant position at Samsung's hands? I know Samsung very well and I am 99.9% sure that it will be a miserable failure. All those acquired products were nearly non-existent compared to post-Google era. The founders may deserve some credits, bu…

You're assuming that those products weren't capable of reaching scale without Google's intervention. By that logic, Bill Gates should have sold Microsoft to IBM, because that is the only way Windows would have ever reached scale.

> By that logic, Bill Gates should have sold Microsoft to IBM

False analogy, because:

- Software provides the most utility, not the hardware, which is why IBM needed Microsoft more than vice versa, and why Android wouldn't have been nearly as much of a success if they'd been absorbed into a single phone hardware company.

- Google in 2005-2010 was a very different company to IBM in 1980; i.e., much more innovative, fast-moving and highly motivated to grow fast to rival the iPhone.

Re: Why OKRs might not work at your company

#140

Post by xtracto »

the_other wrote: post #126
xtracto wrote: post #76

Earlier quoted context omitted.

That's why as a manager I always set my teams okrs to be aligned with whatever crap business is going to place in the scrum stories. I've seen tech OKRs that are things like "reduce tech debt" or "decrease loading time" or "reduce downtime" but without hard tangible stories in sprints, it's just wishful thinking.

> That's why as a manager I always set my teams okrs to be aligned with whatever crap business is going to place in the scrum stories How could it be any other way (and work)?

It doesn't, but it is still done. A friend of mine who worked at IBM told me that they had "quarterly goals" that were stuff like "learn a new language" or "improve testing" or any other utopian idea, but their week-to-week sprint stories were completely perpendicular, so at the end of the quarter during the performance review the only people that achieved some of their goals were the ones that stayed to work on evenings and weekends (extra time) to do something related to their goals.
Post reply on HN