Goal Setting

Base goal

For the base goal, I want it to be concrete and to describe business impact.

In this case, concrete means that there are objective criteria for determining whether or not the goal was met. Most of the time this criteria is a metric than can be measured; however, objective criteria like “deliver a presentation to a group of at least 5 people” are also sufficientI’ve been in an org that expects all goals to be of the form “move metric X from Y to Z.” I’ll do this where it makes sense, and won’t contort a good goal into that form if it doesn’t.

. A great test here is to ask the question “Can I fail at this goal?”In The Pyramid Principle, Barbara Minto offers a useful technique: “visual a real person actually taking the action, so that you can see what he will have in his hand, and then word the action to reflect this end product.” ([1996] 2018, p99)

Describing business impact usually means a goal that requires that a project was adopted by users and describes how they benefited from it. The main trap to avoid is goals about potential impact (e.g. “a customer could do X”) rather than actual impact (e.g. “a customer successfully did X”). A great description of business impact also includes a time horizon that is impactful to the business (e.g. “for Black Friday”). One trick to use here is to ask the thought experiment “when I write a promotion packet about this project in 6 months, how will I explain to the CFO that it was successful?”Minto points out another benefit of describing the end effect is that it becomes possible to see if the planned steps are actually sufficient to achieve it. ([1996] 2018, p 103)

One common difficulty I’ve seen here is goals that describe too much “what is being delivered” or “how” (e.g. “add support for feature X”). Instead, goals work better when they don’t articulate the what or the how and only articulate the “why” because it focuses energy on business impact and leaves space for flexibility on exactly what solution is used.

Stretch goal

For the stretch goal, I want it to reflect a growth area for an individual person. Usually this is a qualitative area that may not be measurable. I almost never want it to be an extension to the base goal (e.g. “complete in only X months” or “and also ship feature Y”). Instead, my goal is to pair someone’s known growth area with their active project so they see opportunities to improve. My trick here is to ask “what would be different if a more senior engineer aimed for the same goal?” (ideally not any generic senior engineer, but a specific one to whom this person looks up to).

Some ideas hereFor more ideas of areas where a more senior engineer might add value to a project, check out Project Phases.

:

• “Paul the peer wants to work with us again”
• “Leave behind great documentation”
• “Paul the peer presents this project to his own team”

One last note: I clearly indicate that the stretch goal is entirely optional and purely for someone’s growth. It is totally acceptable to only achieve the base goal and entirelly unacceptable to miss the base goal in lieu of the stretch goal.