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

81–90 of 125 posts

Re: OKRs from a development team’s perspective

#81

Post by maxxxxx »

Seems this tends to go exactly the way Scrum and Agile did. If done correctly by the whole company it works well. But in most cases it will probably be a mandate by top management and the rest has to come up with some nonsense metrics and objectives and just play a game.

I think more and more any methodology will work if followed honestly and adapted to real world problems. In the end it's always the disconnect between what an organization claims to do vs what it really does. If that disconnect is small things are good, but in a lot of cases the disconnect is big.

Re: OKRs from a development team’s perspective

#82

Post by maxxxxx »

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…

Exactly. Individuals are far away from the actual organization goals. In my yearly review I have to categorize my achievements by stuff like "Supporting growth", "Fueling worldwide expansion", "Increasing customer satisfaction" and so on. I am very far away from any of these so either I indirectly support all of them or you could also say I support none of them.

Just filling this out makes it clear that most of the company is about bullshitting each other.

Re: OKRs from a development team’s perspective

#83

Post by codingdave »

loteck wrote: post #80
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.

In such a case, you have bigger problems than OKRs.

Re: OKRs from a development team’s perspective

#84

Post by Justsignedup »

As an engineer OKRs are a bit of a conflicting thing, and here's the reasons...

- I don't decide what projects come my way. Product or management decides that.

- My concerns are: "Is the company going to be around for > 6 months?" because if the answer is yes than my concerns are "In 6 months, make sure we don't hit a wall that will be a stop all development situation". I've seen it.

- OKRs are always going to be goals of the company. My question will always be: What can eng do to actually affect these OKRs? Are customers leaving due to bugs? Eng will prioritize bugs. Are customers leaving due to lack of features? Eng will build features. Is the company about to run out of money? Eng needs to build as much and as fast as possible and ignore any long-term problems because we need to get customers.

Basically either department heads need to take the current OKRs and transform them into department specific OKRs or they become meaningless. There needs to be engineering OKRs around things that engineering can affect. Not product OKRs which product will affect. Not sales OKRs which sales affects.

Example of a product OKR:

- increase customer conversion rates by 0.5% every 2 weeks for the next 2 months.

Example of an engineering OKR:

- enable product to A/B test

- enable product to measure more data points to make decisions to reach their OKRs

Re: OKRs from a development team’s perspective

#85

Post by sonnyblarney »

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…

"Most design decisions you make as a developer affect the value users get from your product, and therefore the churn rate."

Yes but probably not in a way that matters.

Churn will be decided by a few small, hopefully well targeted issues (including price and switching cost) and so it's really Product Marketing/Managements job. The Eng. should be to meet the expectations of Product.

Re: OKRs from a development team’s perspective

#86

Post by Jtsummers »

malyk wrote: post #75
Jtsummers wrote: post #35

Earlier quoted context omitted.

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

Those are system requirements and are not what you do with OKRs.

Re: OKRs from a development team’s perspective

#87

Post by strogonoff »

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?”

OKRs are designed to exist in levels, “trickling down” in a way that narrows them down more and more as they reach specific teams and individuals[0].

A goal such as “Increase customer retention” could be a legitimate higher-level objective. From key results on that objective, we get objectives for specific teams working on various aspects of the product.

(For example, “Reduce churn rate by X” likely isn’t going to be just about engineering; copywriters and others may be involved. Down the line at some point there may be an engineer’s personal key result such as “launch customer feedback collection system by X date”, or something else specific to circumstances.)

I believe that wholeheartedly adopting OKRs in this multi-level fashion is helpful even to companies with a just a few employees, and how objectives and results are translated across levels is a good measure of management health overall.

[0] Rick Klau talks about it in “How Google set goals” https://youtu.be/mJB83EZtAjc?t=1951 (2013)

Re: OKRs from a development team’s perspective

#88

Post by maxxxxx »

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…

My recommendation is to have a lot of meetings to create PowerPoint slides with some metrics that may be remotely related to what you are doing :-)

Re: OKRs from a development team’s perspective

#89

Post by sanderjd »

thinksocrates wrote: post #27
gipp wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: OKRs from a development team’s perspective

#90

Post by cortesoft »

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…

This hasn't been the case in my experience at a 200,000 person company. The OKR's I hear about are so far separated from what my teams work on, that it is impossible to even pretend our work relates to it.
Post reply on HN