Reviewed by someone who never saw my work

For most of my early UX career, the person who wrote my performance review didn’t see my work day-to-day or have a background in design.

I was the only UX person in the company; I didn’t have a design manager or a design team. I reported into engineering, to someone who was good at their job but who had almost no true understanding of mine.

My manager often wasn’t a part of my user research sessions. They didn’t really have a reference point for what good UX looked like. So when it came time to review the quality of my work, a lot of it was a big guess.

The problem was that a lot of the performance process was built on an assumption that wasn’t true: that the performance process should be run in line with the org chart.

I want to show you where this assumption breaks and a few ways to design around it.

PREVIOUS NEWSLETTERS

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

Engagement scores tell you what people think, not what changed. Vanity metrics versus actionable metrics.
Start with the decision, not the data. Dashboards are only as useful as the questions they answer.
I changed my mind about discovery. What if the best way to understand a people problem isn’t more discovery, but a small experiment?

The org chart doesn’t map well

When you design your review in line with the traditional org chart, you’re assuming the manager sees the work and can judge it effectively.

But in a good number of companies I’ve worked in and with, that isn’t actually the case:

When a consultant is embedded in a client for six months, their client is experiencing the quality of their work when their manager might never even see it.
A company going through layoffs and restructures might mean someone has 3 different managers in a year, so no single one has a full picture of their work.
In some cases, a person is in the only role of their kind, reporting into an unrelated function, the way I was.

We need to stop treating these as edge cases that don’t need to be accounted for.

A great deal of the time, managers don’t have enough visibility or awareness to be able to properly give their team members feedback on their work or help them improve.

If not the manager, then who?

When you’re designing your review process, I recommend starting with a simpler question than “who’s their manager.” Ask who has actually seen the work.

Depending on the role, that might be:

The peers working alongside them day to day
The lead on a project they contributed to
A senior person in their discipline who sits in a different team
Sometimes the customer, if they’re the one seeing the output

Then design the review process to gather feedback from those people, and let it be data to feed into decisions about performance and pay rather than leaving it up to one person.

This is where the design of a lot of “off the shelf” style performance tools get in the way. They assume the manager is the best person to review someone.

It’s the reason Crewmojo built the flexibility to pull feedback from whoever genuinely sees the work, rather than forcing everything down the reporting line.

What the performance review is actually for

There is a bigger question underneath all of this that I want to address.

We tend to treat performance reviews as the way the business decides two things about their people: who gets paid what and who gets promoted.

So we build the whole process around producing that verdict, and stop asking whether it’s helping anyone get better.

Flip the priority. A performance process should help people and the business improve first. That’s one workflow, designed around that job.

Please please please, if you take anything from this newsletter let it be this:

Run your pay and promotion cycles as separate workflows from those that gather performance feedback.

When the review exists mainly to make decisions about people’s pay and progression, people game the system to “perform” instead of actually taking on feedback and improving.

Three questions to ask instead

Most reviews hand the person a verdict at the end. A more useful version puts them at the start of it and a say in who their feedback comes from.

There’s a concept from organisational psychology called double-loop learning (by Chris Argyris):

The single loop asks “am I doing this right?”
The double loop asks “is this even the right thing to be doing, and how would I know?”

A review meant to help someone improve needs the people giving feedback to help answer both.

So flip the usual order. Before any feedback gets gathered, have the person reflect on:

What goals or outcomes am I working towards, for myself and the business?
Who can help me know whether those are the right ones?
Who can help me make progress and give me feedback on my approach?

Those answers point to who should feed into their review, and help them grow.

It’s a small change in sequence, but it turns feedback from a threatening assessment into a conversation about growth.

A lighter review is the payoff

Design it this way and the formal review gets a lot lighter.

If you capture the improvement conversation as you go, from people who actually see the work, you’ve already got most of what a review needs.

With AI in the mix, that running record does much of the writing for you, so the review becomes a summary of a year your managers were already paying attention to, not a heavy annual event.

The measure of success shifts too: less about how someone stacks up against a fixed idea of good, more about how fast they’re learning and improving the outcomes of their work.

I’m keen to hear — how does feedback actually flow in your team?