Governing a remote team: what to require, and how often

When a team works in your offices, you know what is happening without asking: you see who is there, you overhear discussions, you sense tension. Remotely, that information disappears, and nothing replaces it automatically.

The risk is therefore not that the team works less well. It is that you find out too late that a problem exists.

The minimum arrangement

A written weekly report. One page, sent on Friday, readable in three minutes: what shipped, what is in progress, what is blocked and by whom, days consumed against plan.

The most important item is "blocked and by whom". In eighty per cent of cases it points to something on the client side: a pending decision, an access not granted, an unavailable environment. Without that line, the blockage stays invisible until the monthly committee.

A fortnightly demo on a real environment. You watch it run, you do not read a progress report. The rule that makes the demo useful: a feature that cannot be demonstrated does not count as delivered. That eliminates the "90% done" category that never advances.

A monthly committee. One hour, with the pack sent forty-eight hours in advance. Budget consumed, open risks, decisions awaited on your side, technical debt created or repaid.

A quarterly access review. The named list of who has access to what on your side, with revocation of anything no longer needed. It is a security requirement and also an excellent tell: if the provider cannot produce that list, they are not managing their access.

What does not work

Automated dashboards alone. A velocity indicator or a ticket chart says nothing about what is hard. It gives a feeling of control without the corresponding information.

Daily calls with the client. They consume time on both sides and replace writing with speech, which leaves no trace. The daily stand-up belongs inside the team, not with you.

Reporting on time spent. Counting hours measures presence, not progress. If you need that indicator to feel reassured, the problem lies elsewhere.

The principle that simplifies everything

Work in your tools. Your repository, your ticket tracker, your team messaging, your CI chain.

That avoids double entry, keeps traceability on your side, lets you observe progress without asking for it, and means that at the end of the assignment there is nothing left to retrieve from the provider. It is also, incidentally, the best reversibility clause there is: it applies without having to be invoked.

The signal to watch

A weekly report that never mentions a blocker. Every project runs into difficulty; reporting that flags none is not describing reality, it is describing what the provider thinks you want to read.

Say so explicitly at kick-off: a report with no sticking point is a suspicious report, and flagging a problem early has never been held against anyone.