Remote engineering team: what works, what doesn't

When an executive hesitates to hand development to a team they will never pass in a corridor, the question they ask is about time zones. It is not the one worrying them. The one worrying them is: how do I keep control?

The question is legitimate, and the usual answer — reports, activity logs, tracking tools — is the wrong one. Surveillance produces documents, not software. What actually gives control is a delivery cadence short enough that a drift becomes visible before it becomes expensive.

The real objection

Nobody seriously doubts that good code can be written a thousand kilometres away. What is feared is the silence: three weeks without news, then a demo that does not resemble what was described, and no longer enough budget to start again.

That scenario is real. It has nothing to do with distance: it plays out identically with an in-house team whose work nobody looks at before the delivery date. Distance does not create the problem — it merely removes the informal catches, the conversation by the coffee machine that accidentally reveals a misunderstanding.

What follows replaces those catches with explicit appointments. None of them is specific to remote work; they are simply mandatory once it exists.

The regular demo

Once a week, or every two weeks: one thing that works, shown live, on a real environment. Not screenshots, not a status document, not a percentage.

It is the only indicator that cannot be arranged. A report can be written optimistically without quite lying; a feature operated in front of you either works or does not. And a weekly demo mechanically caps the possible drift: at worst, a week has been lost.

The corollary is on your side: you have to attend. A demo nobody comes to becomes an empty ritual within three weeks, then disappears.

A single point of contact — on both sides

Everyone insists on a project lead at the vendor. Almost nobody appoints one at home.

Yet that is the side where disorder costs most. Three people giving instructions produce three contradictory priorities; the engineering team then arbitrates on your behalf, based on who spoke last. The result resembles what nobody wanted, and responsibility is impossible to establish.

This does not mean one person decides everything. It means one person transmits the decisions, once they are made.

Writing decisions down

A decision taken in a meeting and not written does not exist. Six weeks later two people will remember two different things, both in good faith, and the arbitration happens again — with code already written in the meantime.

The format does not need to be heavy. Three lines are enough:

• The context — the question that arose, in one sentence.
• The choice — what was decided, and by whom.
• The consequence — what it makes possible, what it closes off.

The third line is the useful one. It is what gets reread when someone asks, a year later, why the system does not do a particular thing.

The permanent test environment

An address you can open at any time, unannounced, showing the real state of the project. Not a demo by appointment: a place.

It changes the nature of the relationship. You no longer have to ask where things stand, you can look. And the team no longer has to prepare a presentation, which frees time and incidentally removes the temptation to show only what works.

Technically it costs almost nothing — it is a copy of the application, fed with test data. A vendor not offering it unprompted is already telling you something.

Time difference, honestly

A few hours' offset is a genuine advantage: a question asked at the end of your day has its answer waiting in the morning, and a fix requested in the evening is in place by the next. Work advances while you are not working — which is exactly what you are buying.

The cost has to be acknowledged, though. Beyond six or seven hours, the shared window becomes too short for real exchange and has to be organised explicitly: a fixed, protected slot where both teams are available at once. Without it every round trip takes twenty-four hours, and a discussion that would have lasted ten minutes stretches across three days.

An honest team will tell you which of their hours genuinely overlap yours, rather than announcing a permanent availability nobody sustains.

What genuinely needs presence

Two moments, and they are not the expected ones.

Initial scoping. Understanding a business means seeing how people work, including what they never think to mention because it is obvious to them. A few days on site at the start of a project saves weeks of misunderstanding. It is where travel pays for itself best.

Workshops with end users. Watching someone use a first version, in silence, teaches more than ten written reports. Remotely you see neither the hesitations nor the moment the person hunts for a button that does not exist.

The rest — development, code review, releases, support, fixes — works perfectly well at a distance. This is not an ideological position: most in-house teams already work this way across two offices, two cities, or two days of remote work.

Distance does not make projects fail. It only makes visible the absence of method that, on site, was patched over by corridor conversations.

A simple test before committing

Ask to see the test environment of a project in progress — anonymised if need be — and that project's decision log. If both exist and are shown to you without preparation, the method is real. If you are offered a presentation instead, it is not yet.

Our Web & Mobile Development page describes the cadence we work to, and IT Advisory & Digital Transformation how we scope a project before writing the first line.