My team’s got more to do than we’ll ever have time for this year. I can tell you what I wish our OKRs were; the hard part is prioritizing it all.
said every CTO everywhere.
I recently sat down with some of NYC’s leading CTOs and heads of engineering to discuss OKR (objectives and key results) and KPI (key performance indicator) best practices. The truth is, despite the fact that 2018 is underway, many tech teams are still scrambling to finish 2018 annual planning.
I’m here to tell you it’s OK. Keep Calm.
Whether you use OKRs, KPIs, Rocks, or any other annual and quarterly planning system, the key to success is to find a process that is flexible and that your team will embrace.
While there’s no one-size-fits-all solution, these OKR and annual planning best practices should hopefully get your team over the finish line.
Set a three-year goal first
With the average tenure of today’s tech employee at two years, it’s important to keep in mind that a 20- or 10-year goal might seem too distant and unmotivating. Instead, anchor your team with a strong three-year goal. Three years is a good amount of time for most tech teams. It’s long enough that it feels strategic and short enough that it’s motivating. Pro Tip: The three-year goal should be measurable.
Get buy-in from the team early and often
People generally hate being told what to do. Ensure that your team is on board with your annual plan by getting buy-in from them early and often. Enable employees to poke holes in the plan and suggest improvements to it. Give employees permission to be vocal about areas they want to be involved in.
Set expectations on what to do if you need to pivot mid-year
Annual planning doesn’t have to be anti-agile. If done right, the annual plan can be a strong complement to a high functioning agile team. Use agile best practices to guide your annual planning session by setting a small handful of measurable initiatives, and account for slack time. Hold regular retrospectives, and create a process for pivoting or iterating on the plan that mirrors how you handle a new feature, epic, or sprint planning.
Make it personal
Assign one person to be accountable for each OKR, Rock, or KPI. Know who the product owner is for each initiative. Be crystal clear on the definition of “done done.” Put the accountable person’s image next to the OKR. Whether you have an avatar, someone’s headshot, or a physical sign-off sheet, make who owns each initiative visible to the entire company. For larger organizations, consider implementing RACI or some other type of responsibility matrix, to create a shared understanding of the type of involvement various team members have in each initiative.
At Casper, each OKR owner presents their results to the entire team, regardless of how much of the goal they achieved.
Estimate your capacity at the start of each quarter
Don’t go crazy with this; just figure out the ballpark capacity. How many person-weeks do you expect to have, accounting for planned new hires and any anticipated turnover, holidays, and vacations? With that ballpark estimate of capacity, you can have a better chance of setting achievable velocity and outputs.
Don’t have one metric that everyone is trying to hit
Instead, have a small handful of 3–5 metrics, each with an owner. Ideally, product and engineering teams have adjacent and aligned goals, but not the same exact goal.
Achieving growth and efficiency at the same time is really hard. Pick one.
Innovation is inefficient. Growth is inefficient. When you are doubling in size, be realistic about the temporary hit that velocity per employee is going to take. New employees need ramp-up time and time to integrate with the team. So when picking your OKRs, be realistic about the trade-offs you are making when prioritizing either growth or efficiency.
Use a tool to track progress against OKRs
Jira, Trello, Google Docs, Metronome, Clubhouse—pick one tool, and use it. Which tool you choose matters less than that you use it consistently. Just as you track progress toward epics and stories, track progress towards OKRs. Set a cadence for tracking progress, and stick with it. You might choose to track OKR progress as part of each sprint, or you might choose to hold distinct meetings to review OKR progress.
What best practices have you seen? What mistakes have you made? Add your OKR best practices in the comments below.