30 Oct 2020

Goal playbook

Structure quarterly goals to help teams deliver and mitigate risk.

Straight from my playbook, here are the fields you want attached to each goal your teams take. You can see this in action in the my OKR tracker template.

When you have your teams craft goals during the goal planning process and encode them in your goal tracker (excel, JIRA, or Azure Dev Ops), make sure they fill out all of the following fields:

Ownership (3 fields)

  • Engineering Owner
  • Product Owner
  • UX Owner
    These are used to drive accountability and manage the ritual of execution review. At least one needs to be filld out. As engineering typically owns execution, you usually see the Engineering Manager as the Engineering Owner and their PM if their is one in Product owner.

Priority

See the SFELC speech for more info about priorities, but roughly:

  • P1 - Must get done
  • P2 - Should get done
  • P3 - Could get done

P1 OKRs must get done for the quarter. We will move resourcing around to make them happen. These are either top-down initiatives, critical external commitments, strategic efforts, or primary KPIs.
Teams should have only a handful of P1s, because one of the key ways we ensure delivery when things go wrong is to kill other, lower priority goals. They are the marquee KRs for the team and get extra attention and visibility from leadership to ensure success. They are absolutely critical for driving our culture of quarterly commitment.

P2 OKRs are important to have (key initiatives). They should get done and should only be sacrificed for P1 initiatives.

P3 OKRs are stretch goals for the team.

Scoring Criteria

See Key Result Scoring Criteria for more information on this field - the goal is to be explicit up front with what success looks like and leave room for stretch when appropriate.

Goal status:

One of the most critical aspects of engineering execution is managing risk. In order to cultivate the right risk mindset, we only have two possible states for goals (or Key Results if you are using OKRs) that are active in the quarter:

  • Goals are On Track (green) if they are on track to be delivered for the quarter
  • Goals are At Risk (red) if they are at risk to be delivered for the quarter

On Track means:

  • Scoping well understood and complete timeline landing within the quarter with some margin for error
  • Dependencies accounted for (with commitments from dependent teams)
  • Known risks accounted for - technical and personnel (e.g. maternity leave, vacation, hiring delays)
  • >80% confidence in delivery

At Risk means:

  • At risk (20% or higher chance) of missing the quarter
  • Critical dependencies without clear commitments from other teams / functions
  • Barely landing in the quarter with no margin for error
  • Not started or still in “planning” but working backwards from the date it will miss given other constraints

There are additionally a few terminal states for Goals:

  • Goals will be marked as Completed when finished
  • Goals can be marked as Cancelled if we have aligned across the organization that the goal is no longer relevant. This is not used for goals we are simply failing to achieve.
  • If we are unable to achieve the goal for this quarter, we mark it as Incomplete (but continue working on it). This means we have missed our commitment. We want to avoid this for P1 goals at all costs.

Understanding ‘At Risk’

Risk is “risk for delivering on our commitment”, not a project being off-track.

A project can be stalled/delayed but the goal still might be “On-Track” to deliver this quarter. Example:

  • You have built-in time to accommodate some slippage and still have some cushion remaining
  • You have an alternate path to success
  • You don’t need this specific project to achieve the stated goal
  • You have a mitigation plan

On the other hand, a project can be unblocked and moving along but you can still be “At Risk” to delivering your goal. Examples:

  • Project is unblocked but remaining time in quarter insufficient to finish
  • Loss of personnel has slowed it down enough to miss the quarter
  • Big unknowns remain to be uncovered later in the quarter (team has deferred risk to the end)
  • Learned something new that will make the goal unachievable in the time period

There is no state called “Not Started”. This is a common way that timeline risk gets buried until there isn’t enough time to complete. If goals are not started, the team is accountable for figuring out when the work needs to start in order to deliver in the quarter, and keeping ‘On Track’ or ‘At Risk” up to date.

Managing active risks

Engineering is messy, so goals will become ‘At Risk’. It’s what we do next that counts.

We want to encourage rapid identification of risk, as early as possible in the quarter. A goal that has been green the entire quarter and turns red at the very end is very problematic because it leaves us with little options to solve. Leadership typically has a few tools at their disposal – cutting scope, moving resources, mitigation plans, and reprioritizing dependency teams. All of those tools are far more effective with 10 weeks left in the quarter vs. e.g. 1 week.

A goal moving to ‘At Risk’ near the end of the quarter also indicates gaps in planning and risk management. These are non-trivial skills for engineering leaders to develop, so leadership will be poking on P1 goals that are green during execution review to make sure they are actually going to be delivered during the quarter; it’s better to find out sooner rather than later.

If a goal is At Risk, there are 2 options:

  1. Team develops a plan to bring it back ‘On Track’. The team should aim to do this for P1 goals as quickly as possible (days, not weeks). Leadership should lean in to help unblock, especially if it lingers more than a week.
  2. Team marks the goal as failed (“Incomplete”) but continues to work and delivers in the following quarter. This tends to happen more frequently later in the quarter.

Tools to get a goal back on track:

  • Cut scope
  • Develop a mitigation plan (e.g. alternate path to success, redundancy, etc)
  • Push on dependencies
  • Drop other lower priorities
  • Reallocate resourcing

We want to avoid failing P1 goals at all costs and should treat them going red as a signal flare and call to action. P1 goals should not linger in the red zone for multiple weeks; we should be adjusting scope / resourcing, pushing on dependencies, escalating, etc to remedy.