Some keys to setting Objectives

Why not read this post further

I wondered for a minute whether I’d title this blog post “Forget about setting objectives”. Why? Essentially because, as you might have noticed if you read some of my past posts, I’m rather against dogmas. And today, at least in the software industry, most of the chats I have with people about “objectives” include the “OKR” term.

If you’re looking for a step-by-step guide on setting OKRs, please do not read further. If you’re interested in the pitfalls I’ve seen and my advice on how to avoid them, I’m happy to share them below.

Notice: I’ve never seen OKRs properly set, nor producing the expected results. It’s just like Spotify’s model: there’s the theory, and then there’s humans. Humans just don’t have the Hive Mind. Let that sink in.

Let me repeat it. Humans don’t have the Hive Mind. For our glory, and our decay.

Oh, also: this topic inspired me quite a lot. There are a lot of words below. But I tried to sum it up with a cheat sheet at the end. Feel free to jump there directly.

OKRs, and stuff

Thanks a lot for reading until this point, especially if you still don’t have a clue what an OKR is. Out of transparency, even though I’ve been trying to work with it and chatting about it for years now, it always takes me a second. Objectives and Key Results. Here we go.

OK, I admit it. Before starting to write this, I Googled it again. The first hit was an Atlassian guide. Wow, that escalated quickly. Please don’t click the link. Let me paste some select parts for you:

An OKR is a popular management strategy that defines objectives and tracks results. It helps create alignment and engagement around measurable goals.

That lost me on the 5th word. Yes, “popular”. All I know is that most “popular” things in the tech world are often deeply misinterpreted and misimplemented. And that after a while we roll back thinking: “Hum, it wasn’t such a good idea after all”. We’re all very good at blindly following some “thought leaders” and trying to copy what they do, even in very different situations that don’t apply. If you missed it: Amazon, one of the sources of the microservices and serverless fads explained how they came back from it in a particular situation. OK, sorry for the rant, let’s keep on reading.

“Management strategy that defines objectives and tracks results”. That sounds wise. It’s pretty much the same as SMART, then.

Let’s leave the jargon aside then. All of these have that in common: it is about getting clarity on what you want to achieve and having unbiased ways to determine accomplishments.

Shooting at a moving target

Did I tell you that I worked most of my career as a Product Manager? What do we ask of a Product Manager, most commonly? A Roadmap! Has anyone ever carved a roadmap in stone, and everything went according to the plan? I never did. An honorable colleague of mine coined it:

A roadmap is a living animal. It grows, it changes. And it’s all fine.

A Roadmap is probably the most extensive way to write a set of objectives that I experienced. It spans multiple weeks or months (no, please don’t ask for years); it is time-bound. It is specific. It, hum, should be achievable. There is an unbiased way to assess whether things are delivered. It is broken down into multiple deliverables. It impacts multiple people or teams.

While making a prediction on when a given feature will be delivered is more or less like shooting in the dark, all kinds of impediments make it all at once shooting in the dark at a moving target.

OKRs or any sort of objectives should be first set at a company-wide level. How dare we do this while knowing that we won’t reach it? In the software industry, much revolves around the product and its roadmap.

Should we even try? I’ll try to give some answers. Spoil: yes, we should. A moving target requires a moving aim. A changing environment requires changing objectives.

Accountability & Responsibility

Let’s hold on for a second, and get clarity about Accountability and Responsibility (recommended reading: RACI). The last paragraph indeed puts some rather heavy weight on the Product Manager’s shoulders, right? If they fail at predicting their roadmap, engineers won’t reach their objectives. Sales won’t sell enough. MRR and ARPA won’t look as pretty. Blame on PMs.

Wait, what? I know that Humans don’t have the Hive Mind, but should PMs be bullied altogether? PMs are responsible for writing the roadmap, but can’t be held accountable for it. Defining what’s in the roadmap is a team effort. Trying to achieve the roadmap is a team effort. Impediments are a team burden.

Clearly one of the biggest pitfalls I’ve seen. Objectives make people accountable, even when they’re not defined at a person’s level. Either because when they’re not reached, someone will try to blame the person who was responsible/accountable for it (mixing up the two, most of the time), or because the person will blame themselves anyway. You can only be accountable for things that are under your control.

