How to write performance reviews for remote engineers
How to write performance reviews for remote engineers
A performance review for a remote engineer is a written evaluation built from artifacts the engineer produced (PRs, Linear tickets, design docs, incident write-ups) rather than from manager observation. The review compares those artifacts against goals set in writing at the start of the period, separates growth feedback from compensation, and is calibrated with peer managers before delivery. Meetings are for discussion, not for forming the opinion.
If you skip the artifact step, you are reviewing the engineer's Slack presence. That is the single biggest failure mode of remote performance management.
Why the in-office review playbook breaks remotely
The classic review is built on ambient signal. You walked past someone's desk. You saw who stayed late. You overheard a whiteboard debate and remembered who carried it. None of those signals exist on a distributed team.
What replaces them, by default, is Slack visibility. The engineer who posts in #general at 8am UTC and replies in threads all day "feels productive." The engineer who shipped a hard refactor while quiet in Slack "feels checked out." Both feelings are wrong. The first is a strong communicator, possibly a weak shipper. The second is the inverse. Without a written-evidence requirement, you will reward the first and quietly write off the second.
This is the "raised wrist" problem. In a meeting room, the loudest hand goes up. In Slack, the most timezone-aligned person posts first. If your engineering team spans UTC+10 to UTC-8, the same three people dominate every channel because they happen to be awake when your morning ritual runs. Their work is not better. Their visibility is.
A remote review system fixes this by inverting the default: nothing counts unless it is written down, and the written record is the engineer's, not the manager's.
The artifact-first review: what you actually pull
For a six-month review of a mid-level backend engineer, you should be able to assemble the evidence pack in 45 minutes without talking to anyone. The sources, in order:
- GitHub / GitLab activity. Every merged PR in the period. Group by repo. Note the median diff size, the median time-in-review, and the count of PRs that required more than one round of revision. Pull the three largest changes and read them.
- Linear / Jira tickets. Every ticket the engineer owned. Note completion rate against the original estimate, count of scope changes mid-ticket, and how often the engineer left a written update vs. dropped silent.
- Design docs and RFCs. Any architectural document the engineer authored or substantively commented on. A senior engineer should be producing or shaping these. A mid should be commenting thoughtfully on others.
- Incident write-ups. PagerDuty incidents the engineer responded to, and the post-incident docs they authored or contributed to. The quality of an incident retro tells you more about senior judgment than any 1:1.
- Peer review feedback, gathered by doc. A shared Notion or Coda doc with 5 to 8 questions, sent to 4 peers the engineer worked with directly. Async, written, due in 5 business days. Never a meeting.
The peer doc matters most. The structure we recommend has five sections: where did this engineer raise your bar, where did they lower it, one decision they made that you would have made differently, one moment they were generous with their time, and a numeric trust score (1 to 10) on shipping without follow-up. A free-text "anything else" field catches the rest.
Compare that against what a meeting-based 360 gives you: opinions filtered through whoever talks fastest, no paper trail, and a manager who has to translate vibes into a written review afterward. The doc is cheaper, more honest, and produces evidence you can quote in the review itself.
A sample review template that works for remote engineers
Use this verbatim or adapt it. The structure is the point: every section is anchored to an artifact, not a feeling.
## Engineer: [name]
## Period: [Q1 2026, Jan 1 to Mar 31]
## Tier: Mid-level backend
## Reviewer: [manager name] (calibrated with [peer manager name] on [date])
### 1. Goals set at period start (verbatim from the goals doc)
- G1: Ship the billing-webhooks refactor end-to-end by Feb 15
- G2: Reduce p95 latency on /api/orders below 400ms
- G3: Mentor the new junior on testing patterns
### 2. Evidence (artifacts only)
- 23 merged PRs across 4 repos. Median diff: 180 lines. Median time-in-review: 1.4 days.
- G1: Shipped Feb 12 (3 days early). Linked PR: #4421. Post-launch incident count: 0.
- G2: p95 now 310ms (was 720ms). Linked dashboard snapshot. Linked PR: #4503.
- G3: 8 PR reviews left for the junior with substantive feedback. 1 pair-programming Loom recorded.
### 3. Peer signal (5 peers responded, due-date hit)
- Trust score median: 8/10
- Where they raised the bar: 4 of 5 cited the webhook refactor RFC as the cleanest doc they read this quarter.
- Where they lowered it: 2 of 5 noted slow async response on EU mornings (engineer is UTC-5).
- Generous moment: helped the junior debug a race condition on a Friday evening.
### 4. Growth feedback (separate from comp)
- Strength to keep: written design clarity. The webhook RFC is being used as a template.
- Stretch: take ownership of one cross-team initiative next quarter. Pattern match to senior tier.
- Tactical: improve EU-morning response time. Either pre-write a status post the night before, or set explicit "I'll be online at X" expectations.
### 5. Compensation outcome (separate doc, separate conversation)
[Filled in only after calibration. Not delivered in the same meeting as growth feedback.]
The template is boring on purpose. Boring is calibratable. When every manager on your team uses the same five sections, you can put six reviews side by side and have an honest conversation about which engineers are actually performing at their tier.
Calibration sessions: the hour that protects fairness
Calibration is the one synchronous meeting in the whole process. Block 60 to 90 minutes. Every manager brings their drafted reviews. You read three at random aloud, then ask: would this same write-up land an engineer at tier X on every other team here?
The honest answer is usually "no" the first few times you run it. One manager grades to a tougher rubric than another. One uses peer scores as the headline; another uses them as a footnote. Calibration is where you flatten those gaps before the engineer ever sees the review. If you skip calibration, you are not running a review system. You are running a "what does your manager think today" system.
For teams that adopt the practice for the first time, expect 30% of drafts to get materially rewritten in the first calibration round. That number should drop to under 10% by the third cycle. Many of the patterns here pair well with the rituals in our async communication guide for engineering teams in 2026, since both depend on the same written-by-default discipline.
Biases remote managers fall into (and how to debias each)
| Bias | What it looks like | The debias |
|---|---|---|
| Slack-visibility bias | "Sarah is always responsive in #eng-help" carries more weight than "Sarah shipped 4 of her 4 goals." | Score artifacts before opening Slack. Strip the engineer's name from PR lists and re-score the work blind once. |
| Timezone bias | The 3 engineers whose mornings overlap yours feel like the strongest team. | Pull peer-signal docs from engineers in the underrepresented timezone explicitly. Add their voice to calibration. |
| Recency bias | The last 4 weeks dominate the review. | The artifact pack must be pulled across the full period, with a row-per-month rollup. Force yourself to read March 1 before March 31. |
| Tooling bias | Engineers who post Looms feel more "visible" than engineers who write tight docs. | Equal weight to artifact types. A 600-word RFC is worth at least one Loom. |
| Affinity bias | The engineer you have weekly 1:1s with feels more known than the one you meet biweekly. | Calibrate with a manager who has the inverse relationship. They will catch your blind spots. |
The raised-wrist problem (engineers in quiet timezones underrepresented in calibration because they did not raise their hand often enough) deserves a standing fix: in every calibration round, pull the artifact pack of one engineer the room did not nominate, and review them anyway. The signal is almost always there. Nobody talked about it because they were not on the same Slack hour.
Why growth feedback and compensation must be separated
Combining them is the most common reason performance reviews go sideways remotely. The engineer hears "you should grow into more cross-team work" and immediately translates it as "and that is why my raise is small." The growth note becomes a justification for the comp decision, which means the engineer cannot hear the growth note as a growth note. It is now a defense to argue with.
Run them as two conversations, at least a week apart. The first is written, delivered async, with one synchronous follow-up if the engineer wants it. The second is the comp outcome, also written, with the calibration logic visible. The engineer should be able to read the comp memo and reconstruct why the number is what it is.
This separation gets easier when comp itself is rule-based rather than negotiation-based. A clear tier ladder (with explicit signals for each rung) means the comp conversation is "you are mid, mid pays X, here is what senior looks like and here is the evidence gap." On Cadence, every booking sits on a four-tier ladder visible to both sides from minute one, which is part of why the awkward "what should I pay you" round-trip disappears. The principle works the same on full-time teams; you just have to write the ladder down.
When a remote review surfaces a hire that is not working
Sometimes the artifact pack and the peer signal converge on the same conclusion: this is not the right fit. Remotely, this is harder to act on, because the engineer is usually a contractor in a different country, with notice periods and severance norms that vary by jurisdiction. The default move is to drift for another quarter and "see if it improves." It rarely does.
A faster path is to architect the working relationship so that exit is cheap and non-punitive from day one. Weekly engagements with no notice period beat 6-month contracts with PIPs every time. If you are still inside a recruiter-led hiring loop, look at how Wise vs Deel vs Stripe Connect compare for the contractor-payment plumbing that makes weekly billing actually work.
This is also the operational frame Cadence runs on by default. Engineers are booked by the week, daily ratings drive auto-replacement, and either side can end the engagement at the week boundary with no severance choreography. The review process still matters (we publish written retros every Friday), but the cost of a mistake is one week, not one quarter.
If you are about to start a new engagement and want to skip the recruiter loop, you can find your remote engineer in 2 minutes on Cadence with a 48-hour free trial. Every engineer is AI-native by default (Cursor, Claude Code, Copilot fluency vetted in a voice interview before they unlock bookings), which collapses one common review-period axis: you do not have to grade "did they keep up with the tooling" because the baseline is enforced upstream.
Comparing the four common remote review systems
| System | Cost / time | Best for | Where it breaks |
|---|---|---|---|
| Ad-hoc manager memo | Free, 2 hours per engineer per cycle | Teams under 8 engineers | No calibration; reviews drift across managers within 2 quarters |
| GitLab-style handbook reviews | Free, ~4 hours per engineer | Teams committed to public handbooks | Heavy upfront authoring; slow to iterate the rubric |
| Lattice / 15Five | $8 to $15 per user / month | Teams 25+ that need HR audit trail | Bias toward survey questions; can devolve into checkbox theater |
| Weekly written retros (Cadence pattern) | Built into weekly billing cycle | On-demand / contract engineers | Less suited to long-tenure career-ladder conversations |
There is no single right answer. A 30-engineer full-time remote team probably wants a Lattice-style system plus quarterly calibration. A founder running a 4-week sprint with two booked engineers wants weekly written retros and nothing more. If you are still designing the underlying team shape, our remote engineering team setup checklist for 2026 covers the structural decisions that come before any review system makes sense.
What to do next
Pick the smallest viable change that moves you toward written-evidence reviews. Ordered by impact:
- This week, draft the peer-review doc (5 questions, async, 5 business-day deadline). Use it on your next review.
- Next month, run one calibration session with even one peer manager. Just one. The first one is the hardest and the most useful.
- Next quarter, split growth feedback from comp into two separate written deliveries.
Do not try to import a Lattice-shaped process into a 6-engineer team overnight. Do try to make one review this quarter that an outside observer could read and reconstruct exactly why the engineer is at the tier they are at.
If your current bottleneck is the engineering bench itself rather than the review process (the team is too small, the wrong shape, or stuck in a 90-day hiring loop), the fastest unstick is to book a vetted engineer by the week and see how the work changes when you can ship in days instead of months. Cadence's onboarding is two minutes, the trial is 48 hours, and weekly billing means you can shape the engagement around the review rhythm you actually want.
FAQ
How often should remote engineers get performance reviews?
Lightweight written check-ins every month (15 to 20 minutes for the manager, anchored to that month's artifacts), full reviews quarterly, and a deeper calibration cycle every six months. Remote teams that wait a full year between reviews almost always drift on tier alignment and lose engineers to either resignation or quiet underperformance.
What is the biggest mistake managers make in remote performance reviews?
Reviewing the engineer's Slack presence instead of their artifacts. The fix is to pull the PR list, the Linear ticket list, and the design-doc list before opening any chat tool, and to score those first. If the artifact-only review and the gut-feel review diverge, the artifact-only review is almost always closer to the truth.
Should I include peer feedback in a remote performance review?
Yes, always, and gather it via a written doc rather than a meeting. A shared Notion or Coda template with 5 to 8 questions, sent to 4 peers, async, due in 5 business days. The written format gives quieter engineers in non-overlapping timezones an equal voice and produces a citable record you can include in the review itself.
How do I review an engineer in a timezone I rarely overlap with?
Pull their artifact pack first (PRs, tickets, docs, incidents) and score it before you score anything else. Explicitly solicit peer feedback from at least two collaborators in their timezone. In calibration, surface their name even if no one in the room nominated them. The "raised wrist" problem of quiet-timezone engineers being underrepresented is solved by manager discipline, not by waiting for the engineer to ask.
Should performance reviews and compensation conversations happen at the same time?
No. Run them as two separate written deliveries at least a week apart. Combining them turns growth feedback into a justification for the comp number, which means the engineer cannot hear the growth feedback. Calibrate first, deliver growth feedback, then deliver comp with the rubric logic visible.