OKRs from a development team’s perspective • Hacker News Board

Re: OKRs from a development team’s perspective

#121

Post by simplecomplex » Sun, May 26, 2019, 5:03 PM UTC

I’m so sick of the software industry expecting developers to do the work of the entrepreneurs for them without any of the upside.

Why the fuck should I help the owner get rich by identifying how to grow their business by increasing conversion, retention, etc.? I don’t benefit at all.

At my current company we have weekly meetings where the owners tell us all the business metrics we should be driving and ask for ideas on how to increase them. I’ve learned to say “I don’t have any specific ideas right now.” because it’s insulting they expect me to do their work and get nothing for it.

Re: OKRs from a development team’s perspective

#122

Post by cstrasen » Mon, May 27, 2019, 12:17 PM UTC

sanderjd wrote: post #89

thinksocrates wrote: post #27

Earlier quoted context omitted.

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.

Yep, this would be good feedback up the chain. People above you should be working on breaking the company level goals into team and role specific ones. Edit: just to note that I have some other criticisms of OKRs, but having them be way too high level, broad, and not actionable should not be the problem.

Please share your criticism. I would be happy to get as much perspective on the topic as possible.

The problem I encountered was having, or the notion of wanting, a product roadmap which is produced from stakeholder, C-level, product- and IT team input parallel to OKRs. I feel this is an anti pattern. You have OKRs and they make your quarterly roadmap or you don't apply OKRs at all to the producing team.

Re: OKRs from a development team’s perspective

#123

Post by edmundsauto » Mon, May 27, 2019, 6:33 PM UTC

BurningFrog wrote: post #99

hobs wrote: post #41

Earlier quoted context omitted.

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

A lot of engineers talk about how business people should listen to engineers. A lot fewer engineers talk about how they like to listen to business people.

Engineers think (sometimes incorrectly) they could do the job of the business people, in a pinch. Business people know they can't do what an engineer does. This dynamic contributes to why business people respect engineering on engineering decisions, and why engineers don't respect business people on business decisions.

Re: OKRs from a development team’s perspective

#124

Post by hj7n » Tue, May 28, 2019, 2:38 PM UTC

dijksterhuis wrote: post #107

OKRs seem like a fancy new version of KPIs. My single biggest issue with KPIs is that, for the most part, in a large company, one (or even several) metric(s) cannot cover the whole story. They are useful for very specific targets. I’ve ended up working towards KPIs which I’ve known have zero relevance to improving service because they are (a) poorly defined (b) irrelevant to the actual problem (c ) force a metric to…

Hi Dijksterhuis,

Some organizations do indeed move from KPIs to OKRs. I personally think they are different tools for different purposes, and they could work well together.

I believe KPIs are a great tool to define and monitor your business as usual, whereas OKRs is more about realizing your ambitions and pushing the company further ahead.

If it helps, more info here: https://www.perdoo.com/blog/kpis-okrs-the-goals-that-drive-b...

Best, HJ

Re: OKRs from a development team’s perspective

#125

Post by alexhutcheson » Wed, Jun 05, 2019, 3:19 PM UTC

horsawlarway wrote: post #120

jon-wood wrote: post #109

Earlier quoted context omitted.

As a concrete example here you should be able to translate a new queueing system into something that has business impact. Maybe the new system requires 75% of the servers the previous one did, leading to increased revenue. Maybe it’s quicker, resulting in customers experiencing better service, and so churn is reduced from the pool of people who said “I like it, but it’s too slow”. A queueing system in itself isn’t of…

Yes, but at some point there's serious diminishing returns on having every layer of the organization forced to rationalize their behavior this way. If you're an average developer at a non-startup you've likely been asked to put together a queuing system. You didn't decide to do that work, and you probably shouldn't be spending weeks trying to gather the information you might need to justify that work. Your job wasn't…

OKRs are normally set at the team level and above. IMO individual OKRs are an anti-pattern, unless you’re using them for individual development goals (complete this training, etc.)

Determining the business value of your team’s various goals should be your PM’s responsibility, with input and help from your team.

In your example interaction, the only missing piece is a more specific impact estimate. Rather than “We’re losing customers on this feature because it’s slow.”, you’d want your PM to say “If this feature was X% faster, we estimate that it would reduce churn by Y% per quarter, which is worth approximately $Z/quarter to the business.” Your team can then estimate eng cost to make that improvement, and see where the benefit/cost ratio falls relative to the other things you can be working on.