It’s that time of the year when we start seeing people lamenting their objectives and planning processes. Were you handed OKRs that you don’t really understand? Objectives you plainly don’t believe in and know will be changed by the time you’re back from the New Year’s vacation? You’re not alone, and it doesn’t have to be that way.
How Bad Objectives Harm You
First, I’ve seen my fair share of tech leaders who think they can play pretend with OKRs they don’t really believe in. They hold meetings and have people fill out the wiki documents just to go through the motions, expecting things to change quickly or for no one to ever review the work. This is a bit of Kafka-esque compliance that I’ve seen happen even in mid-sized startups, not just in big companies.
This sort of reluctant compliance theater is harmful because it essentially teaches your team that what you do doesn’t matter. That we are ok with declaring goals and work plans and forgetting them a moment later. You’re plainly modeling hypocrisy.
There are also scenarios where we accept objectives that are way too limiting. Prescriptive objectives are essentially feature lists that place your organization on the path to becoming (or remaining) a feature factory. When our goals confine us too much in terms of implementation, they rob teams of autonomy, ownership, and the context that’s necessary to genuinely shine.
Criteria for Good OKRs
Treat these like a checklist that you can go through to ensure you’re not making these mistakes.
Team-Level and Up: I’m opposed to OKRs at the individual level. These are just too much hassle and tend to never be net-positive. Keep it at the team level. (That doesn’t mean individuals can’t help personal growth goals. See the free impact coaching framework book.)
Non-Prescriptive: When an objective tells you exactly what to do and how, it stops being an objective and turns into micromanagement. Teams ought to have enough freedom to interpret a goal and decide on the optimal path to reach it.
Long-Lasting: Goals that are too specific, too short-term, or too small tend to change a lot. When that’s the case, unfortunately, most companies don’t take the time to redo their OKR plan mid-quarter and just wing it for months. Aim to have objectives that you believe have an 80%+ chance of remaining relevant and a priority for the whole quarter (or two).
Top-Down and Business-Centered: When tech teams come up with their own goals, they tend to be overly technical and not clearly connected to business outcomes. Why should we care about reducing the API’s latency? What positive impact on the business do you expect it to have? Most times, it’s better to review top-down objectives and come up with key results that align with them, and not the other way around.
Have Context: You want objectives that you understand. They should have a story, a hypothesis, or a theory that explains why this is a priority, why this is chosen, and what they expect to achieve. These should arm the team with enough context to be able to make the right decisions along the way.
Have Borders: Relatedly, a good objective provides healthy constraints. It should help us be clear about what we’re not going to be doing. Constraints can be the greatest catalysts for creativity. Don’t be afraid to use them.
Specify Lead Indicators: You want to be able to see (and report!) progress as time passes. A good objective should come with indicators and metrics that will help you keep your finger on the pulse and see how well you’re doing. That will also allow the team to decide to pull the plug early if things aren’t working out. That’s better than having one big binary “pass/fail” metric that will only be clear at the end of the quarter.
Definition of Done: Similarly, you want to be able to tell when you’ve reached your goal. I once helped a company that had as an objective something like “improve onboarding.” In hindsight, the team reached a good enough state within 6-7 weeks, but kept working on it for the rest of the quarter because no one could tell they had already surpassed their expectations.
Traceable: Not always simple, but you want to ensure that you have enough clarity regarding the team’s impact on the end result. For example, when three teams are all performing changes that could all result in an improvement to your LTV, it’s going to be very hard to tell which changes were beneficial.
Org-Aligned: Lastly, a good objective makes sense when considered along the org-chart. I hate it when OKRs have absolutely no connection with how the team looks. Org structure matters a lot for productivity and communication. Sometimes that means rewording and chopping an objective differently, other times, it means your squads need a reshuffle.
Get to it! If you need a hand, reach out.