18 ms·

Making OKRs more playful using hill charts

108 points by showmypost 3y ago

raverbashing 3y ago
Here's a better idea, leave OKRs only to the top levels and don't bog lower levels with it Then you can have "fun" with it as to find meaningful purpose since their life is missing it elsewhere
hardware2win 3y ago
When ive been introduced to okr Ive really liked this concept to the point that i started to use them in my private life But on the other hand i dont fully like them in my work life First my job forces OKRs amount and treats them equally So OKR like completing half day training and sharing the learnings has the same value as multi month engineering effort.
- Jare 3y ago
  I think that completing a training or sharing the results are, technically speaking, deliverables not results; that's why that doesn't work as a OKR. OKR would ask for the measurable impact that completing those things has on business behavior (user-facing KPIs, or internal productivity / value measures). My only encounter with OKRs sucked badly, and mismatches like that were one of the reasons.
  - hardware2win 3y ago
    We take trainings under Some technical skills increase or personal development objective And that completion of training or certs is what is measured
  - kqr 3y ago
    This is the problem with both SMART goals and OKRs. They purport to be meaningful by measuring results, but results are outside of one's control and subject to the inputs of lady Fortune! What we want to incentivise is not success, but the kind of behaviour that leads to success. But that, on the other hand, suffers even worse from Goodhart's law. Cedric Chin dug deeply into this dilemma[1] about a year ago. His suggestion is to frequently follow up on both behaviour metrics and result metrics to build a tacit understanding of how one is affected by another. This then allows you to focus improvements on behaviour metrics, which are mostly in your control. I have yet to try putting it to practise, but I like the idea. [1]: https://commoncog.com/goodharts-law-not-useful/ https://commoncog.com/goodharts-law-not-useful/
gardenhedge 3y ago
Things look like they're going downhill! But seriously, seems a bit pointless.
4pkjai 3y ago
I really don’t understand people who are interested in things like OKRs.
- darkerside 3y ago
  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.
  - quickthrower2 3y ago
    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. Measure stuff where it makes sense but not everything needs a measure (or things that don’t might be 0 or 1). Plan based on velocity that takes into account that you wont have planned everything. Measures are useful but also bullshit. There is no correlation between the measure and business success without intelligence. Even revenue is not a measure of success (I could sell half price bitcoins and have a lot of revenue!)
    - robertlagrant 3y ago
      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 https://dora.dev
      - quickthrower2 3y ago
        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).
l1am0 3y ago
A while back I did build a free & privacy friendly hillchart webapp. (No login) Might come handy when you wanna try out that approach https://www.hillchart.co/ https://www.hillchart.co/
- quickthrower2 3y ago
  Nice but doings something weird to internet history.
trabant00 3y ago
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!
- d0gbread 3y ago
  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.
  - vintermann 3y ago
    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.
    - d0gbread 3y ago
      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?
      - vintermann 3y ago
        Well, since I recently quit, I suppose that's what I'm trying.
bhawks 3y ago
At a certain scale you don't need to make OKRs fun and playful - there are enough VPs that all the OKRs read like an episode of Silicon Valley. If you're big enough to have company level OKRs that were written solely by folks that haven't opened a text editor in 10 years simply get out the popcorn and a can of beer. There are going to be some hilarious ones in there.
troelsSteegin 3y ago
> 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 hill chart inside out, you'd get a chart like a dartboard, where as things are more certain you are closer to a bullseye in the middle, and less certain you are further away. I could see looking at OKRs that way.
- js8 3y ago
  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.
- baq 3y ago
  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.
loughnane 3y ago
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.
- gcanyon 3y ago
  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 https://en.wikipedia.org/wiki/Situational_leadership_theory
khzw8yyy 3y ago
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.
- voshond 3y ago
  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
  - khzw8yyy 3y ago
    Because OKRs focus on one thing at the expense of everything else, while claiming this is a feature, not a bug.
mattferderer 3y ago
The link to the Basecamp article from several years ago should not be overlooked - https://basecamp.com/hill-charts 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.
- thex10 3y ago
  This was much nicer for me to digest compared to the original post, thank you for sharing!
- distortionfield 3y ago
  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.
  - kqr 3y ago
    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.
28304283409234 3y ago
Whenever my manager starts on OKRs I ask: Great! What are the C-Level OKRs? Conversation dies rather quickly then.
distortionfield 3y ago
I would highly recommend reading the Shape Up Methodology from Basecamp if this interested you: https://basecamp.com/shapeup https://basecamp.com/shapeup It’s short, but high quality and digestible.
Ancapistani 3y ago
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".
javier_e06 3y ago
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.
BrainInAJar 3y ago
we must imagine Sisyphus happy...
- dilyevsky 3y ago
  Ask and you shall receive https://twitter.com/UubzU/status/1729317510401425919 https://twitter.com/UubzU/status/1729317510401425919
willsmith72 3y ago
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
- maroonblazer 3y ago
  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?
deleted 3y ago
[deleted]
jdlyga 3y ago
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 from the people who work on the product day to day. It's also important not to load your product roadmap into OKR's and call it a day, or else you'll end up with teams of people who check boxes and software that barely makes it out of the driveway. Personally, I would encourage a reflection period after each series of OKR's. Not to just discuss outcomes amongst the senior leaders, but to collect intelligence on the ground, talk to devs, talk to users, talk to support reps, and decide what really should be the priority. But hey, what do I know I'm just a person who's comment you're reading.
- koreth1 3y ago
  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 fails its OKRs no matter how good a job everyone did. I've seen this be quite demoralizing, especially when meeting OKRs is tied to bonuses. The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.
  - d0gbread 3y ago
    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.

