Specifically on the OKRs - the objectives themselves should be inspirational. What is the end state that you're trying to achieve? The underlying key results is what will be measured, so that's where I'd drop any project-oriented activity.

It's very important that OKRs should not conflated with performance reviews. These are goals that the team sets for itself and is accountable to itself for. If you stray there, you'll end up with bad goals and lots of sandbagging. If the two is separated, it becomes very easy to understand another key principle - that you should set about 70% completion as the goal. Targeting 100% completion leads to easy, overestimated goals - it's nice to allow for and encourage extra effort without penalizing the team for directional changes. And speaking of business priority changes - change your KRs, why not? Objectives should in theory be higher level and not be randomized over a duration of one quarter (otherwise you have bigger issues), but in practice it can of course happen and again - so you don't hit an objective. As long as all are aware of the reasons, it shouldn't be a big deal.

Get together as a team and discuss openly what your next quarter's (or whatever) goals should be. I personally find more value in that conversation than in the resulting objectives/KRs. They are important to write down and revisit progress regularly, but that initial directional alignment is key IMO.

I'm not with Google, but I do like their OKR presentation if this is something you want to learn more about - https://rework.withgoogle.com/guides/set-goals-with-okrs/ste....

this is a challenging topic and there is no correct answer. even google doesn't know and from what i've heard, doesn't utilize OKRs in every team. at the end of the day, a developer is responsible for shipping story points at most companies. setting big product outcome and aspirational KRs is not part of their job description, and those are more for product managers. in our company, we focus on shipping a certain number of story points and conducting code reviews as repeating objectives every quarter. Also, every developer has some learning goals with KRs such as watch 5 new videos, attend 3 workshops, experiment with new frameworks, ect. We also have OKRs related to some initiatives that each developer is pushing such as reducing regression, increasing app load speed, adding more tests, and 15-minute quick product wins. please let me know if you have any questions.

Hi, what I do is set 1 soft skill (from a soft skill evaluation package), 1 project based (which usually do change) and then say 3 tech improvement skills or investigations into new techs (which may or may not pay off).

i think you're trying to use a tool that doesnt quite fit your team, no need to enforce something that the team is not comfortable with.

get a product owner & scrum master.