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

OKRs from a development team’s perspective

zafulabs.com

Post reply on HN
Print view View original

51–60 of 125 posts

Re: OKRs from a development team’s perspective

#51

Post by sq_ »

hirundo wrote: post #16
swanson wrote: post #10

> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by 10% I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Someone needs to do the research, analys…

> How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Most design decisions you make as a developer affect the value users get from your product, and therefore the churn rate. Sure you can get more useful data by talking to customers, and you should seek it out. But even lacking th…

I think there's a dual problem here.

First, a developer putting themselves in the place of a user still may not be able to see all of the issues with their product because they are (not sure how to put this better) "too close to the work". It relates to something we talk about here on HN every now and then, namely that "technical people" often miss things that are hard for others because they just can't fathom that x thing that's easy for me could be hard for someone.

Second, I think that, in a lot of places, management makes it super hard for developers to get any data on problems other than general, abstract numbers with zero specifics included. I seems quite unreasonable to expect a developer who is being stonewalled on data or access to users by another business area to work with "our overall churn rate is x%, fix it" and actually figure out what's wrong and what needs improving.

Re: OKRs from a development team’s perspective

#52

Post by tmaly »

I saw the creator of OKRs, Andy Grove, speak years ago out at Intel in Oregon when I was doing an internship.

I don't recall the product development group I was in using them. Maybe they were implemented at a much higher level in the company.

Re: OKRs from a development team’s perspective

#54

Post by pbreit »

swanson wrote: post #10

> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by 10% I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Someone needs to do the research, analys…

I think OKRs are intended to mitigate the lack of customer awareness exhibited in this post. If you’re having that hard of a time linking your efforts to your paying customers, that sounds like a problem.

Re: OKRs from a development team’s perspective

#55

Post by hrktb »

jph wrote: post #32

OKRs are excellent-- I manage a repo about OKRs where you can see examples and contribute ides. The article author is exactly right: use OKRs to drive your weekly team meetings. https://github.com/joelparkerhenderson/objectives_and_key_re...

From the Google examples:

> a team is encouraged to set as goals about 50% more tasks than they are likely to actually accomplish.

> If a team scores significantly higher than that, they are encouraged to set more ambitious OKRs for the next quarter.

I lived through this in Scrum sprints. There is a baked in incentive to sacrifice some iterations every once in a while to ajust the average expectation, while keeping an overall positive look.

Otherwise without having used it seems to me that OKRs are another rather plain tool that works for clever organisations but fails when applied dumbly. Is there anything specific to it that makes worst case scenarii better ?

Re: OKRs from a development team’s perspective

#56

Post by Apreche »

I write software that is used entirely internally by the company. We are building something completely new from scratch that is not yet live. OKRs were recently introduced at our company. The only OKR I can even think of is "get this thing functioning and in production". Just a boolean. I wanted to come up with something measurable, but what is there to measure?

I don't understand how OKRs are appropriate for employees without the power to make business decisions. My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. I do not have power to decide anything with quantifiable results. If I did, writing OKRs and working towards them would be extremely easy.

If I did have any power to make business decisions one of the first things I would do is make any employee without any power exempt from having to even think about stupid OKRs.

Re: OKRs from a development team’s perspective

#57

Post by kenhwang »

My company has been using OKRs for several years now and the author perfectly describes what the engineering team does. We scan through our backlog, slap some nice OKR tags on items that are vaguely relevant, and then ignore the OKRs until the next quarter. The more politically savvy members of the team then spin some BS to make everyone buy that the work engineering is doing actually supports the OKRs.

My personal opinions of OKRs are that it's possibly the most cumbersome form of waterfall without many of the few benefits of waterfall. It's really a tool for making leadership feel good about being bad at their job.

Re: OKRs from a development team’s perspective

#58

Post by astral303 »

kenhwang wrote: post #57

My company has been using OKRs for several years now and the author perfectly describes what the engineering team does. We scan through our backlog, slap some nice OKR tags on items that are vaguely relevant, and then ignore the OKRs until the next quarter. The more politically savvy members of the team then spin some BS to make everyone buy that the work engineering is doing actually supports the OKRs. My personal o…

I agree. OKRs are renamed MBOs. This is extrinsic motivation and a giant waste of time. At best, it’s a process-heavy priorities setting/strategizing mechanism. At worst, it causes unnecessary employee anxiety and distraction away from current business needs.

Any measurement that is a metric (goals in OKRs) will cease being a metric. It will be gamed.

Re: OKRs from a development team’s perspective

#60

Post by yitchelle »

Apreche wrote: post #56

I write software that is used entirely internally by the company. We are building something completely new from scratch that is not yet live. OKRs were recently introduced at our company. The only OKR I can even think of is "get this thing functioning and in production". Just a boolean. I wanted to come up with something measurable, but what is there to measure? I don't understand how OKRs are appropriate for employe…

Some ideas of what you can measure...

Software is usually written to help reduce effort. Measure effort with and without the software. Reduce effort usually means better bottom line for the company which give you a great positive for your next performance review.

Meaure the usual software engineering metrics, ie defect count, defect closed, velocity, delivery timing etc.

I think that everything that we do in a company has a cost for the company. At the most basic level, you and I cost money as the company is paying us money for the work we do. You need to think from that perspective.

Post reply on HN