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

Making OKRs more playful using hill charts

martin.sh

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Making OKRs more playful using hill charts

#31

Post by ninkendo »

koliber wrote: post #20
4pkjai wrote: post #9

I really don’t understand people who are interested in things like OKRs.

OKRs are a goal setting framework for non-trivial 3-12 month goals. Some people are self motivated and well organized, are great at communicating progress proactively to other stakeholders, an understand the idea of cross departmental alignment. OKRs will not help them. For everyone else, OKRs are a tool that can help accomplish those things. PS I actually like OKRs and after a lot of effort, learned how to make them…

The problem for me is the “key results” part of OKR’s. It means that if it’s not measurable, it’s not an OKR, and in too many organizations, if it’s not an OKR it’s not worth doing.

Cleaning up your code base to accommodate all the gradual accumulation of small fixes/hacks is not something you can put a metric on, at least not without pulling numbers out of your ass. But everyone agrees that you can’t really have quality software without doing this. But OKR’s would say that making nothing but tactical changes to ship features and never revisiting architecture is perfectly great. The incentives always seem to push you towards tech debt.

OKR proponents would say that revisiting architecture and paying down tech debt should be implicit and part of the process of achieving your results, but I’ve never seen it done. Or rather the only time I have seen it done is when someone tries to shoehorn the refactoring work into an OKR in order to justify it, making up bogus metrics, getting the OKR dropped because it’s not meaningful enough, and then just working on it anyway.

Re: Making OKRs more playful using hill charts

#33

Post by ekianjo »

darkerside wrote: post #12
4pkjai wrote: post #9

I really don’t understand people who are interested in things like OKRs.

Ever hear someone complain about big company bureaucracy? The bigger an organization gets, the more impossible it gets to manage it and keep people aligned towards effective and compounding goals. OKRs promise to help improve that impossible process. I'm not surprised at all that people are interested.

> OKRs promise to help improve that impossible process.

You mean like Google devs who kill projects faster than they roll them out

Re: Making OKRs more playful using hill charts

#34

Post by robertlagrant »

quickthrower2 wrote: post #28
robertlagrant wrote: post #22

Earlier quoted context omitted.

The existence of bad measures doesn't preclude the possibility of good ones, even though they won't be perfect. BAU activities, e.g. devops, can be measured in useful ways[0] as well. [0] https://dora.dev

Oh yes. But intelligence needs to be applied. OKRs turn measures into something like a sport, like soccer where those measure become the goal (beat the KR and get a bonus, or even just pressure on the KR and nothing else).

> But intelligence needs to be applied

I think this is an almost universal caveat.

> OKRs turn measures into something like a sport

No, I don't think that's true. People might do that, but they also do that to things that aren't OKRs. It's great to critique OKRs, but not by comparing them to a hypothetical perfect world.

Re: Making OKRs more playful using hill charts

#36

Post by d0gbread »

koreth1 wrote: post #13
jdlyga wrote: post #5

Sure, OKR's can help keep multiple teams aligned on business and product goals. And that's an advantage that's too big to ignore. But the problem with OKR's is too often, they're handed down by well meaning people multiple levels removed from the day to day software development work. There can be a lack of ground truth. But too often they miss the bottom-up intelligence, creativity, and engineering needs that comes f…

The biggest problem I've seen with OKRs as an engineer is that the objectives are business goals the engineering team has little or no ability to influence. Like, an objective of "onboard 5 new large customers" makes sense for the business, and the engineering team could definitely screw it up by, say, building a system that can't scale that high. But when the sales team only closes 3 new deals, the engineering team…

Or building things that help retain current customers vs acquire new customers so sales has something to sell.

The bigger problem as I've seen it is engineers that don't see themselves as part of the business, either because of the culture or personal choice around lack of focus on soft skills.

All too often engineers spend zero time understanding the market and customers, and scaled agile, as it's typically implemented and managed, definitely doesn't help.

Re: Making OKRs more playful using hill charts

#37

Post by js8 »

troelsSteegin wrote: post #26

> Progress is more like a hill than a straight line. Uphill: figuring things out (uncertainty, unknowns, problem-solving). Downhill: making things happen (certainty, confidence, execution) This is the first time I've seen a "hill chart" and I found it a little confusing to look at - maybe because the shape looks like a normal distribution, where "the sides" are more uncertain and not less uncertain. If one turned a h…

I kinda like the hill chart but TBH it shouldn't look like normal distribution, but more like a half-circle. In my experience, most (SW) projects (at all levels of granularity) are S-curves (and not straight lines like in burndown chart). You're slow at beginning, because you're learning the domain and finding good abstractions. You're slow at the end because you're working out the kinks and fixing little details. The fastest progress is in the middle. So if the hill chart is supposed to show the difficulty in progress, it should look kinda like a derivative of inverted S-curve.

Re: Making OKRs more playful using hill charts

#38

Post by d0gbread »

trabant00 wrote: post #16

I can't help feel infantilized by these games. It doesn't make unwanted things easier to swallow, quite the opposite. "Here comes the airplane!" is a little game that I like to play with PMs so they get to enjoy me punching them in the face. Aren't we all having fun now, how wonderful!

If it helps, it's not for you.

Execs can't do this themselves because they don't have the information they need, and are trying to be predictable and compete in a market. So think about it as an ELI5 exercise where you're infantilizing up, or as it's more commonly and professionally referred to, managing up, or more plainly, helping the business make better decisions.

Re: Making OKRs more playful using hill charts

#39

Post by baq »

troelsSteegin wrote: post #26

> Progress is more like a hill than a straight line. Uphill: figuring things out (uncertainty, unknowns, problem-solving). Downhill: making things happen (certainty, confidence, execution) This is the first time I've seen a "hill chart" and I found it a little confusing to look at - maybe because the shape looks like a normal distribution, where "the sides" are more uncertain and not less uncertain. If one turned a h…

Going up is difficult but going down takes a lot longer than expected from the top, usually; so yeah, the hill should be skewed to the left and have a fat right tail.

Re: Making OKRs more playful using hill charts

#40

Post by loughnane »

The most productive teams I've run have been when using OKRs or OKR-like schemes.

They're hard to get right though. Its easy to add too much process, make planning too much of a burden, or not regularly check-in.

One concept that's helped lubricate things is "task-relevant maturity", which I first heard about in Andy Grove's _High Output Management_. It's a gross phrase but essentially means to that people who could accomplish a goal in their sleep need less help than someone who is facing something new. Accordingly, I've cut more slack to the former when laying out OKRs.

Its hard to overstate how valuable that is. Senior engineers who've been in the same space for eons chafe at having to do the same pedantic things as a junior engineer, and rightly so--they've seen a million managers and fads come and go.

To the point of the article I _really_ like the concept, but I'm wary of demanding another step for fear that it won't take. Usually I try something out by myself but keep it optional for a year or two---or forever.

Post reply on HN