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

71–80 of 125 posts

Re: OKRs from a development team’s perspective

#71

Post by jofer »

So far, all companies I've seen that use OKRs operate something like this:

Start of quarter - Management: We need to increase X. Dev: Okay, here's how I'll break that down... (key results)

One month later - Management: Everything's changed... Y is the top priority now! Dev: Okay, that means we should focus on fozbuzzles.

One month later - Management: Oh, man, what we really need to focus on is Z! Dev: Alright, we can do that if we de-emphasize X and Y. Let's get Z done!

End of quarter - Management: You didn't meet any any of your OKRs other than Z! Dev: ...but you told me to drop X and Y...

Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change.

Frankly, the start-of-quarter OKR system is incredibly disheartening... None of my major accomplishments or the primary focus of my work ever winds up being recorded, as only the items set at the first of the quarter are evaluated.

I've worked at other places (outside of tech) where the emphasis was on recording what you worked on and why at the _end_ of the quarter. In my experience, it's smoother for everyone. I'm a bit surprised at the focus on quarterly, pre-set OKRs in tech... It seems like a more adaptive process would be better for everyone.

Re: OKRs from a development team’s perspective

#72

Post by phiggins »

tadasv wrote: post #46
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

we've been looking at gtmhub.com for a minute, are you considering a Jira integration?

Re: OKRs from a development team’s perspective

#73

Post by devit »

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…

Also what's the point of arbitrary numbers like "10%" and "+5"?

You should obviously increase lifetime customer value to the optimal value (after accounting the cost of increasing it) and likewise for churn rate.

Re: OKRs from a development team’s perspective

#74

Post by fivre »

tadasv wrote: post #46
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

Do you have a companion tool whose purpose is to convince Excel devotees that modern, domain-specific tooling exists, and that they should stop pushing Excel because it's terrible for many tasks?

My problem is less that no tools exist to manage things outside of spreadsheets, but more that older management tends to take the position of "Jira (or whatever) is complicated and I already know Excel, and I'm in charge so we're using whatever doesn't require me to learn something new".

Re: OKRs from a development team’s perspective

#75

Post by malyk »

Jtsummers wrote: post #35
swanson wrote: post #29

Earlier quoted context omitted.

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

One thing with OKRs is that the key results are supposed to be in your control and responsibility. You don't have control over the no-show rate, but someone has responsibility to improve that as part of their own role. If that has made it to your team, then something is probably broken. Most likely that no-show rate is part of an OKR for clinic managers or someone else. They'll come up with ideas (or consult with you…

But you can potentially help the no show rate.

- Send an email to the person 2 days before their appointment

- Text them the morning of their appointment

- Build something into the CRM of the front desk that reminds them to call people the day before an appointment

- send a pre-generated google directions result to the patient N minutes before the appointment

I could go on for hours here. The job of a developer, at least in the startup world, is to understand the objective of their team and contribute to figuring out ways to reach their objective. It is not just to code up tickets that are put in front of them.

Re: OKRs from a development team’s perspective

#76

Post by cpeterso »

superfrank wrote: post #9

This put my thoughts on OKRs into words better than I ever could. At my last two companies, I've been beating the drum that the closer to an individual level you get the less useful OKRs are. The backward process of, "we know what we are going to do, how to we make it fit the OKR formula" drives me insane. Personally, I actually like OKRs at the organization or large sub org level. I think they are great at getting e…

Spotify decided to stop using OKRs for individuals for these same reasons. They wrote about their experience here: https://hrblog.spotify.com/2016/08/15/our-beliefs/

Re: OKRs from a development team’s perspective

#77

Post by superfrank »

jofer wrote: post #71

So far, all companies I've seen that use OKRs operate something like this: Start of quarter - Management: We need to increase X. Dev: Okay, here's how I'll break that down... (key results) One month later - Management: Everything's changed... Y is the top priority now! Dev: Okay, that means we should focus on fozbuzzles. One month later - Management: Oh, man, what we really need to focus on is Z! Dev: Alright, we can…

> Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change.

I think there are two types of priorities, "fires" and "nice to haves".

Fires are high priority, unpredictable, and often need to be solved quickly. This is things like "our databases crash every morning" or "our AWS bill is too high and going to put us out of business".

Nice to haves can still be needed, but they tend to take a back seat when a fire happens. Additionally, their priority tends to be much more subjective. This is things like "Our build process takes too long" or "our deploy process has too many manual step which leads to human error".

OKRs tend not to last a full quarter because any tasks/priorities that you can schedule and make fit nicely into a 3 month period are "nice to have"s. I'm not saying they don't matter, but the timeline to get them done doesn't really matter so things get delayed or moved around.

On the flip side, you can't schedule fires and you usually can't delay them either. The things that actually important enough that they can't get delayed tend not to fit the OKR framework.

Re: OKRs from a development team’s perspective

#79

Post by loteck »

madrox wrote: post #18

Leadership is hard. Gaining alignment around goals is hard. Even if you state a goal, getting timely execution is really hard. OKRs are great in that they are specific and measurable, so you can have a concrete conversation on if performance is adequate. The problem with OKRs is goals can be hard to quantify, so it's attractive to simply make OKRs out of things you CAN measure. This is why we get companies that optim…

Completely agree, this post looks classically to me like a team toiling under leadership that picked OKRs as the measurement system for employees but not for leadership.

How many OKR rollouts are plagued by lack of adoption in the C suites? Who here is shocked to find a system is malfunctioning because employees are trying their best to engage with it, but leadership can't or won't do their part? OKRs in particular are hugely reliant on leadership defining goals for others to align with.

Measurements and progress are cultural. It either starts and continues from the top, or it's defective.

Re: OKRs from a development team’s perspective

#80

Post by loteck »

codingdave wrote: post #70

I've only seen this in large companies, not startups or software shops, but it was never a single layer of OKRs. It was a set at each management level. The CEO would define the top-level OKRs. Their direct reports would ask themselves, "How can I contribute?", and build a more detail set of their organizations OKRs, that rolled up to support the CEOs. Every layer of management down the chain did the same. And the ind…

The trick here is: what happens if the CEO is unwilling to pin herself down to specific goals, for any reason, but especially because she has no goals or is afraid to be seen failing those goals?

Either leadership doesnt engage with OKRs, tasks are deliberately misinterpreted as goals, or unmeasurable goals are set. The rest of the company's OKRs then follow this example, and everyone suffers.

Post reply on HN