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

41–50 of 125 posts

Re: OKRs from a development team’s perspective

#41

Post by hobs »

edmundsauto wrote: post #24
superfrank wrote: post #17

Earlier quoted context omitted.

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

And then you have to do the hard thing, which is listen to the engineers (which is why most business folks are fine with keeping the siloing as is.)

Re: OKRs from a development team’s perspective

#42

Post by bluGill »

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…

If you are a good developer you understand the customer a little.

You are the first line of defense against things that seemed like a good idea, until they are implemented. You should pay attention to what you are building, once in a while (not every developer will have this happen) you will see something and go to your boss with a "stop, look at this, it we should cut our losses now because it is bad for the metrics".

You as an engineer know what is possible. I've seen several projects go from ideas that management/marketing thinks are too difficult so they don't bring it up to the top must have feature when an engineer who understands the customer sits down and writes it in a couple days thus making them realize their idea was actually easy if only they had asked.

Re: OKRs from a development team’s perspective

#43

Post by asark »

maxxxxx wrote: post #15
msoad wrote: post #11

Metric-obsessed management systems often miss on quality.

Or they invent a lot of bullshit metrics because in reality a lot of work is very hard to quantify.

The one place I worked that tried to do this, the developers mostly ended up doing things easy to measure. Turns out it's super-easy to measure views and shares so content marketing it is! Not exactly a good use of our particular abilities but it seemed to make everyone (who was pushing the OKRs) happy. Our real work could rarely be connected to any kind of OKR. Too hard to measure and, "this OKR thing seems cool, we should gather data for at least 2 years on X, Y, and Z for a baseline averaged across projects so we can create OKRs to improve them" didn't fly, obviously. So. Youtube videos and blog posts it was.

Re: OKRs from a development team’s perspective

#45

Post by nlawalker »

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…

That would be nice. My intuition is that this doesn't happen because the person in the hierarchy who translates "improve customer value by x%" into "internationalize feature x, launch in Y locales" is effectively taking responsibility for showing that the latter impacts the former, which is the problem I find to be intractable.

Re: OKRs from a development team’s perspective

#46

Post by tadasv »

residentfoam wrote: post #21

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'…

Shameless plug, but check out my tool for managing OKRs outside of spreadsheets if this is something you're looking for https://simpleokr.com

Re: OKRs from a development team’s perspective

#48

Post by leggomylibro »

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 once worked somewhere that had in-house customer service, and they gave developers the opportunity to spend a couple of days every few months working with a representative to respond to tickets and other first-line support stuff.

It was very valuable. It turns out that listening to people is a good way to figure out what they are frustrated with and what they want to see. Who'da guessed?

Re: OKRs from a development team’s perspective

#49

Post by the-pigeon »

Making decisions based off an any metric is very dangerous and the downfall of many products.

You MUST have a deep understanding of exactly what that metric is measuring and all of the things it doesn't take into a account.

For a concrete simple example. An A/B test may sure that forcing users to create an account before seeing shipping charges increases order completion by 10%. But then it turns out you've reduced return visits to the site by 30% and decreased overall conversion rates due to damaging that funnel.

Reality is very complex. Trying to boil everything down to a few numbers to make decisions based on seems like it simplifies things but often times you are just ignoring the complexities and flying blind by chasing metrics.

Re: OKRs from a development team’s perspective

#50

Post by dvirsky »

staticassertion wrote: post #31
dvirsky wrote: post #28

Earlier quoted context omitted.

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.

If it's ok to shift priorities 3 weeks into OKRs and push them to the next quarter why was it important to have them at all? Do you now need to measure the new work that's prioritized? It's totally fine (and encouraged, in fact) to not pass every OKR, but I don't see any point to them. All of the failures of waterfall that everyone has always been aware of, but with the additional work of stating how you'll measure i…

As I said, look at them as a compass - a map will be a better analogy maybe - this is what I want to achieve at the point in time I'm making my plans, and here's how I'm going to achieve it. As long as that doesn't change, it's useful to break down a vague goal into milestones and evaluate on occasion (my team does it every 2 weeks) how you're progressing.

But it's okay for that to change, and then you just write new OKRs.

Post reply on HN