OKR Process · 10 min read

Quarterly OKR Planning: Continue, Start, Stop, Then Commit

A quarterly planning session should not begin with a blank board and a manager telling everyone what to do. Start with what happened last quarter. Then give people a real role in designing the next one. That is how you get alignment without turning the plan into a set of goals people were assigned but never believed in.

By Max Bondarenko · Last updated July 2026

Start with the previous quarter

Before you design a new goal, look at the quarter that just ended. What was done? What worked? What did not work? What should the team continue doing, start doing, and stop doing? That review is not a retrospective for its own sake. It is the evidence base for the next plan.

Bring in the people who create and receive the work

A web developer may spend the quarter building landing pages for marketing campaigns and growth projects. That person has important KPIs and work, but if they only receive tasks after the plan is set, they are an executor in somebody else's system. The same thing happens to engineering teams across product, UX, sales, and marketing.

The counter-problem is obvious: a fully bottom-up plan can become a collection of local priorities. The answer is not to exclude people. Leaders set the company direction and constraints. Teams help create the route. These are complementary jobs.

Run the three-zone workshop

Use a whiteboard. Give everyone a section and let them add ideas as notes. Then sort the work into three zones. It makes dependencies visible before they turn into blockers in week six.

Choose the right way to measure the work

Not every Key Result needs the same measurement model. Numeric goals are best when you have a meaningful baseline and target. Binary goals are sometimes useful, but a plan full of them gives you very little signal until the end. Milestones are valid when the work is abstract and a number would be fake precision.

Set the Key Result volume at the point of proud and possible

This is where teams usually get stuck. A target should be ambitious enough that you would be proud to say at the company meeting, "I did this." Then test whether it is actually achievable with the team, the time, and the dependencies you have. If it is not, reduce it until both answers are yes.

That point is the right volume. It is not sandbagging. It is not fantasy. It is a target a team can commit to and still feel stretched by.

Make progress visible enough to manage

For milestone-based work, 10 milestones are usually better than two. Crossing one milestone a week gives the team momentum and gives the manager a real signal. Being stuck on one milestone for six weeks tells you almost nothing until the quarter is already gone.

The leader still owns the system

Leaders should have their own objectives and follow the same goal-design and update process as the team. They can delegate the administration: access to tools, onboarding, and the mechanics. They cannot delegate accountability for helping people create meaningful goals and building a system that helps those people achieve them.

Questions people actually ask