Be opinionated - but about the principles of performance, not the process.

When I designed my first performance framework, I wanted it to be as comprehensive as possible.

It started with ensuring a manager took the time to understand their team member’s aspirations. It helped them align on the expectations of their role and how it connected to the organisation's goals. It provided a framework for building their goals from both their progression ambitions and the business's needs. It ensured team members could discuss their progress and blockers in 1:1s. It also tied in how to ensure their performance was reviewed fairly at the six-month mark.

Even writing it back now, I laugh in embarrassment at how much I tried to launch in one go. I had good intentions; I wanted to make sure my solution was comprehensive, but in practice it was too much  (For me to run, for managers to follow, for people to use straight off the bat).

The feedback I got was either “Can we just focus on one part of this?” or “Can you give me the exact steps to follow for each part?”

The more we overcomplicate performance, the more people want a recipe to follow to the letter. A recipe is the opposite of what we're actually after: managers taking the time to understand their people, help them grow, and bring out their strengths in the work.

We tend to be binary about it. We either overcook the process, or we hand people no structure at all. We're not very good at the middle ground.

PREVIOUS NEWSLETTERS

In case you're a new reader (or just missed them), here are the past few newsletters:

1. What if your promotion was in your hands? - How Juro flipped the script on how promotion decisions are made
2. ​AI isn't the disruption. Our inability to design for humans is​ - the key takeaways from a roundtable about taking a human-centred approach to AI adoption
3. ​Would you rather follow a script​ - where we share why high-autonomy cultures often need just as much manager support as low-autonomy cultures.

Why borrowing performance processes doesn't work

When the process feels heavy, we reach for someone else's answer.

I've done this too. I'd read an article about how another company ran performance, thought "that's brilliant," and looked to borrow it wholesale. Or, when there's budget to spend, we pick the performance software with the most features for the buck and roll out whatever the vendor tells us to.

Neither of those builds anything for the specific context of our own organisation.

Both are a kind of neutrality, really. We're not forming a view. We're following the status quo and calling it a decision.

Mark Lewis (Crewmojo's CEO) wrote about performance processes needing "​product-market fit​": two processes that look identical can land completely differently depending on the organisation they sit in. Borrowing the shape of someone else's process skips the part that makes it work: the fit to your context.

The deeper issue is that we jump to designing the process before we've said what outcome we're designing for. We argue about the mechanics (how reviews should work, which template to use, what cadence to run them in) while the question of what performance processes are in service of goes unanswered.

Be opinionated, but at the level of principles

Mark and I were talking recently about a shift he's been sitting with. He's spent years deliberately not holding an opinion on how organisations should "do" performance, because he sees how differently every one of his customers approaches it. But he's landed somewhere I think is right: there's room to be more opinionated, just not at the prescriptive level. At the level of principles.

I'd take it one step further. The principles worth holding aren't design rules for a process. They're questions that help you form your own view before you build anything.

A few I'd start with:

🤩 ​What does a high performer look like in this organisation​, and what conditions help them be successful?

🧭 What do we actually believe the purpose of a performance review is? (And should goal-setting and reviews be separate, or joined?)

💬 When is feedback most useful: to actually improve performance? To help people feel valued and recognised?

📈 What kinds of goals do we want people to have and why: performance goals, progress goals, development goals, some mix?

🌱 What is all of it in service of - i.e. what is the purpose that people want to perform anyway? Because they want to make an impact on the world, experience greater career growth, or just have a well-supported and balanced life?

That last one might sound abstract, but it's important because it informs everything else.

Unbundle your performance processes

And most importantly, think about unbundling them. Instead of having a hefty annual, six-monthly, or even quarterly cycle that includes review, feedback, and goal-setting, separate them into smaller activities that occur more naturally within the work and at a cadence that helps people improve.

There's a good book on this, Thanks for the Feedback by Douglas Stone and Sheila Heen, which separates feedback into appreciation, coaching and evaluation, and makes the case that when you deliver them together, people can't tell which one they're receiving. The same is true of a performance process that tries to evaluate, coach and set goals in a single sitting.

This is the part I like about how Crewmojo rebuilt their product. Performance shows up as visible, editable steps rather than fixed modules you're handed. When the process looks configurable, people treat it as configurable, and they start adapting it to their context instead of assuming what's in front of them is simply "the process." A good starting point you can iterate from, not a blueprint to accept.

One thing you can do this week

Take one performance ritual you already run: your review, your 1:1s, your goal-setting.

Before you look at improving its design, write down the single outcome it exists to serve. What is this actually for?

Then look at what's been bundled in. Is your review quietly also doing the work of feedback and goal-setting? If it is, that bundling is the first thing to pull apart and question, before anything else.

Simplify, simplify, simplify.

Your teams shouldn’t have to spend valuable work hours on performance processes; they’d rather be doing their day job to the best of their ability.

‍