Performance Reviews Now Grade How You Delegate to AI

Managers Didn't Get Stricter. They Got More Behavioral.

A Nielsen survey of 1,700 directors and senior managers across seven countries found more than half said employee work became harder to evaluate after AI adoption. Seventy-eight percent responded by changing the criteria themselves, weighting prompting ability, delegation judgment, and experimentation more heavily than raw output.

That's the short version. Here's the version that stings.

Picture a quarterly review. Three tickets on the board are marked done. One was a four-hour job where a coding agent scaffolded most of the implementation, and the engineer spent the rest of the day on the edge cases that would've paged someone at 3 a.m. Another was three days of careful schema migration nobody wanted to own. On the board, they look the same. In the room, they aren't in the same category.

The manager isn't being unfair. She's working with the evidence she has. And AI quietly removed most of that evidence.

The output got cheaper; the judgment got more expensive. That's the whole shift in one line. When a decent first draft takes ninety seconds, "how much did you produce" stops separating people. So managers reach for the next available signal: how well you scoped the work, what you handed off, and whether you checked it.

Is that a better rubric? Mostly, yes. It's closer to what senior work actually is. But it creates a side effect nobody planned for: the new rubric rewards evidence, and most people generate none.

If your manager can only see the board, what does the board say about you?

The New Rubric Asks Three Questions, None of Them Is "Did You Use AI?"

The three questions are whether you can write a brief, whether you know what's safe to hand off, and whether you report what broke. None of them require you to disclose which tools you touched.

The managers in that survey who rewrote their evaluation criteria put weight on three things: prompting ability, the judgment to decide what to delegate, and experimentation with new workflows. Read that list again. It isn't a list of technical skills. It's a list of decisions.

Prompting ability isn't typing speed or knowing magic phrases. In practice it's specification: can you state the constraints before you start? "Summarize this thread" and "summarize this thread for the account manager, four bullets, flag anything about billing, skip the scheduling chat" produce wildly different results, and only one of them needs a rewrite. The skill being graded is the brief, not the prompt.

Delegation judgment is the one that decides careers. Consider two engineers facing the same migration. One hands the whole script to an agent and ships it. The other hands the mechanical transformation to the agent and writes the rollback plan by hand, because a wrong migration is expensive to undo. Same tool, same task, different judgment. A good delegation decision looks exactly like no decision at all, right up until the one week it doesn't.

Experimentation is the cheapest to demonstrate and the most often skipped. Not "I tried a chatbot once." More like: we tested agent-written tests for two sprints, coverage went up, review time went up more, we kept the tests and dropped the review step. That's a finding. Findings are reviewable.

Here's the uncomfortable part. Nobody gets credit for the disaster they avoided, and the new rubric is full of avoided disasters. You can't demo a delegation call in a merged pull request. You can't show a reviewer the four hours you didn't spend. The evidence has to be written down somewhere, at the moment it happens, or it evaporates.

How do you prove a decision you made at 9:40 on a Tuesday that saved a week of work?

Work Got Harder to Judge Because Output Got Cheaper

When a three-day task collapses to three hours, volume stops being a signal, and volume is what most review processes were built on.

A forty-line fix that resolves a race condition is a better outcome than a four-hundred-line fix that papers over it. Every engineer knows this. Almost no performance system measures it, because measuring it requires reading the work instead of counting it. AI didn't create that gap. It widened it until the gap became the main thing.

Then there's the tool layer. The same Nielsen research found 57% of managers said their organizations had more tools in circulation after adopting AI, and 51% said those tools had become more interdependent. Only 29% described their AI setup as fully optimized and centralized. More surface area, more connections, less coherence.

There's a name for the practical result: tool sprawl. And it hurts evaluation in a specific way. The story of a piece of work now lives in fragments, a Slack thread where it started, a ticket where it got assigned, a doc where the deadline moved, a pull request where the actual reasoning ended up. A manager trying to reconstruct what happened is doing archaeology across five systems, and she has eleven minutes.

Atlassian has described AI spreading across the entire software delivery loop, planning, code, review, and incidents. Atlassian That's the right direction for tooling and the wrong direction for evaluation, because the decision points are scattered wider than ever. More dashboards, less narrative.

When the narrative is missing, people default to proxies. Lines of code. Ticket count. Response time. Proxies are cheap to compute and easy to game, and everyone in the room knows it. The teams that come out of this well won't be the ones with the best metrics. They'll be the ones where a person can point at a task and say: here's what I was asked, here's what I handed off, here's what I checked, here's what I decided.

The Five-Line Delegation Log

A delegation log is five lines per task, not a diary, not a journal, not a time tracker.

The five:

1. The request, in the requester's own words. Not your summary of it.
2. What went to the AI, and what deliberately didn't.
3. What you checked. The specific thing you verified, not "reviewed."
4. The decision. What you chose, and the one alternative you rejected.
5. What it created next. The follow-up task, the doc, the ticket, the thing someone else now owns.

That's it. A concrete example from a support team:

> Request: "Customers keep asking why their export is empty, can you fix the messaging?"

> Delegated: drafted six variants of the empty-state copy; did not touch the export logic.

