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

51–60 of 71 posts

Re: Making OKRs more playful using hill charts

#51

Post by koliber »

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…

The key results are not a problem just for you! You are hitting the nail on the head. Check out section 6 of this study ( https://arxiv.org/pdf/2311.00236.pdf ) - defining good OKRs is problem number 1, and data issues are the 2nd most cited concern!

I wrote a piece about the common issues that people face creating OKRs. There are a few common mistakes that people make which makes key results unmeasurable: https://koliber.com/articles/top-okr-mistakes

> the gradual accumulation of small fixes/hacks is not something you can put a metric on

I've done it before. On one team, we had a goal to reduce the number of linting errors and warnings from 18,000+ by 50% (while not growing the number of INGORES). The team was reluctant at first, because "it's only linting and it does not matter." But they relented and eventually started fixing things here and there. And the number started going down, albeit slowly. And over time we got the number of linting errors down to 18 (or something close), because people found time here and there to improve things. And the team learned how to use OKRs. And they put in place a style guide and an auto-linter. And they started using it so that the errors did not come back. And there were plans in place to put in more sophisticated style analysis and run another OKR agains that.

They literally matured in the code development practices way beyond just linting, just becuase of the relentless drive on one seemingly insignificant OKR.

This is just one example. You can use OKRs with engineering metrics to improve lots of things:

- fix the top 10 Jira tickets tagged with #techdebt

- reduce linting errors by 20%

- reduce number of functions with a cyclometric complexity of 10+ by 50%

- research 5 static code analysis tools

- increase unit test code coverage from 56% to 62%

You can go many different ways. I've helped engineering teams do this well, starting with deciding what makes sense to improve and getting buy-in, through defining the OKRs, building the system of measuring it, and most importantly, driving the OKR every week.

In the case you cited, with a bunch of hacks, I'd approach it like this:

- Create a OKRs like "Reduce tech debt".

- One of the key results would be "Identify 50 hacky places in code, and create Jira tickets for them" or something similar, by Jan 31st."

- 2nd OKR would be "Refactor XX out of the 50 hacky places identified by Jira tickets, by March 31st"

Pick numbers that work for you.

Re: Making OKRs more playful using hill charts

#52

Post by darkerside »

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.

A lot of people are mistaking my explanation for why people are interested in OKRs for an endorsement of OKRs. I think having goals is good, understanding how they type into the broader company mission is good, but being able to adapt is also good. OKRs:goal-setting::Scrum:agile

Re: Making OKRs more playful using hill charts

#53

Post by bootsmann »

koliber wrote: post #51
ninkendo wrote: post #31

Earlier quoted context omitted.

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…

The key results are not a problem just for you! You are hitting the nail on the head. Check out section 6 of this study ( https://arxiv.org/pdf/2311.00236.pdf ) - defining good OKRs is problem number 1, and data issues are the 2nd most cited concern! I wrote a piece about the common issues that people face creating OKRs. There are a few common mistakes that people make which makes key results unmeasurable: https://ko…

Whats the benefit of OKRs as a system in your example? You're essentially just creating a list of to-dos to check, no?

Re: Making OKRs more playful using hill charts

#54

Post by rfrey »

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…

If refactoring code doesn't lead to fewer defects down the road, or to faster feature implementation with less errors, or faster employee onboarding, or any other visible result, then maybe management doesn't want you to do it, and maybe it's reasonable to consider why.

Re: Making OKRs more playful using hill charts

#55

Post by dalyons »

bootsmann wrote: post #53
koliber wrote: post #51

Earlier quoted context omitted.

The key results are not a problem just for you! You are hitting the nail on the head. Check out section 6 of this study ( https://arxiv.org/pdf/2311.00236.pdf ) - defining good OKRs is problem number 1, and data issues are the 2nd most cited concern! I wrote a piece about the common issues that people face creating OKRs. There are a few common mistakes that people make which makes key results unmeasurable: https://ko…

Whats the benefit of OKRs as a system in your example? You're essentially just creating a list of to-dos to check, no?

Todos are binary, OKRs are (supposed to be) measurable continuously. Ie, we only did 5 of the top 10 tech debt tasks so the goal was 50% achieved

Re: Making OKRs more playful using hill charts

#57

Post by distortionfield »

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.

The entire shape up philosophy from Basecamp is honestly the best project management style I’ve been a part of in software engineering. The inversion of thinking around time (how long do I want to take vs. How long will this take?) is the most critical aspect of it.

Re: Making OKRs more playful using hill charts

#59

Post by Ancapistani »

Hmm.

This concept is something of a breakthrough for me, personally. I have fairly severe ADHD, and it took me about fifteen years in this industry to really find my place in it. My "hill chart" is more of a "valley chart".

In dealing with my own mental abilities, I've found that I've developed a toolset that has resulted in my strengths being in aggressively removing uncertainty and finding the optimal path to implementation - because implementation is the part that I struggle with.

Now I'm wondering if the very effective teams that I've been on have been comprised of people whose "charts" here overlap in a way where someone is always in their "downhill" portion while others encounter the "uphill".

Re: Making OKRs more playful using hill charts

#60

Post by vintermann »

d0gbread wrote: post #50
vintermann wrote: post #49

Earlier quoted context omitted.

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?

Well, since I recently quit, I suppose that's what I'm trying.
Post reply on HN