Ask HN: How do you set goals for engineering teams | Hacker News Reader

Ask HN: How do you set goals for engineering teams

17 pointssevilo4 comments

Hi HN, our company adopts Google's OKR (Objectives and Key Results) framework for goal setting. While we have a general agreement that goal-setting is important, we struggle to understand what's the proper way to do it. Conflicting information have been shared around with some saying your objectives shouldn't be project oriented, because business priority could change. While others say your objectives should be where you spend most of your time on.

It always seems like it's easier for marketing or sales to come up with measurable performance indicators like "acquire x number of new customers". But with engineering teams, our backlog and projects are determined by company vision and product planning. How can we set goals to drive the product without turning everything into "tasks" or "project based"?

Anyone Googlers or folks who have done similar goal setting that could help out?

View on HN

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.

Reply on news.ycombinator.com