Retro is the Stepson of Planning

by Inbal Gilead (Dir. Product) and Liran Yogev (Dir. Engineering), at ZipRecruiter

Planning season is finally over (phew!), but wait… did we forget something? 😉

Oops! What about retrospectives?

Plan vs. Actual (Image by midjourney)

“Why do we need retrospectives?” you might ask. Well, they’re the key to understanding how our team is really doing compared to our plans. As product leaders collaborating closely with our engineering counterparts, retrospectives provide us with valuable insights that help us identify areas for improvement. For instance:

• Are we working at the right pace? Do we have the right skills on our team?
• Was our plan realistic in terms of workload?
• Did we plan well for dependencies?
• Did our engineers handle the scope definitions smoothly, or did they face challenges?
• What was the ratio of planned work to unexpected surprises, and where did those surprises come from?

Each of these insights serves as a call to action, guiding us toward significant improvements. Teams and plans are like living organisms, and keeping a close eye on them ensures our plans have a fighting chance (though perfection is never guaranteed nor is it the goal).

Our Easy Breezy Retro Format

Leading three teams, Liran and I needed a format that gets the job done without bogging us down. So, we came up with this simple format, where we map our planned initiatives on a scale of “just a bunch of random words” to “we’re done”:

The Quarterly Checkup

Originally, we used this format as a checkpoint at the end of Q1. It helped us ensure we were still aligned with the goals we set in January and on track to meet our H1 objectives. This allowed us to make adjustments while we still had time to influence our progress for the rest of the half.

During the Quarterly Checkup, we gather the teams together, review the plan, and have a (relatively short) conversation to align everyone on the initiatives. We iron out any misunderstandings or loose ends that may have slipped through the cracks. We also discuss the current status of each initiative, make necessary adjustments to scope and priorities, brainstorm actionable ways to improve our results, and foster a team-focused environment to accelerate our plan.

Here’s an example of what one of our teams achieved:

We used colors to indicate how we were doing relative to our initial plan, where green is “on track” and red is far away from where we should have been at this point.

With this team, we were thrilled to validate that we were 40% completed and right on track! We also discussed the four initiatives on the far right side of the diagram and agreed that they should be finished early in Q2.

After that, we each went our separate ways, and not before long, we started thinking about H2. As we’re in the final stages of planning, before we wrap things up, let’s take a peek at how H1 concluded. Shall we?

The H Summary

The H Summary process was much quicker this time around. Liran and I revisited the Q1 checkpoints and updated them to reflect the current status at the end of the half. Since we had already had in-depth discussions with the teams during the Quarterly Checkup, we were able to quickly draft a summary ourselves and circulated it for feedback from the teams. Within a few hours, we had a neat summary and some insights:

Cool Learnings Powered by Our Retro

1. Allow and encourage the team to focus
   The Data Access Control POC remained untouched during the first half as it didn’t align with our other activities.
   In hindsight, we should have identified the issue and removed the Data Access Control POC from the plan back at the quarterly checkpoint to avoid diverting the team’s focus and prevent sandbagging the plan with an initiative that wasn’t going to be pursued.
2. Dependencies could be initiatives, too
   Instead of directly working on the Self-Service Analytics — New Tool and Improve Query Engine Performance initiatives, the team engaged in a Proof of Concept (POC) for a technology that served as a prerequisite or “dependency” for both initiatives.
   A more effective approach would be to make resolving the dependency the primary initiative rather than attempting to tackle the two downstream initiatives simultaneously.
3. Don't underestimate the “long tail syndrome”
   We successfully completed or nearly completed the four initiatives we focused on, but they wrapped up later in the quarter than anticipated.
   This could be attributed to either the “long tail syndrome” or a case of “scope creeping.”
   In any event, we missed properly declaring and following up on the definition of done.

Each of these insights, along with others, is pure gold for us, and our teams. We shared the complete retrospective report for everyone to learn from, and we reviewed our H2 plan with fresh eyes, ready to avoid those highlighted pitfalls.

Retrospectives are invaluable tools for continuous improvement, enabling product and engineering teams to optimize their performance, spot potential traps, and adapt their plans accordingly. Let’s embrace the power of retrospectives as we move forward and unlock the full potential of our teams. 🚀