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

31–40 of 125 posts

Re: OKRs from a development team’s perspective

#31

Post by staticassertion »

dvirsky wrote: post #28
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.

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 it, so that finance knows who to pay more.

Re: OKRs from a development team’s perspective

#33

Post by ltc5505 »

Would it kill people to expand the acronym on first use?

For example: "Most of the companies I’ve worked for in the last 5 years have used the objectives and keys results (OKR) system."

I'm not sure why this common practice in text is seemingly disappearing on the web.

Re: OKRs from a development team’s perspective

#34

Post by alexhutcheson »

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 you’re not making some effort to measure the value and impact of what you’re doing, then how do you know if it was the right thing to allocate your effort on? Presumably the new message queueing system had some effect on customer experience or developer velocity - can you try to measure that?

It doesn’t have to be perfect, but most teams would have a lot more impact if they spent some of their time getting at least very rough estimates of the impact of their current and future projects.

Re: OKRs from a development team’s perspective

#35

Post by Jtsummers »

swanson wrote: post #29
hirundo wrote: post #16

Earlier quoted context omitted.

> 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 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 for ideas) and your team is responsible for implementing the improvement or running experiments to see if it actually achieves the desired improvement.

That means your OKR will have to do with responsiveness to your customer or addressing the things your customer believes are associated with the poor no-show rate. Is your "patient reminder" system broken and failing to contact patients? Do you lack such a system? That's something you can address and control, so the OKR will have to do with that (server uptime, quality of service, features of the service, timeliness of changes to the service).

Re: OKRs from a development team’s perspective

#36

Post by lifeisstillgood »

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 believe it should work like this

- Board to CTO : Increase Retention (decrease churn)

- CTO to DevLeads: * Build a daily report emailed to the board showing 30 day moving average of churn

* Build a business event log - every time a user does something on the system log it to a easily queryable system (customer signs in, customer raises invoice or customer deletes widget) This can get very deep very fast. Start with Graphite / carbon and get more sophisticated later.

* hire a data scientist / convert DBA into one and find correlations between customers who churn and events in the log. Not logged in for 30 days looks like a good start.

* Write split testing into the (SaaS) app such that we can randomly segment customers at risk of churning (indicates by event activity) and see if we can keep them

* also add in "have you tried this feature emails", or "holy crap what do you mean the invoice page does not align right anymore"

All of these things (for a SaaS app) are doable projects for any development team.

This is of course based on the idea that the Board has told the CTO "fix this thing as top priority". If they have not that's their problem. The CTO should then go to the board and say "I am going to fix this thing as top priority"

Then we start the fun job of actually monitoring what developers do work on compared to what we planned to work on. Most times priorities chnage, legacy weighs us down and friction burns is.

Re: OKRs from a development team’s perspective

#37

Post by [deleted] »

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…

[deleted]

Re: OKRs from a development team’s perspective

#38

Post by asark »

ltc5505 wrote: post #33

Would it kill people to expand the acronym on first use? For example: "Most of the companies I’ve worked for in the last 5 years have used the objectives and keys results (OKR) system." I'm not sure why this common practice in text is seemingly disappearing on the web.

There's even a tag for it. Not that anyone cares about what HTML can do anymore.

Re: OKRs from a development team’s perspective

#39

Post by baxtr »

kradroy wrote: post #30

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

This is exactly what we do. We reserve about 25% of every team's capacity for "other" stuff, e.g. maintenance. The PMs/leaders have to acknowledge for that when they compile their OKRs.

Re: OKRs from a development team’s perspective

#40

Post by hirundo »

swanson wrote: post #29
hirundo wrote: post #16

Earlier quoted context omitted.

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

You build a mental model of the domain that guides the code you write. Often it amounts to "what would I want in that user's position?" aka the golden rule. As uninformed as that model may be it's better than none, and a place to start iterating on the model. In design it's usually better to be wrong than vague or random. And every line of code you write embeds a freight load of design choices, often as durable as concrete.
Post reply on HN