31 Oct 2020

Execution review

Leadership's opportunity to share accountability for team execution.

What is it?

Execution review is a most critical ritual to drive a culture of quarterly commitment and the one that does a lot of heavy lifting in teaching your management key skills needed to hit commitments.

This ritual needs to be done frequently - ideally weekly, but but biweekly can work if you have additional more frequent checkpoints on critical projects.

I recommend structuring it as a “timeslot meeting” - basically, a longer meeting where each team can come to cover their quarterly goals with a predictable time slot. When you are first starting out, you may want to consider 30 minute time slots for a typical 8-12 person engineering team. Over time, many slots can be reduced to 15 minutes as teams get more mature.

Start this meeting about 2 weeks into the quarter, as the first 2 weeks not much will have happened, and continue until the quarter is complete.

Scaling this meeting
As your team grows, it gets difficult to cover all of the OKRs. Most of these rituals should be run at the M2/M3 level. If you have a very flat org and you are finding this cost prohibitive even as a M2/M3, I recommend restricting your focus to:

  • All P1s
  • At Risk items
  • Items that have changed since last week
    as well as considering a biweekly cadence (a weekly meeting with team slots spread across 2 weeks).

Why do we do it?

  1. Enable EMs/PMs to become exceptional at managing risk and dependencies
  2. Give leadership the right level of visibility
  3. Enable leadership to support the organization and share accountability for successful execution
  4. Build a culture of accountability and commitment

This meeting is leadership’s opportunity to help support the team’s execution. Many challenges that are difficult to solve at the EM level are trivial to solve at a more senior leadership level, particularly when it comes to cross-team dependencies and resource challenges. It also gives leadership visibility into the org and is a repeating ritual that helps drive a culture of accountability and commitment.

Setting up for success

Make sure you are following the materials in

In particular, you will want to make sure there are owners for every goal you have as an organization and the priorities are there as well.

Make sure your OKRs are encoded in a shared spreadsheet (see my Excel OKR template) or better yet in JIRA/Azure Dev Ops which lets you do queries etc. We’ll refer to this as the goal tracking tool.

Goal Owner expectations

Show 10 minutes before their published timeslot. If you can’t attend, send a delegate in your stead.

Prior to the meeting, every owner should have:

  1. Updated the goal state for each goal they own in goal tracking tool. This should be done every week.
  2. Come armed with deep knowledge of the projects that add up to the goal and their status. Best practice: Update each goal with a comment: “Why we think this is on track / at risk” every week.
  3. Understand the status of their dependencies
  4. If they had a goal turn RED in the previous meeting, they should have developed a recovery plan to turn the goal green or a specific ask from leadership. Don’t wait around for this meeting to make this happen.
  5. If they are a dependency for another team’s goal, they are also up to date on the status of the other team’s goal.
  6. Scored their goals (if using OKRs) to indicate progress

How to run the meeting

Walk through each goal (if time is limited, focus on P1s or At Risk items as mentioned above) and ask the owner to talk about their progress.

This is not a status meeting!

You should run this as a review meeting - poking and probing to see what is happening with the effort. In particular:

  • Is the team managing risk appropriately?
  • How are they managing their dependencies?
  • Do they need help?
  • Are they prioritizing properly?

Here’s what you’re really trying to figure out:

Are these goals really on track to deliver according to the commitment? If not, how can I help?

Has the team accounted for all of the timelines? For example, if it is a user-facing feature, have the accounted for dogfood feedback, etc? Have they factored in vacation? Is the team delaying start on something risky, like integration? You want teams to proactively pull the riskiest part of the project forward. Are they aware of their dependencies on other teams? Are those other teams on track as well? If they don’t know the answer, that’s not a good sign.

Make sure to check out and share Undertanding risk to make sure your team is aligned on ‘At Risk’ vs ‘On Track’.

Is the team focusing on the most important goals and proactively derisking them?

Are they making progress on P2s and P3s over P1s? Are there P1s that have not started? How long do they expect them to take?

Is there a sense of urgency to work through any issues? Do they need help?

Is the team moving quickly when the project has turned red? Are they taking aggressive action to get the project back on track? Are they stuck spinning their wheels with a dependency team but afraid to rock the boat? Goals turning RED is not a problem (it happens!), but something lingering in “At Risk’ usually is except for projects that are “coming in hot” with the timeline.

You should cover every goal that is at risk. As a leader, your responsibility is to unblock the team, help them ruthlessly prioritize, and teach them to escalate early and often.

Make sure your team is following the playbook in Managing active risks to quickly address issues that have flared up.

Are we taking the time to reflect on our learnings - both when things go well and when they do not?

When we move a goal to “Incomplete”, are the teams taking accountability? Do they have takeaways that will help them get better next time?

When a goal is completed, make sure to appreciate the team.

Execution anti-patterns

Keep an eye out for any of the following issues:

  • Making progress on P3s before P2s or P2s before P1s (Focus on your priorities)
  • Goal is green for the whole quarter and turns red at the very end (Plan well and pull risk forward)
  • Starting off the quarter in the red (Be thoughtful about your commitments)
  • Work on a P1 goal “Not Started” until much later in the quarter
  • Not knowing the status of critical dependencies
  • An owner shows up and does not have complete knowledge of the goals with their name on them
  • When pressed, they do not have intermediate milestone dates for the quarter

Leadership “Tone”

The tone for this meeting (and for the quarterly review) is critical. As a leader, you want to be supportive but absolutely steadfast in holding the line. Do not move the goalposts. If something turned out to be much harder than the team thought, they can always take on a new, closer horizon goal, but the existing one must remain and get marked as Incomplete. Otherwise there is no accountability, nor an opportunity to learn and get better. Next time the team will hopefully do a better job managing risk and planning.

Ask teams to deliver on the “letter of the goal” - the exact wording they encoded in the tracking tool. Otherwise it is an another opportunity for folks to change the scoring criteria and move the goalposts, and it reinforces the importance of getting the commitment written clearly and understandable. It is common, especially in the first quarter or two, for teams to realize they hadn’t written their goals well and now they are impossible to complete. They will learn and start taking out better goals in successive quarters.

In general, consider the goals to be immutable - teams can add new goals, but cannot modify existing ones. You want to be a bit of a stickler here as you really want to drive execution hygiene.

If a team and leadership together decides that a goal is not longer worth pursuing, you can cancel it in this meeting.

I typically allow teams to tweak their goals in the very first execution review of the quarter, especially if the planning cycle was compressed, but beyond that cases are very rare.