How to Check Your Remote Team's Work Without Micromanaging

You pay remote developers and cannot see them work. Checking the hours does not help, because hours are not what you bought. You bought software that runs, and you can check that without watching anyone’s screen.

The Agile Manifesto says it in one line: “Working software is the primary measure of progress.” The same document tells you to “build projects around motivated individuals,” give them what they need and “trust them to get the job done” (Principles behind the Agile Manifesto). Healthy accountability is both: you trust the people and you look at the output every week.

Does remote work cost you output? #

The best evidence we found is a six-month randomized trial of 1,612 employees at a Chinese technology company. Hybrid working (some days at home) did not affect performance reviews or promotions over the next two years, had no effect on the lines of code written by the engineers, and cut quit rates by a third. The managers in the study had expected a productivity loss of 2.6 percent before the experiment and revised their view to a gain of 1.0 percent afterwards (Bloom et al., Nature, 2024).

Read that carefully. It tested hybrid, not fully remote, in one company. Lines of code is a weak measure. What it does show is that “I cannot see them” is not by itself evidence that work is not happening. Do not spend your effort on surveillance. Spend it on the four checks below.

Four checks that need no technical skill #

1. A written update, once a week #

Daily updates become a chore for the team and noise for you. One weekly message is enough if it has a fixed shape:

Shipped: what a user can now do (with a link)
Next: what we start on Monday
Blocked: what we need from you, and what we already tried

“Shipped” must describe something a person can do in the product. “Worked on authentication” is activity. “Customers can now reset their password by email” is output. If three weeks in a row the Shipped line is empty or vague, you have learned something real.

2. A demo on a test version of the product #

Once a week, 15 minutes, on screen share or a recording. The developer clicks through what is new, on a staging site you can also open. You need no technical knowledge to notice that a feature does not do what you asked. Ask to try it yourself. Developers who are proud of a feature are glad to hand it over. A team that always has a reason the demo is not possible this week has told you something too.

3. The list of merged changes #

Every change to the code goes through a pull request, a proposed change that a teammate reviews and merges. The list lives in your company’s GitHub account, and with GitHub’s command-line tool you can read it in one line. This is what it prints for a public repository (snap-diff/snap_diff-capybara, read 30 October 2026):

$ gh pr list -R snap-diff/snap_diff-capybara --state merged --limit 5 \
    --json number,title,mergedAt,author --jq '.[] | "\(.mergedAt[0:10])  #\(.number)  \(.author.login)  \(.title)"'
2026-10-22  #312  oboxodo  feat: SNAP_DIFF_ACCEPT_SCREENSHOTS selects record: :all per run, on CI too
2026-10-20  #311  oboxodo  feat: one status per screenshot; record: :all compares before re-recording
2026-10-17  #310  oboxodo  fix: one predicate decides "are we on CI"
2026-10-17  #309  oboxodo  fix: count every assertion, and only comparisons that ran
2026-10-16  #308  oboxodo  fix: the HTML report lists new screenshots

You do not need to understand the titles. Look for dates close together, titles that describe a change, and no long gaps. The list also shows who does the work: all five here come from one author, which is normal for a small open source gem and a risk for a company product, because that person leaving takes the knowledge with them. We explain that risk in how to assess your team’s health in 15 minutes.

If the team cannot show you a list like this, or the repository belongs to the contractor rather than to you, fix that first. Create the GitHub organization yourself, make yourself the owner, and invite the developers in. Keep the hosting, domain and database accounts in your name too.

4. Two or three delivery numbers, tracked over time #

DORA, Google’s delivery-research program, defines the measures worth tracking: how long a change takes from commit to production, how often you deploy, and how quickly the team recovers from a failed deployment (DORA metrics guide). Ask for those three each month and watch the trend. DORA’s own warning applies to you as the person who asked: do not turn a metric into a quota, because the team will game it.

Questions that separate real progress from busy-looking work #

Ask these in the weekly meeting and listen for specifics:

1. What did you build this week, and where can I see it working?
2. Why is [feature] taking longer than we expected?
3. What is blocking you right now, and what have you already tried?
4. What would you change if you redid this week?
5. What should I see next week to know we are on track?

A concrete answer names a screen, a bug, a decision. A vague answer names a category of work (“backend stuff”). Repeated vagueness is a signal to ask for a code review from someone outside the team. Our post on questions to ask a dev shop goes further.

But I do not want to micromanage #

You are not micromanaging by asking for a weekly update, a demo and access to the repository. Micromanaging is dictating how the work is done: which tool to use, when to be online, how long a task should take. The four checks above ask only for results. If the team treats a demo request as an insult, the problem is not your process.

What to do on Monday #

1. Send the three-line update format to the team and ask for the first one on Friday.
2. Put a 15-minute weekly demo on the calendar.
3. Check who owns the repository and the hosting accounts. Move ownership to your company if it is not.
4. Ask the lead for the five most recent merged pull requests and the last release date.

If you want an embedded team that reports this way by default, see how we work. JetThoughts is rated 4.8/5 on Clutch.

Sources #

• Principles behind the Agile Manifesto - working software as the measure of progress; trust motivated people.
• Bloom, Han and Liang, Hybrid working from home improves retention without damaging performance, Nature, 2024 - 1,612 employees, six-month randomized trial.
• DORA, DORA’s software delivery metrics.
• Command output from snap-diff/snap_diff-capybara, 30 October 2026.