As analogies go the hill implies a peak, there is no such thing.
As a developer there a better ones:
Pirates navigating uncharted seas. Explorers finding their way in an abandoned coal mine. Chutes and ladders.
Making OKRs more playful using hill charts
61–70 of 71 posts
Re: Making OKRs more playful using hill charts
#62The 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.
Yup, that is so obvious in hindsight but I hadn't thought of it that way before. "We're willing to spend this much time, will you be able to do it?" is a much easier question both to ask and answer than "how much time will it take?"
It also encourages collaboration over adversarial negotiation.
Re: Making OKRs more playful using hill charts
#63Earlier quoted context omitted.
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 implemen…
> All too often engineers spend zero time understanding the market and customers,
From my perspective the problem is that companies invest zero time in training engineers about the market and companies, and instead just treat engineers like assembly line cogs that produce business value on-demand.
Re: Making OKRs more playful using hill charts
#64Earlier 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…
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.
It does all of those things.
But it’s really really really hard to quantify it in a measurable way. Which is what OKR’s force you to think about: what is the metric, what is its current value, and what is your goal for the metric, so you know whether you achieved it?
Can you quantify “faster employee onboarding”, reliably? Can you graph it over time? Can you quantify “faster feature implementation” in a way you can actually measure that isn’t sensitive to the fact that all features are different?
Re: Making OKRs more playful using hill charts
#65Earlier 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…
"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 activit…
> 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.
Right, but please read the first sentence of my post. It’s the “key results” part that’s hard. Because you need to quantify all the benefits you’re targeting, giving them a number, so that you can show whether you completed your goal or not. If you say “productivity will go up”, you have to put a number on the current productivity, then give regular reports on what happens to that number after the refactoring. What do you pick? Number of PR’s merged per day? That’s probably going to go down, because most of the PR’s today are small tactical band-aid fixes. So do you say the number of PR’s merged should go down after the refactoring? That could just as easily be because the refactoring made things worse and everything’s so broken that nobody can make changes. So PR’s merged is a shitty metric. What else? Bugs filed? In a product where you’re growing users you’d probably expect them to go up due to increased usage, so any benefit to refactoring is likely going to be lost in the noise. Line of code count? Please.
More often than not people just pull whatever metric they want out of their ass to make the case for what they’re trying to accomplish, and cherry pick things so that it looks better after the effort. But it’s against the spirit of OKR’s to do this, which is why OKR’s are bad for anything “fuzzy” like refactoring. You have to shoe-horn work that everyone agrees is worth doing, into a framework that isn’t designed for refactoring work, to make the case.
Re: Making OKRs more playful using hill charts
#66Earlier 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…
Your advice could be generalized into:
- Take whatever it is you want to do and break it down into N jira tickets
- Make an OKR saying “solve these N jira tickets by date X”, with the result indicator being “number of those particular jira tickets solved”
- At the end, your OKR percentage is some fraction of N
This works regardless of what the thing you’re trying to do is. It goes against the spirit of OKR’s which is to use metrics that matter to the business (number of users onboarded, page load time, conversion percentage, etc) to justify work. That’s what the “results” in OKR’s are supposed to mean.
Re: Making OKRs more playful using hill charts
#67The 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 tackl…
Because OKRs focus on one thing at the expense of everything else, while claiming this is a feature, not a bug.
Re: Making OKRs more playful using hill charts
#68Earlier 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…
Your advice could be generalized into: - Take whatever it is you want to do and break it down into N jira tickets - Make an OKR saying “solve these N jira tickets by date X”, with the result indicator being “number of those particular jira tickets solved” - At the end, your OKR percentage is some fraction of N This works regardless of what the thing you’re trying to do is. It goes against the spirit of OKR’s which is…
Correct. Breaking something into N tickets is one way of approaching OKRs.
It does not go against the spirit of OKRs. Reducing tech debt and making a metric out of the number if Jira tickets can work, and is a workable approach if there is business value from reducing tech debt. If you can align it to "reduce page load time", why would you not use it? Don't conflate business value with how you measure things. OKRs should align to business value. OKRs should be measurable. You can have things aligned to business value that are harder to measure. You can have measurable things which provide little business value.
There is no rule that says that you can not measure the number of tasks that get completed as part of an OKR. It's true that the smaller N gets the less sense it makes, and that N=1 is a binary goal. OKRs are better for larger N numbers, as those show progress better. Going from memory, "Measure What Matters", the OKR bible, has examples of OKRs where the goal
Nothing is stopping you from using OKRs for small N. But I have seen people come up with all sorts of excuses why "it won't work" so your milage may vary. My suggestion is always "try it fullheartedly before you knock it."
The generalization won't work once N is large, or is continuous, or does not make sense as separate Jira tickets. Luckily, it does not need to and you can track such metrics without the help of a ticketing system.
Examples that won't work as Jira tickets but can be good OKRs, if they align to a business goal:
- improve the Core Web Vitals cumulative layout shift (CLS) by 0.3 points. (can align to "reduce bounce rate" as CLS affects the perceived load time and quality)
- increase test coverage by 15% (can align to "reduce churn", if churn is caused by poor product quality, and test coverage can improve quality)
Re: Making OKRs more playful using hill charts
#69Earlier quoted context omitted.
"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 activit…
> 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. Right, but please read the first sentence of my post. It’s the “key results” part that’s hard. Because you need to quantify all the benefits you’re targeting, giving them a number, so that you can show whether you completed your goal or not. If you say “productiv…
You are hitting on an important and difficult aspect of OKRs. Getting the alignment between what you can affect (the leading indicator) and what the outcome is (business value).
It's not an exact science. You can make pro and con arguments against different things that could conceivably be measured. This is where experience and strategic thinking help.
You can always come up with a risk or a reason why a particular measurement won't affect the desired outcome. You will be more right on some and less right on others. However, throwing out the entire OKR approach because you can not be sure is not correct either.
Re: Making OKRs more playful using hill charts
#70Earlier 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?
Key results can be more granular and less granular. Think of it as a continuum. Some are continuous:
- Improve the time to first byte for the homepage by 500ms.
This one is continuous, because time is continuous. Realistically it will be quantized into milliseconds, but that's nitpicking.
You can get less granular:
- solve 500 linting errors
This one is kind of continuous, but there are 500 distinct steps. Each week it is feasible that you can solve a handful, and can see movement and improvement.
- add 5 unit tests to XYZ module
Now we are getting much less granular. It is a checklist of 5 TODOs. But you can track the progress. Its unlikely each week you will make an improvement, but on some weeks you need to if you want to hit "5" by the end of the quarter.
- hire a new DevOps engineer
This is a binary, checkbox, or hit-or-miss key result. Sometimes they makes sense. It's not great if they make up the majority of the key results on an OKR. The good news is that you can make it more granular. Create a plan for hiring an engineer. Break out the steps, assign a percentage to each step, and track it as a 0-100% key result. This way, as you write a job description, post it, create a pipeline, review resumes, and hold interviews, you can track and share the progress.