> Checked: reproduced the issue on three account types; the cause was a permissions error, not messaging.

> Decision: shipped a two-line copy fix and filed a permissions ticket. Rejected rewriting the export flow this sprint.

> Next: permissions ticket assigned to Priya, review date Thursday.

Read that and you know what happened, who decided, and what it cost. It took ninety seconds to write.

The format matters less than the placement. A log kept in a separate document is a log that dies in three weeks. It belongs on the task itself, filled in while the work is fresh, because the alternative, reconstructing it the Friday before reviews, produces fiction. And if you're capturing a commitment that started as a sentence in a hallway, the gap between hearing it and recording it is the whole ballgame. If capture takes more than a minute, you'll stop doing it by Thursday.

Two rules keep it alive. Log decisions, not activity, nobody needs to know you opened a chat window at 2:15. And skip the log entirely on tasks where the reasoning is already visible in the diff or the doc. This is for the decisions that would otherwise leave no trace.

The Case Against Logging Everything

The obvious objection is that this turns into surveillance, and the objection is correct often enough to take seriously.

Any log a manager can read becomes a performance artifact within one review cycle. People figure out what gets looked at and start producing it. Write "checked: reproduced on three account types" and soon everyone claims three account types, whether or not they did. That's Goodhart's law wearing a project-management hat, and it's a real cost.

There's a second cost: overhead. A two-minute log on a ten-minute task is a 20% tax on work that didn't need a record. Do that fifty times a week and you've invented a job.

So here's a position, not a hedge: a log that describes everything describes nothing. Log only the decisions that (a) cost real money or time to reverse, or (b) will be invisible in ninety days. In most jobs that's maybe one task in five. For a solo freelancer it might be one in ten.

Permission matters too. If your organization treats task notes as manager-readable by default, say so out loud and let people write accordingly. A log written for a future version of yourself, the one who has to write a self-review in March, reads very differently from a log written for someone grading you in real time. The first is useful. The second is theater. The owner matters more than the format.

There's also a fairness edge here that doesn't get discussed enough. The survey data says 78% of managers changed how they evaluate. That means roughly one in five didn't. If your manager is in the other 22%, a five-line log is harmless but not urgent. If they're in the 78% and you have nothing written down, you're bringing a knife to a rubric fight.

Where an Agent Stops Being a Tool and Starts Being a Coworker

Background agents change the accounting, because the person approving an action is now the author of it.

The direction is clear. Anthropic has been building agents that work in the background, assembling briefings, drafting, suggesting next actions, and pausing to ask for approval before doing anything consequential. Anthropic Otter has pushed meeting software past transcription toward generating follow-up work. The pattern across all of them is the same: the machine does more, and the human signs off at specific points.

Those sign-off points are where accountability lands. A useful way to draw them:

• Auto-execute: reversible, low-risk, internal. Drafting a summary. Tagging a ticket. Creating a scratch doc.
• Draft for approval: anything externally visible. Emails to customers. Published content. Comments on a client's board.
• Require explicit confirmation: anything irreversible or expensive. Sending money. Deleting records. Moving a committed deadline. Merging to production. Assigning work to another person.

Call the middle and bottom tiers an approval checkpoint. The point isn't safety theater, it's that the approval is the authorship. If an agent drafted the customer email and you clicked send without reading it, you own the outcome. That's not a technical rule. It's the same rule that's always applied to a junior employee's work you signed off on.

Which brings it back to reviews. When a promotion case comes down to "what did you actually do," the answer in an agent-heavy job is a list of approvals and the reasoning behind them. Approvals that were never recorded are indistinguishable from work that never happened. That sounds harsh. It's also exactly how code review has worked for twenty years, the reviewer's name is on the merge for a reason.

Three Conversations Where the Trail Does the Talking

The trail pays for itself in three specific rooms.

The promotion conversation. Two engineers, same team. One kept everything running and can't name a single decision from the last six months. The other can point to six delegation calls, three where she handed work to an agent and three where she deliberately didn't, and what each one prevented. Guess which one gets the title. It's not about who worked harder. It's about who produced a record.

The renewal conversation. A freelancer's client asks what they've been paying for. "Forty hours a month" is an answer that invites a negotiation. "We cut your onboarding from nine steps to four, here's the decision that made it possible, and here's what I'd tackle next quarter" is not. One of those is a receipt. The other is an invoice with a shrug.

The investor update. "We shipped 40% more this quarter" invites the obvious follow-up: shipped what, and did it work? A founder who can trace one shipped feature from problem to decision to deployment to measured result is having a different conversation entirely.

The common thread: in all three rooms, nobody wants the full history. They want the three or four decisions that explain everything else. That's the whole reason a five-line log beats a detailed one, it produces exactly the compressed version someone will actually read.

And notice what makes these conversations possible isn't hindsight. It's capture at the moment of the decision, while the reasoning is still cheap to write down. The trail isn't paperwork, it's the only version of your work that survives the quarter.

The rubrics will keep shifting, and the next one won't be about prompting. Whatever it measures, it will need a record behind it. The people who'll do fine in that review are the ones already writing things down.