How much travel, and whether it can be remote

The travel question is usually asked as a lifestyle question and is actually a method question. Deployment work has one property that resists remote: the information you need is where the work happens, and it is not in the documents. It is in the tab the operator keeps open, the exception everyone knows about and nobody wrote down, and the sigh before a certain case.

What the on-site share is for

Three things, and only the third can be moved online.

Watching the work. You cannot ask enough questions to reconstruct a process, because the person answering does not know which parts are unusual. An hour of watching replaces a day of interviews.

Access and trust. Access is procedural; trust is not. The operator who hands you a messy record does it because you sat next to them, not because the ticket was approved.

The readout. This one can be remote, and often should be — a decision meeting with the sponsor rarely needs a plane.

Practical shape, from public hiring descriptions and the field: an intense first two to four weeks at the customer, then a rhythm of one to three days a week, tapering as the system stabilises. Roles that advertise "up to 50%" are describing a heavy deployment period, not an average.

The arrangements that reduce it honestly

Anchor weeks. Instead of three days a week for months, take one full week a month on site and stay remote the rest. Same physical days, far better quality: the on-site week is spent watching and the remote weeks are spent building what the watching revealed.

A named on-site counterpart. The single most effective travel reducer: one person on the customer side who can be eyes and hands, briefed weekly, with their time actually allocated. Without the allocation it becomes unpaid work for them and stops happening.

Watch the work, not the meeting. If the visit consists of conference rooms, it produced nothing that email could not. Insist on a desk next to the operator for at least half of every visit.

Instrument before you leave. Every trip should end by adding one observable thing that reduces the next trip. A team whose travel does not decline over a deployment is not instrumenting.

Where remote changes the job

Three cases where a remote-first arrangement is fine, and one where it is a different role.

Fine: work on a platform whose users are internal engineers (they will show you their screens willingly), incremental work on a system whose behaviour is fully logged and whose owner is technical, and follow-on deployments at a customer you already know.

A different role: a workflow operated by non-technical staff on a site with physical processes. Attempting this remotely produces a system that satisfies the sponsor's description of the process rather than the process, which is the exact failure the discovery bank exists to prevent — and it is much harder to detect when nobody is in the room.

The honest costs

Travel in this role is not glamorous. It is early flights to industrial parks, hotel wifi, and a Tuesday evening spent rewriting notes before they go stale. The teams that do it well make two structural choices: they cluster customers geographically where they can, and they protect the day after travel for writing rather than meetings.

Two questions worth asking an employer, beyond the percentage: how many consecutive weeks was the last person on site, and who books and approves travel. The first tells you the real rhythm; the second tells you whether a three-week trip will be reimbursed in three weeks or three months.

What the travel buys

The thing that cannot be bought any other way is the moment when a user says something they did not intend to say — the aside that reveals the process is not the documented process. Every method on this site assumes that moment happens. The four-week rule measures whether the habit formed; the habit rarely forms without someone having sat in the room long enough to see why it would not.

A decision framework

If travel is a hard constraint rather than a preference, three paths are open: choose vertical platforms where the users are technical, choose a role closer to the model and further from the customer, or negotiate a defined presence — one week a month, contracted, with the counterpart named. What does not work is accepting a travel-heavy role and quietly doing it remotely; the customer notices in month two, and by then the thing that was lost is the one that is hardest to rebuild, which is their belief that you understand their process.