You’ll tell me: “Well yeah, that’s precisely the point of objectives”. I’m so sorry the old Command & Control paradigm left such an impact, still in today’s world. Let me open up that door: failing is fine. You can fail. Others can fail. What matters is what you do with that failure. Actually, you can even stop naming it a “failure”, and realize it’s just a missed objective.

So why set some objectives, after all?

Because we learn! I try to avoid using metaphors, so please excuse me for this one: when you park your car parallel in a narrow spot, you usually will need several attempts. You won’t stop at the first miss. You look into the mirrors and adjust. And you’d have to do that even more if the spot was moving while you park.

I mentioned that setting an objective is a complex task. And one key criterion is about making it “achievable”.

Still not believing in dogmas, I like the Shape Up method idea of “appetite”, because it balances the ambition and the need to reach a specific objective. How hungry are you? Do you know for sure that this or that quantity is enough? And when it’s enough to sustain your body, would you still have some more, because you like it and you can? (Oops, another metaphor)

Make an educated guess! That gives a direction. It brings clarity.

Then track the objectives metric, continuously. Don’t wait for being against the wall to realize it’s too high. If you have a chance to adjust either your efforts or your objective, do it.

And when you miss the objective, and it will happen, there’s no blame. There are lessons to learn. Were you not hungry enough? Did some impediments seriously impact delivery? Can they be prevented next time, or should you just know that you need a safety margin in case they occur again?

I truly understand engineers’ reluctance to tell “how long something will take to develop”. Tag it as you like: man-hours, days, complexity points. Any sort of commitment. Because they’ve always been the first to get blamed for not delivering according to their estimates.

Now the best success I’ve experienced is by setting abstract metrics that gave an idea of how much work a task would represent, relative to others. Absolute values just can’t work. Relative values have that chance that:

• they can fluctuate, and thereby adjust over time to a given team and/or environment. Something “hard” for someone can be “easy” for others in different contexts;
• by making an educated guess at a given task’s metric, we can make a more educated guess for a similar task next time. Mark my word: “guess”. Not “commitment”. Not “estimate”. Nothing absolute.

Let me fall to this one, too (sorry):

Shoot for the moon. Even if you miss, you’ll land among the stars.

Norman Vincent Peale

Honestly: shoot for whatever you want. Then make sure you know where you landed, and where you want to go next.

Financial Incentives

That’s all fun and games, but you’re here to run a business. People should get a bonus if they help you reach success.

Well, I’m still hesitant to answer this for the sales positions. But in other situations, let me tell you: no.

What really made me want to write this (very) long post is a discussion I was having on a Product Management Slack channel, about objective-bound financial incentives for PMs. That thread includes countless anecdotes of how people burnt out, gave up on objectives they couldn’t reach, cheated with the system, had toxic behavior towards their peers, or simply didn’t care at all.

As much as you should reward and recognize someone for their outstanding achievements, keep in mind:

• Not rewarding others won’t motivate them much. It’s penalizing them.
• Unless you have flawlessly defined objectives (despite all that I wrote above), there’s a fair chance that their completion assessment will be biased. What’s the bias that you introduced then, and can you be fair to others?
• People cannot suspend their lives to a vast series of uncertain events and people’s willingness. Their wage should be sufficient so that they just don’t care about getting a bonus. Thereby losing the “incentive” meaning.
• Don’t wave a carrot that you don’t own. The money isn’t yours. If your boss, for good or bad reasons, decides you can’t give it, YOU will fail your team. Talking about accountability…

Cheat sheet

Long stories short: you need objectives. Though only if you set them wisely.

• Specific, Measurable, Achievable, Relevant, Time-bound.
• Make an educated guess.
• Constantly review and adapt your objectives.
• Absolute values often make weak objectives. Look for relative values (% of increase/decrease).
• Humans don’t have the Hive Mind. Don’t ask them to change. It’s fine.
• You can only be accountable for things that are under your control.
• It must not be about penalizing.
• It is about giving a direction.
• Missing is fine.
• It must be about learning.
• Refrain from binding objectives and financial incentives.

Featured image by Christian Kaden