[deleted]
OKRs from a development team’s perspective
61–70 of 125 posts
Re: OKRs from a development team’s perspective
#62> I think it gives leadership the justification they need to declare that everyone is working towards the same goals, but I don’t think it leads to dev teams actually feeling like that’s true.
The more important thing is whether it's actually true, not whether dev teams (or leadership) feels it's true, no?
But the OP indeed seems to describe an environment where it is not actually true either.
Clearly, thought and planning is needed on how people work, in a way that will be directed to actually addressing OKR's. The OP offers suggestions about abandoning backlogs, and focusing weekly meetings on OKR's, which seem possibly beneficial, but probably not sufficient. I think it probably requires more fundamental shifts in how the whole organization works, which are a lot harder than just publisizing OKR's.
Re: OKRs from a development team’s perspective
#63Earlier quoted context omitted.
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 i…
If you have no idea where you're going, and no metrics at all, how do you reasonably pick any tasks?
So, clearly, you have some goal. It's likely also measurable. If you pick it so specific that you can't stick to it, yeah, OKRs are nonsensical. But "make money" or "increase conversion rate" or "find market fit" are clearly meaningful goals, no?
The difference from waterfall is that OKRs don't prescribe a "how". They describe a desired outcome. Guardrails within which you can be as agile as you want, just get some results.
Re: OKRs from a development team’s perspective
#64I 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…
Break it down into milestones. What's the minimum piece you could complete that would be usable by someone (even just a beta user to gather feedback)? What's the next incremental piece that would be useful after that?
You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback.
> My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home.
OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?
Re: OKRs from a development team’s perspective
#65We 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.
This just means someone somewhere has an unstated objective that things be maintained. Make them write it down, and then your 25% capacity supports that.
Re: OKRs from a development team’s perspective
#66My company has been using OKRs for several years now and the author perfectly describes what the engineering team does. We scan through our backlog, slap some nice OKR tags on items that are vaguely relevant, and then ignore the OKRs until the next quarter. The more politically savvy members of the team then spin some BS to make everyone buy that the work engineering is doing actually supports the OKRs. My personal o…
I agree. OKRs are renamed MBOs. This is extrinsic motivation and a giant waste of time. At best, it’s a process-heavy priorities setting/strategizing mechanism. At worst, it causes unnecessary employee anxiety and distraction away from current business needs. Any measurement that is a metric (goals in OKRs) will cease being a metric. It will be gamed.
MBO and OKRs are not (supposed to be) the same methodology. Their proponents decades back were of opposing views on how to manage.
Re: OKRs from a development team’s perspective
#67No mention of Key Performance Indicators? Why?
MBO and KPIs are different systems stemming from different philosophies about how to frame objectives and how to measure what matters.
Re: OKRs from a development team’s perspective
#68> 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…
Aside from transparency and common goal, the most beneficial side of OKRs is to allow any individual to ask "does what I'm currently doing move us closer to the KRs?" and "is this the most important thing that I can do to contribute to the KRs?"
Re: OKRs from a development team’s perspective
#69OKRs are merely a mechanism for generating public commitment to goals. You get to have a bit of a say what those goals are, but fundamentally they're about holding your feet to the fire after you spent a quarter bullshitting on Reddit because nobody in the organization has a foggiest clue about what needs to be done.
Understand OKRs for what they are, and you'll be a much happier developer. Don't treat them too seriously, use them as a productivity mechanism _for yourself_. Now, even if nobody knows what needs to be done, you can refer to your (approved) OKRs and do _that_, whether it makes sense a month after the quarter started or not.
I don't know how it is now, but at e.g. Microsoft in the 00's you'd set your goals once a year. A month later those goals were completely irrelevant to what actually needs to be done. And Microsoft is objectively one of the most successful software companies in the world. Waterfall, agile, OKRs or yearly goals, it doesn't matter. The reality is always dictated by circumstances. What matters is that every single thing I worked on while there makes money now, and a couple make billions a year.
Re: OKRs from a development team’s perspective
#70I'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 individual contributors set personal goals that supported their direct manager's OKRs.
No system is perfect, and this one had its annoyances. But it did tie everything from personal goals all the way up to the top-level corporate goals, which resolves many of the concerns from the article.