
Ask HN: How do you set goals for engineering teams - sevilo
Hi HN, our company adopts Google&#x27;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&#x27;s the proper way to do it. Conflicting information have been shared around with some saying your objectives shouldn&#x27;t be project oriented, because business priority could change. While others say your objectives should be where you spend most of your time on.<p>It always seems like it&#x27;s easier for marketing or sales to come up with measurable performance indicators like &quot;acquire x number of new customers&quot;. 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 &quot;tasks&quot; or &quot;project based&quot;?<p>Anyone Googlers or folks who have done similar goal setting that could help out?
======
romanhn
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...](https://rework.withgoogle.com/guides/set-goals-with-
okrs/steps/watch-googles-OKR-presentation/).

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

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

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