108 points by showmypost 3y ago

Here's a better idea, leave OKRs only to the top levels and don't bog lower levels with it Then you can have "fun" with it as to find meaningful purpose since their life is missing it elsewhere

hardware2win 3y ago

When ive been introduced to okr Ive really liked this concept to the point that i started to use them in my private life But on the other hand i dont fully like them in my work life First my job forces OKRs amount and treats them equally So OKR like completing half day training and sharing the learnings has the same value as multi month engineering effort.

Jare 3y ago
I think that completing a training or sharing the results are, technically speaking, deliverables not results; that's why that doesn't work as a OKR. OKR would ask for the measurable impact that completing those things has on business behavior (user-facing KPIs, or internal productivity / value measures). My only encounter with OKRs sucked badly, and mismatches like that were one of the reasons.
- hardware2win 3y ago
  We take trainings under Some technical skills increase or personal development objective And that completion of training or certs is what is measured
- kqr 3y ago
  This is the problem with both SMART goals and OKRs. They purport to be meaningful by measuring results, but results are outside of one's control and subject to the inputs of lady Fortune! What we want to incentivise is not success, but the kind of behaviour that leads to success. But that, on the other hand, suffers even worse from Goodhart's law. Cedric Chin dug deeply into this dilemma[1] about a year ago. His suggestion is to frequently follow up on both behaviour metrics and result metrics to build a tacit understanding of how one is affected by another. This then allows you to focus improvements on behaviour metrics, which are mostly in your control. I have yet to try putting it to practise, but I like the idea. [1]: https://commoncog.com/goodharts-law-not-useful/ https://commoncog.com/goodharts-law-not-useful/

gardenhedge 3y ago

Things look like they're going downhill! But seriously, seems a bit pointless.

4pkjai 3y ago

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

darkerside 3y ago
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.
- quickthrower2 3y ago
  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. Measure stuff where it makes sense but not everything needs a measure (or things that don’t might be 0 or 1). Plan based on velocity that takes into account that you wont have planned everything. Measures are useful but also bullshit. There is no correlation between the measure and business success without intelligence. Even revenue is not a measure of success (I could sell half price bitcoins and have a lot of revenue!)
  - robertlagrant 3y ago
    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 https://dora.dev
    - quickthrower2 3y ago
      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).

l1am0 3y ago

A while back I did build a free & privacy friendly hillchart webapp. (No login) Might come handy when you wanna try out that approach https://www.hillchart.co/ https://www.hillchart.co/

quickthrower2 3y ago
Nice but doings something weird to internet history.

trabant00 3y ago

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!

d0gbread 3y ago
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.
- vintermann 3y ago
  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.
  - d0gbread 3y ago
    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?
    - vintermann 3y ago
      Well, since I recently quit, I suppose that's what I'm trying.

bhawks 3y ago

At a certain scale you don't need to make OKRs fun and playful - there are enough VPs that all the OKRs read like an episode of Silicon Valley. If you're big enough to have company level OKRs that were written solely by folks that haven't opened a text editor in 10 years simply get out the popcorn and a can of beer. There are going to be some hilarious ones in there.

troelsSteegin 3y ago

> 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 hill chart inside out, you'd get a chart like a dartboard, where as things are more certain you are closer to a bullseye in the middle, and less certain you are further away. I could see looking at OKRs that way.

js8 3y ago
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.
baq 3y ago
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.

loughnane 3y ago

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.

gcanyon 3y ago
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 https://en.wikipedia.org/wiki/Situational_leadership_theory

khzw8yyy 3y ago

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.

voshond 3y ago
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
- khzw8yyy 3y ago
  Because OKRs focus on one thing at the expense of everything else, while claiming this is a feature, not a bug.

mattferderer 3y ago

The link to the Basecamp article from several years ago should not be overlooked - https://basecamp.com/hill-charts 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.

thex10 3y ago
This was much nicer for me to digest compared to the original post, thank you for sharing!
distortionfield 3y ago
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.
- kqr 3y ago
  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.

28304283409234 3y ago

Whenever my manager starts on OKRs I ask: Great! What are the C-Level OKRs? Conversation dies rather quickly then.

distortionfield 3y ago

I would highly recommend reading the Shape Up Methodology from Basecamp if this interested you: https://basecamp.com/shapeup https://basecamp.com/shapeup It’s short, but high quality and digestible.

Ancapistani 3y ago

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".

javier_e06 3y ago

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.

BrainInAJar 3y ago

we must imagine Sisyphus happy...

dilyevsky 3y ago
Ask and you shall receive https://twitter.com/UubzU/status/1729317510401425919 https://twitter.com/UubzU/status/1729317510401425919

willsmith72 3y ago

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

maroonblazer 3y ago
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?

deleted 3y ago

[deleted]

jdlyga 3y ago

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 from the people who work on the product day to day. It's also important not to load your product roadmap into OKR's and call it a day, or else you'll end up with teams of people who check boxes and software that barely makes it out of the driveway. Personally, I would encourage a reflection period after each series of OKR's. Not to just discuss outcomes amongst the senior leaders, but to collect intelligence on the ground, talk to devs, talk to users, talk to support reps, and decide what really should be the priority. But hey, what do I know I'm just a person who's comment you're reading.

koreth1 3y ago
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 fails its OKRs no matter how good a job everyone did. I've seen this be quite demoralizing, especially when meeting OKRs is tied to bonuses. The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.
- d0gbread 3y ago
  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.