Timezones your reporting gets wrong, contractor status your software ignores, and the belonging problem nobody builds for. From a business that runs one.
12 September 2026 · 10 min read
We run a team across two countries. This is what we got wrong, in the order we got it wrong, and what we changed.
It is not a guide to hiring offshore. It is about the operational parts that break afterwards, which are rarely the parts anyone warns you about.
The first thing to go is not communication. It is your numbers.
Most workforce tools carry one timezone for the organisation. It is set once, usually to head office, and every report is rendered in it. That works perfectly until part of your team is somewhere else, at which point the tool starts producing confident, wrong statements about real people.
Ours did exactly this. Our burnout signal counted late-night activity — reasonable, except that "late night" was calculated against a single Darwin offset. Our Manila team appeared to be working through the night, every night, because 9am for them is the middle of our reporting day. The system flagged half of them.
The reason that is worth telling is not the bug. It is that the output looked entirely plausible. A dashboard saying several named people are at burnout risk does not announce that its arithmetic is wrong. Somebody nearly had a conversation with a colleague based on it.
Fix: each person carries their own timezone, and their working day is read in their local hours. If your current tool cannot do that, its reporting about anyone outside head office is noise, and you should find out before you act on it rather than after.
Offshore staff are frequently engaged as contractors. That is a different legal relationship, and it changes what you may reasonably do.
Most workforce software has one concept: a user. Some add roles, but role is about permissions — what someone can see — not about what someone *is*. So a contractor gets treated as an employee by every feature that does not know the difference. Monitored like an employee. Nudged to clock in like an employee. Included in reports written about employees.
We had this wrong too. Three contractors were typed as employees in our own system, which meant the rules that should have exempted them simply did not fire.
Fix: worker type as a separate field from role, and a ceiling rather than a switch. In our product a contractor is never monitored regardless of what the monitoring setting says, because the type overrides the switch rather than being checked alongside it. If the rule lives only in a policy document, it will be missed by whoever sets up the next person.
Worth checking on your own setup: if you turned monitoring on across the workforce tomorrow, would your offshore contractors be included? In most tools the honest answer is yes, and nobody would notice.
Australian staff are covered by an award. Offshore contractors are not. Those are separate calculations and separate obligations, and the mistake is usually in the direction of applying nothing to either.
Keep the Australian side rigorous — penalty rates, loadings, overtime thresholds computed from the actual clock record, with the working visible. Keep the contractor side simple and documented: hours tracked, invoices reconciled against them, rates recorded somewhere other than an email thread.
The failure we see most is a business that runs its Australian payroll carefully and its offshore arrangements from memory, then cannot answer a straightforward question about what someone was paid eight months ago.
The operational parts are solvable. The one that quietly costs you is that an offshore team can end up as a resource rather than as colleagues.
The symptoms are mundane. They are not in the group chat where decisions actually get made. They hear about changes after they are decided. Nobody knows what they did last month. They have never seen the people whose work they support.
None of that is malice. It is what happens when the default communication channel is a room they are not in.
What helped us: one place where everything is discussed rather than a chat tool for the office and email for everyone else. An all-hands that includes them rather than being scheduled at a time only Australia can attend. Making sure the work they ship is visible to people who did not commission it.
It is the least technical part of this article and the one that determines whether the arrangement lasts.
Australian employees have a right to refuse unreasonable contact outside working hours. Offshore contractors generally are not covered by that — and the practical risk is the opposite of what you would expect.
When your team spans timezones, "outside hours" is ambiguous by construction. Somebody's morning is somebody's evening. Without a rule, the quiet default is that the offshore team absorbs the mismatch, because they are the ones who are junior, newer, or engaged commercially rather than employed.
Decide it explicitly. Ours is that notifications follow the person's own working hours, whoever they are and wherever they sit, and urgent still gets through. A contractor has no statutory right to disconnect; that is not a reason to ping them at 11pm.
1. Does your reporting use each person's timezone, or one office offset?
2. Is contractor status a distinct field, and do features actually read it?
3. If monitoring were enabled workforce-wide tomorrow, who would be included who should not be?
4. Can you answer what an offshore contractor was paid, and for which hours, without opening an email thread?
5. Is your offshore team in the room where decisions are made, or told afterwards?
We failed at least three of those at some point. The first one produced a dashboard that was wrong about named people and looked right, which is the kind of failure worth designing against rather than apologising for.
Offshore works when the systems treat those people as colleagues in a different timezone rather than as an exception the software was not built for.
Check your timezone handling first. It is the one that is already producing wrong answers you have not noticed.