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

41–50 of 71 posts

Re: Making OKRs more playful using hill charts

#41

Post by mgburns »

ninkendo wrote: post #31
koliber wrote: post #20

Earlier quoted context omitted.

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 qua…

"Cleaning up your code base to accommodate all the gradual accumulation of small fixes/hacks is not something you can put a metric on" - why not? generally the need to refactor is driven by something - getting too hard to make changes? productivity down? introducing more errors then we used to? In those cases improving productivity or reducing errors is the result we're targeting, and cleaning the code is the activity we do to achieve the result.

Re: Making OKRs more playful using hill charts

#42

Post by gcanyon »

loughnane wrote: post #40

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…

You might resonate with Situational Leadership. The basic premise is almost exactly what you say above about senior engineers. In SL they break it down into four stages:

    1. Beginner: you tell them exactly what to do and how to do it.
    2. Novice: you mostly tell them what to do and encourage them to learn and experiment.
    3. Experienced: you consult with them on what to do, and they mostly manage how to do it.
    4. Expert: you give them the goal and mostly just ask them how they'll approach it and how long it will take.
https://en.wikipedia.org/wiki/Situational_leadership_theory

Re: Making OKRs more playful using hill charts

#43

Post by khzw8yyy »

The problem with OKRs is that they are a religion. Once a metric is established it becomes a god to worship at the expense of all else, until the harmful effects of such single mindedness become painful enough that the old god is deposed and a new god put in its place. With the same myopic thought process. True leaders call this blindness "focusing on what's important".

Simplifying something as complex as an engineering team or a company down to a couple of variables cannot possibly model the real world. You can't say this out loud though, because this goes against established leadership culture. You can't be one of them philosophers. We've got to have achievable goals here!

Example: once upon a time a goal was instituted where tasks were supposed to be assigned to the engineer with the most experience in a particular area. Focus! Faster time to close a ticket! Happier engineers - they work on what they are good at!

See the problem yet? Meeting the goal actually made it so that there were a ton of bottlenecks. If an engineer was out sick the team lost an expert in a particular area. Engineers got bored working on the same thing day in and day out. And because the OKR killed knowledge transfer it became impossible to tackle a problem as a group.

And so the old metric was declared a problem and a new ridiculously limited model of the world was put in its place.

Re: Making OKRs more playful using hill charts

#45

Post by maroonblazer »

willsmith72 wrote: post #3

I think it could've used a real example, or a completed example in the template. Am I right that you idea is you're mapping the KRs to different points on the chart? Or is it about progress towards KRs? It seems hard to decide where a KR lies in terms of uncertainty/certainty when it's just a measure

Yeah, I'm struggling to make sense of this too. Is the point of the hill chart simply to identify the amount of uncertainty/risk associated with a KR?

Re: Making OKRs more playful using hill charts

#46

Post by thex10 »

mattferderer wrote: post #44

The link to the Basecamp article from several years ago should not be overlooked - https://basecamp.com/hill-charts Hill charts are a great way to keep people informed about a project status. I think they make much more sense than estimates.

This was much nicer for me to digest compared to the original post, thank you for sharing!

Re: Making OKRs more playful using hill charts

#47

Post by patrickmay »

quickthrower2 wrote: post #15
darkerside wrote: post #12

Earlier quoted context omitted.

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 can in theory make sense but they create a new kind of tension. Because they compete with the BAU work, the niggly things that come up mid quarter that you need to get done. Individuals need to resolve the dilemma, do what has to be done, or do what makes me look good. I think a new thing is needed at least for smaller teams. Something like adaptive goals. Roadmap a year, vaguely and plan the next 6 weeks. Measu…

BAU work should be covered in resource planning, not OKRs. The amount of time available to work on KRs should never be 100% -- it should be in the range of 60-70% to account for overhead, trainings, vacations, and unexpected issues that must be addressed.

Re: Making OKRs more playful using hill charts

#48

Post by voshond »

khzw8yyy wrote: post #43

The problem with OKRs is that they are a religion. Once a metric is established it becomes a god to worship at the expense of all else, until the harmful effects of such single mindedness become painful enough that the old god is deposed and a new god put in its place. With the same myopic thought process. True leaders call this blindness "focusing on what's important". Simplifying something as complex as an engineer…

Why exactly is this a problem of OKRs?

Making your efforts focused on a thing seems like a good idea, given proper research and discovery is done and the metric to improve is measurable and meaningful.

I think the criticism you are voicing is more down to a management style rather than OKRs. I’ve never would isolate my team members in areas and prevent knowledge being focused in one person. Always let the group tackle the problem and let them decide on who is going to work on it. Encourage pair programming and especially during the problem discovery, involve the entire team (when tackling a large, new problem).

Smaller stuff can be picked up by the same engineer. A bug fix here, a small adjustment there. But as soon as you introduce a big chunk of business logic, it’s important to bring along the team. I feel like that’s not what happens to you, but I don’t see this as a fault of OKRs

Re: Making OKRs more playful using hill charts

#49

Post by vintermann »

d0gbread wrote: post #38
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.

Helping the boss convince the market he made better decisions.

I often feel the frustration when I'm writing some data-crunching report-extraction thing, of the knowledge that the output of it will be some administrator squinting shrewdly at it and thinking himself better informed. Then he'll do pretty much whatever he would be doing anyway.

And that's the better case. I suspect in many cases they don't look at the information they ask for at all.

Re: Making OKRs more playful using hill charts

#50

Post by d0gbread »

vintermann wrote: post #49
d0gbread wrote: post #38

Earlier quoted context omitted.

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.

Helping the boss convince the market he made better decisions. I often feel the frustration when I'm writing some data-crunching report-extraction thing, of the knowledge that the output of it will be some administrator squinting shrewdly at it and thinking himself better informed. Then he'll do pretty much whatever he would be doing anyway. And that's the better case. I suspect in many cases they don't look at the i…

Maybe with a shitty boss and a complacent environment. Help them not squint at it and make a gut decision. Why not instead ensure the objective of the report is clear, there's a meaningful target around which to hinge on a decision, and present the data in a way that helps make the decision? And in lieu of the time or resources to do that, work on those problems?
Post reply on HN