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

21–30 of 125 posts

Re: OKRs from a development team’s perspective

#21

Post by residentfoam »

OKRs could drive some value BUT in my experience they are hard to maintain and update. Most companies keep their OKRs in huge spreadsheets, some even have dedicated people to maintain that insanity.

Teams then work with different tools, e.g: Marketing use Trello, Eng use Jira, you name it and now you have to trace back tasks from different tools to some OKRs defined somewhere in the cloud ... good luck with that.

It's nearly impossible to measure and reconcile progress made on team/sprint basis with OKRs therefore you just shovel random numbers in the spreadsheet and management is happy.

When an OKRs is updated good luck cascading the changes bottom up .

I have yet to find a company that has implemented OKRs in an effective way.

Most of the time managers themselves tell you : "just write something .. it does not really matter" hahahah and there you go ... At the end of the day people have to do OKRs but they keep asking themselves ... why ?

Re: OKRs from a development team’s perspective

#22

Post by staticassertion »

OKRs just feel like waterfall with "metrics" slapped on to make it sound legitimate. The idea that I can predict what I should be working on for a full quarter, and know how to measure it in advance, is inane.

Been working under this system for 1.5 years and I think it's nothing but a detriment. I did research into doing OKRs "right", watched videos, really tried to give it a fair shake, too.

Re: OKRs from a development team’s perspective

#23

Post by a_c »

dpcx wrote: post #2

We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful. I'll be reading and…

Am on a small dev team in a fast moving startup. To me, one of the O is to measure distractions and KR being

- having the amount of time spend on planned work vs adhoc work - source of distraction being measured (cross team requests, adhoc meeting)

Re: OKRs from a development team’s perspective

#24

Post by edmundsauto »

superfrank wrote: post #17
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'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. I hope no one is expecting every individual developer to know the numbers on churn, but I do think it's important that someone on the eng team would know that number. In my experience, some combination…

If churn is a priority from leadership (and it should be, for any decent sized product), I would expect everyone to understand the factors that play in. You need all your engineers to understand the strategic goals, they are often the best positioned to suggest ideas for fixing them (or can prioritize fixes that are higher impact to priority areas).

Re: OKRs from a development team’s perspective

#25

Post by avip »

maxxxxx wrote: post #13
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…

That’s a huge problem with the whole idea of providing value to the business. Some people can show real metrics but a lot of us are several layers away from anything quantifiable so either you have nothing to show or you have to make up some bullshit metric as I often see in resumes.

Slightly off, but the whole "business value" in IT resumes is proper a US thing. Cross the border and you're good with just mentioning what you did, sans the (often imaginary) "impact".

Re: OKRs from a development team’s perspective

#26

Post by gipp »

nlawalker wrote: post #14
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…

Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results. When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either…

If that's what your OKRs look like as a developer, then your company is doing them very wrong. They're supposed to be hierarchical, becoming more concrete as you go down the line. Your examples sound like top-level OKRs; mine are usually something like "internationalize feature x, launch in Y locales" or "Implement feature Z, measure effect on meric A".

Which is not to say the OKR system doesn't still have issues, they just look more like the ones discussed in the OP.

Re: OKRs from a development team’s perspective

#27

Post by thinksocrates »

gipp wrote: post #26
nlawalker wrote: post #14

Earlier quoted context omitted.

Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results. When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either…

If that's what your OKRs look like as a developer, then your company is doing them very wrong. They're supposed to be hierarchical, becoming more concrete as you go down the line. Your examples sound like top-level OKRs; mine are usually something like "internationalize feature x, launch in Y locales" or "Implement feature Z, measure effect on meric A". Which is not to say the OKR system doesn't still have issues, th…

Yeah, if that's how it supposed to work, then I've not been anywhere that does it right. We're always working ones like what I mentioned in the post.

Re: OKRs from a development team’s perspective

#28

Post by dvirsky »

staticassertion wrote: post #22

OKRs just feel like waterfall with "metrics" slapped on to make it sound legitimate. The idea that I can predict what I should be working on for a full quarter, and know how to measure it in advance, is inane. Been working under this system for 1.5 years and I think it's nothing but a detriment. I did research into doing OKRs "right", watched videos, really tried to give it a fair shake, too.

I look at them as a useful way to plan and estimate. It's okay if priorities shift or if you realise something will take longer, or that you actually need to work on something else right now and some KR will be pushed to next Q, etc. And it's perfectly fine not to meet some of your OKRs. I think of them as a compass rather than a paved road.

Re: OKRs from a development team’s perspective

#29

Post by swanson »

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…

It's the right attitude in spirit. But like how am I supposed to know how to decrease no-show rates at a clinic? How can I figure out how to increase harvest yields from autonomous tractors? Convert more enterprise sales accounts?

I know that the answer is: spend lots of time talking to customers, doing research, empathizing, etc. But then who is going to write the code while I'm doing all of that? It needs to get done, but I'm not sure why that is the job of the "development team".

Re: OKRs from a development team’s perspective

#30

Post by kradroy »

We started using OKRs this past year. I can't tell you what our current OKRs are. We even create "sub-OKRs" that align with the higher level OKRs. It feels like a pointless exercise, because we do what the author describes: slap labels on items in our backlog that sorta-kinda relate to an OKR.

The author's suggestions aren't terribly complete or practical. I don't know many teams who could just dump their backlog every quarter. You're going to have work that can't be related to OKRs. We do use the OKRs to drive our weekly meetings and sprint planning.

One suggestion I have is just to accept all work isn't OKR related and reserve capacity for that work. If some PM or manager complains, push back.

Post reply on HN