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

91–100 of 125 posts

Re: OKRs from a development team’s perspective

#91

Post by MrDunham »

hobs wrote: post #41
edmundsauto wrote: post #24

Earlier quoted context omitted.

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

I love listening to my engineers. They usually know how to solve something faster and more elegantly then I do.

But I'm someone who will learn enough Node/React/python to understand what can, and can't, be done.

Re: OKRs from a development team’s perspective

#92

Post by henrikschroder »

vikramkr wrote: post #5

If the items in the backlog aren't related to the OKRs, then it's possible that they should be thrown our with the new cycle like the author says, but I wonder if it could mean that the OKRs need to be changed in certain situations as well. If there are things the teams value in the backlog that aren't part of any OKRs, and the dev teams are in some sense closer to the product than upper management, then that input s…

In many companies, engineering puts out fires, prevents disasters, gets rid of tech debt, etc. In short, engineering does a lot of maintenance that is needed to keep the entire company afloat. If that work stops, the company will go bust.

It's such an obvious key objective, it should be in every top-level OKR, yet it almost never is, which means that there's nowhere the engineering department can slot in that work. And how do you measure it?

Re: OKRs from a development team’s perspective

#93

Post by ken »

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'm always amused by where one job ends and another begins. It seems strange to me that every web software company in the world is looking for "full stack engineers" -- you need to be an expert at everything from CPU instructions up to the CSS3 color module and its implementation in the browsers that our users are using -- but doing research and analysis of user behavior is off-limits. That's where we're drawing the line?

Re: OKRs from a development team’s perspective

#94

Post by jcrites »

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?

One approach is to keep in touch with customers and find out what their pain points are. Everyone should be interacting with customers to some extent. This could entail helping out with some support requests (escalations), or joining customer calls, going to conferences, etc. Listen silently to sales calls, or support calls with important customers - or be a named and introduced participant. If you have a mailing list or forums, keep tabs on that and help people. You can usually get an intuitive sense of what’s important to customers by interacting with them.

Sure, maybe it’s “not your job” to do these things, but a bit of time spent more than pays off in insight most of the time. If this is difficult to arrange, then the next best thing is to talk to the people who themselves speak to customers, and listen to what they have to say.

This isn’t a replacement for surveys and analysis, but I find it useful to have my own intuition as a human based on interacting with other humans.

It’s also good to be a customer or user of your own product. I strive to be in the position to use the things that I’m working on first-hand myself. If your product has an involved onboarding or setup process, then ideally everyone on the team should have gone through that setup themselves personally.

Most of the product design vision that I’ve developed for products I’ve worked on has come from a studied understanding of the customer problem and interaction with real customers. I think the best way to stay customer-obsessed is to ensure you’re interacting with customers, or are one yourself.

Re: OKRs from a development team’s perspective

#95

Post by robryan »

ken wrote: post #93
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'm always amused by where one job ends and another begins. It seems strange to me that every web software company in the world is looking for "full stack engineers" -- you need to be an expert at everything from CPU instructions up to the CSS3 color module and its implementation in the browser…

It comes down to allocating resources. If your developers are tasked with doing research on churn what are your product/ customer success people doing? Obviously depends on the size of the team on the product.

Re: OKRs from a development team’s perspective

#96

Post by robryan »

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…

Interesting that this often doesn’t go both ways, in startup culture. I mean in terms of the non technical team members picking up enough technical skill to better understand the technical side.

Re: OKRs from a development team’s perspective

#97

Post by marcinzm »

fivre wrote: post #74
tadasv wrote: post #46

Earlier quoted context omitted.

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…

The problem with domain specific tools for project management is that everyone has slightly different goal, priorities and requirements. So you end up with a mess of a tool that barely works (Jira) or one that's missing necessary features. Then someone decides they could do it faster and better in Excel.

Re: OKRs from a development team’s perspective

#98

Post by jwilliams »

strogonoff wrote: post #87
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 aspe…

To be honest, I've rarely seen this work well outside of Google.

Part of it is how the goals are translated. A business outcome trickles down to a specific technical one -- and a specific team and person -- which on the face of it makes sense, but it's surprising how often pursing that that derived outcome totally loses sight of the big picture.

It's similarly hard to map backwards, which can lead to a lot of the company feeling "mission accomplished", when the objective was still a total miss. That's a painful disconnect to have happen.

Re: OKRs from a development team’s perspective

#99

Post by BurningFrog »

hobs wrote: post #41
edmundsauto wrote: post #24

Earlier quoted context omitted.

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

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.

Re: OKRs from a development team’s perspective

#100

Post by hobs »

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.

Well, if they dont they get fired :) and I dont like to talk about the business doing things, just working this weekend because they didnt listen for the last six months.
Post reply on HN