I Ran 60 Remote Developer Reviews in Singapore Before Realising 3 of My Questions Were Useless — Here Is the 7-Step Cycle That Replaced Them

The moment that changed how I run reviews was an engineer in Ho Chi Minh City telling me, politely, that he had prepared his answer to “how do you think you did” three weeks in advance, because he had learned that the honest answer was expensive. He was right. I had been running that question for sixty-odd reviews as though it were an invitation to reflect, when it was actually a test with one safe answer. Two of my other standard questions turned out to be the same. What follows is the cycle I use now for remote engineers managed from Singapore — seven steps, built around the only thing that survives distance: evidence.

The Three Questions I Retired

“How do you think you did?” In a manager-report relationship with a power asymmetry, this is not a reflective prompt. Confident self-assessors inflate, conscientious ones deflate, and the variance you measure is personality, not performance. Across cultures it is worse: in much of Southeast Asia, self-promotion to a senior is socially costly, so the engineers most likely to underrate themselves are often the strongest. Replace it with a specific request: “Walk me through the change you are most proud of this half, and what you would do differently.”

“Where do you see yourself in five years?” Almost nobody knows, and the ones who answer fluently have usually rehearsed a career narrative rather than described a preference. It also invites an answer the engineer thinks you want to hear — management, usually, from people with no desire to manage. Replace it with: “What kind of work would you like more of in the next six months, and what would you happily do less of?” That is answerable, honest, and actionable.

“Is there anything you need from me?” Asked at the end of a review, when the rating has already been delivered, this reliably produces “no, I’m good.” The engineer has just been evaluated and is not about to open a new topic. Replace it by asking a specific version earlier in the cycle: “What slowed you down most this half?” — and ask it in a monthly one-to-one, not in the review.

Step 1: Agree the Evidence Before the Period Starts

The single largest improvement available is moving the definition of “good” from the end of the period to the beginning. At the start of each half, write down for each engineer what will count as evidence: which projects, which kinds of contribution, and what a strong six months would look like at their level.

This takes about twenty minutes per engineer and eliminates the most common complaint in remote reviews — that the goalposts were invisible. It also protects you. When you rate someone as not meeting expectations, the conversation is about whether the evidence was met, not about whether your standard was fair, which is a much better conversation to be in.

Keep it short: three to five lines per engineer. A full scorecard will not survive contact with a shifting roadmap. What survives is a statement like “owns the payments migration end to end, including the rollback plan; mentors one junior through their first on-call rotation.”

Step 2: Gather Artefacts, Not Impressions

Before forming any view, collect the material. For each engineer, over the review period:

• Merged pull requests — and more importantly, what happened to them afterwards. Did they need follow-up fixes?
• Design documents written, and whether the decisions in them held up.
• Review comments given to others. This is the most underweighted signal in remote teams and the clearest indicator of a senior engineer who is raising everyone around them.
• Incident participation — who was in the room, who diagnosed, who wrote the follow-up.
• Questions answered in team channels. In a distributed team, the person who unblocks four colleagues a week is creating enormous value that appears in nobody’s metrics.

What to exclude, firmly: lines of code, commit counts, story points, hours logged. Each is easy to measure, trivially gameable, and uncorrelated with value. An engineer who deletes two thousand lines of dead code has a negative diff and has done excellent work. Use these numbers only as a prompt to go and look at something, never as an input to a rating.

Step 3: Correct for Visibility Bias Explicitly

This is the step that distinguishes a remote review cycle from a co-located one, and it has to be done mechanically because good intentions do not touch it.

Build a three-column list: every engineer, their overlap hours with you, and your draft rating. Then look for correlation. If your highest ratings cluster among the people in your timezone, or the people who speak most in meetings, or the people whose first language is English, you have found visibility bias. In my own first pass, four years ago, the correlation was almost perfect and I had genuinely believed I was rating contribution.

The correction is procedural: read the artefacts from Step 2 before you consult your memory, and for any engineer you rate below their peers, require yourself to name three specific artefacts supporting that view. If you cannot find three, your rating is an impression.

