As a concrete example here you should be able to translate a new queueing system into something that has business impact.
Maybe the new system requires 75% of the servers the previous one did, leading to increased revenue. Maybe it’s quicker, resulting in customers experiencing better service, and so churn is reduced from the pool of people who said “I like it, but it’s too slow”.
A queueing system in itself isn’t of any value to the business as a whole.
Yes, but at some point there's serious diminishing returns on having every layer of the organization forced to rationalize their behavior this way.
If you're an average developer at a non-startup you've likely been asked to put together a queuing system. You didn't decide to do that work, and you probably shouldn't be spending weeks trying to gather the information you might need to justify that work.
Your job wasn't to figure out 13.2% of your customers opt out of your paid reporting services because they experience slow responses and unrecorded data.
Your job is usually much closer to -
PM - Can we make this service faster? We're losing customers on this feature because it's slow.
TeamLead - Probably, we can re-implement our queuing to be quicker and more reliable.
Dev - Ok, I'll investigate [x] queuing library or service
Then you should be spending your limited time and energy on actually producing that result. The technical task is usually quite complicated (ex: here's just the table of contents for RabbitMQ https://www.rabbitmq.com/documentation.html).
The justification for the work wasn't your job to put together (although asking sane questions is usually a good call). Your justification was simply "My PM/TeamLead asked me for it".
----
I sure as hell don't want every junior dev on my team going out and trying to tease out the intrinsic business value of every task I give them.
That's a waste of my resources. That doubles up the effort that I already expect my PM to be doing. That leads to disagreements about priorities when those junior devs don't have the context about why a business decision was made and either infer it incorrectly, or spend lots of time asking when it really just doesn't impact them all that much.
OKRs are normally set at the team level and above. IMO individual OKRs are an anti-pattern, unless you’re using them for individual development goals (complete this training, etc.)
Determining the business value of your team’s various goals should be your PM’s responsibility, with input and help from your team.
In your example interaction, the only missing piece is a more specific impact estimate. Rather than “We’re losing customers on this feature because it’s slow.”, you’d want your PM to say “If this feature was X% faster, we estimate that it would reduce churn by Y% per quarter, which is worth approximately $Z/quarter to the business.” Your team can then estimate eng cost to make that improvement, and see where the benefit/cost ratio falls relative to the other things you can be working on.
Maybe the new system requires 75% of the servers the previous one did, leading to increased revenue. Maybe it’s quicker, resulting in customers experiencing better service, and so churn is reduced from the pool of people who said “I like it, but it’s too slow”.
A queueing system in itself isn’t of any value to the business as a whole.