A few weeks ago, Thomas Forstner left a spicy comment on Mark's post about a newsletter we'd published on accountability for performance.
Thomas is VP of People at Juro and is testing a hypothesis: that you could shift accountability for performance away from leaders and onto individuals themselves.
I was curious and wanted to hear more - so I caught up with Thomas to unpack the approach.
What followed was one of the more interesting conversations I've had in a while about adopting product management methodologies to design the employee experience around performance.
In this newsletter, we'll dive into why Juro decided to do things differently, how they flipped the script, and what it's looked like to adopt product and design thinking to deliver a new approach to promotions.
PREVIOUS NEWSLETTERS
In case you're a new reader (or just missed them), here are the past few newsletters:
- 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
- Would you rather follow a script - where we share why high-autonomy cultures often need just as much manager support as low-autonomy cultures.
- Accountability isn't an HR problem - where we challenge the assumption that measuring platform usage or adoption equals accountability for performance
Why most performance reviews leave everyone a bit deflated
Most of us know the version of performance reviews that doesn't work.
It's lengthy, it happens once or twice a year, and too often we receive feedback that could have been useful, only to find it's too late to do anything but absorb it.
Most teams build their performance processes so that accountability lies with the manager: the assessment, the coaching, the case for someone's progression. And because the process is often built for HR rather than the people who use it, adoption remains patchy, and everyone goes through the motions. (We've written before about why chasing adoption is the wrong goal.)
Thomas put the cost of this plainly. If the first time someone tells you they're unhappy with their pay is when they slap a counteroffer on the table, the conversation has happened far too late, and in the wrong room.
How Juro flipped the script
Juro is an 80-person AI contracting platform. Thomas's people team is two people (plus him picking up IT on the side), so anything they build has to be lean.
So, they did away with the traditional performance approach and are testing a hypothesis that progression should be something an individual makes a case for, not something that should just be expected.
Instead of execs deciding raises and promotions behind closed doors, people at Juro now build their own business case. They gather evidence of their contribution over time, and when they think they're ready, they make the case to their manager and execs themselves.
The bar is deliberately high. As Thomas put it, "good work does not get you a promotion." For a case to hold, the work needs to be:
- Business critical,
- Done above and beyond, and
- Done consistently.
Miss one of those and the case doesn't hold.
Those three points do more than determine the outcome of a business case for a promotion. They set a clear expectation of what great work looks like at Juro, and that gives people something concrete to aim for. It nudges them to focus less on writing a persuasive case and more on doing work that makes a difference.
Juro doesn't just raise the bar and leave people to meet it on their own, though. Thomas made it clear that when someone struggles to do exceptional work, it's often a sign that the company hasn't set them up for success, rather than a failure on the person's part. So the expectations come paired with the conditions to meet them: outcomes defined specifically enough that people know what they're aiming at, a choice-first approach to where and how people work, and return-to-work plans built with people who have needed to take extended leave. The aim, in his words, is to create the conditions for anyone to succeed, whatever their circumstances.
Discover, design, deliver, then keep iterating
Juro also runs performance far more often than most, with six lightweight cycles a year instead of one heavy review. Thomas's logic is that frequency lowers the stakes of any single conversation and creates a learning loop, because each cycle gives them data to improve the next.
Plenty of people teams launch something new and never stop to ask what it might break. Before Juro launched this new approach, they also thought hard about who it might disadvantage. Self-advocacy doesn't come equally easily to everyone, and Thomas was clear that asking people to make their own case can favour those already comfortable doing so. So they built in mitigations: an annual check on any gender pay gap, regular conversations with managers to quietly encourage strong performers who hadn't put themselves forward, and the option for a manager to co-write someone's case.
It’s early days, but so far, the proportion of cases in draft reflects the company's diversity makeup, which was exactly what they were hoping for.
A few things you could try
While I am intrigued by Juro’s approach, I'm not suggesting you copy their framework exactly. Their approach fits their context, and Thomas would be the first to say it's still an experiment. But there's plenty here worth borrowing, depending on where you are.
I’d encourage you to reflect on which one might suit you:
🗂️ Borrow the bets/processes/bonus quests structure to decide where your team actually spends its energy.
🧪 Improve one process through experimentation. Pick a single thing, treat it as a bet or bonus quest, keep it small, and build in a way you can learn from it.
🔁 Increase the frequency, lower the stakes. More frequent, lighter conversations beat one heavy annual event, and they teach you faster.
📝 Try a starter version of employee-led cases. Even asking people to reflect on and name the value they bring starts to shift the ownership.
If you boil Thomas's own advice down: start small, accept you'll get it a bit wrong, treat it as an experiment, and bake in a way to keep iterating.
So a question to leave you with. If you could burn one of your performance processes down and rebuild it from scratch, which one would it be, and what's stopping you from running a small experiment on it now?