Step 4: Collect Peer Input That Is Safe to Give

Open anonymous feedback forms produce two things: silence, or score-settling. Neither is useful. Instead, ask two or three named peers three specific behavioural questions about each engineer:

1. When you were blocked in the last six months, who helped, and what did they do?
2. Whose code review comments have changed how you write code?
3. If you were starting a difficult project next month, who would you want on it, and why?

These work because they ask for description rather than judgement. Nobody has to rate a colleague; they just have to say what happened. The third question is the most predictive one I have found — it surfaces the quietly indispensable engineers who never appear in a status update, and in remote teams those people are systematically underrated.

Step 5: Write the Review Against the Evidence

Draft every claim with its supporting artefact attached. Literally: write the sentence, then paste the link. Then delete any sentence you cannot evidence — including the complimentary ones, which are the ones people skip. “Great team player” with nothing behind it is worse than useless; it teaches the engineer that the review is decorative, and it gives them nothing to repeat.

Structure each review in four parts, and keep it to a page:

The fourth section is the one most managers omit and the one engineers remember. A review that asks for change without offering anything is a demand, not a development conversation.

Step 6: Calibrate Across Managers Before Delivery

Calibration is where a remote organisation either establishes one standard or quietly maintains two. Get every manager in a room — virtual is fine — with their draft ratings and their evidence, and have each defend a rating that sits at the top or bottom of their distribution.

Ask one question explicitly in every calibration: are the remote engineers and the in-office engineers being held to the same standard? The usual finding is that remote engineers need more documented evidence to earn the same rating, because their work is less ambiently visible. That is a bias in the process, not a difference in the people, and naming it in the room is the only reliable way to fix it.

Calibration also protects against the manager who rates everyone highly to avoid difficult conversations, which is particularly common with offshore reports where the manager feels guilty about the pay differential. That kindness is expensive: it denies the engineer the information they need to grow and it makes any future performance conversation indefensible.

Step 7: Run the Conversation as a Dialogue, Then Follow Up in Writing

Send the written review at least 24 hours in advance. Reading a review aloud to someone over a video call while they process it in real time is the worst possible format, and it is worse still across a language barrier. Let them read it, absorb it, and arrive with questions.

Use the meeting for the parts that need a human: the disagreements, the context behind a rating, and the conversation about what they want more of. Video on, if both parties are comfortable — this is one of the few conversations where the bandwidth is worth it.

Then write up within 48 hours: what was agreed, what you committed to, and what happens next. For remote teams this is not bureaucracy. It is the only durable record either party has, and six months later it is what makes the next review a continuation rather than a fresh start.

Singapore Specifics Worth Getting Right

Three local considerations apply. First, documentation quality matters most when performance concerns lead to dismissal or dispute — keep contemporaneous records of concerns raised and support offered rather than reconstructing them later, and apply the same evidence standard to remote and in-office staff so the process is demonstrably consistent. Second, performance records about an identifiable person are personal data under the PDPA, so store them with the same access controls you would apply to any other personal data rather than in a shared drive folder. Third, if your engineers are employed overseas through an employer of record, your review discipline still applies but the employment rules of their jurisdiction govern any formal process — confirm with the EOR before a performance conversation becomes a formal one.

If you are managing across the Gulf as well, the timezone mechanics that make or break these cycles are covered by our colleagues in their guide to managing timezone overlap for Dubai remote teams, and their employer guides cover the UAE equivalents of the documentation points above.

Locally, the step most worth doing this week is Step 3 — build the three-column list and look at the correlation. It takes fifteen minutes and it is the only one of the seven that can change a rating you were about to deliver. If the exercise tells you the problem started at hiring rather than at management, our TypeScript developer profiles and data engineering profiles are screened for the async working habits that make remote contribution visible, and building a fintech product in Singapore covers the documentation standards regulated teams inherit.

FAQ — Remote Developer Performance Reviews in Singapore