Offshore Web Time Zone Guide
What should be a straightforward project can be made into a relay race by the time zone challenges of offshore web development, with all parties holding a different baton. The disparity in time zones will have an impact on an Australian company’s team morale as well as their deployment handoffs, approvals, bug fixes, code reviews and meetings.
There is a simple way to handle it. Put in place response SLAs before you start developing, make your working hours a conscious choice, set aside a core overlap each day and leave no room for ambiguity in how you document decisions. I am Isadora Fletcher and my experience with clients and remote work has taught me that the most intractable problems are seldom technical; they are the kind of thing like a message left to go unanswered or a decision put on hold while half the team is asleep.
The Case For Early Attention To Time Zones
Consider time zones a matter of delivery, not just something on the diary. Your product owner could be fast asleep when a developer in another country puts the finishing touches on a task and there are questions to be had. This is central to Australia local vs global development choices.
You may not think much of such a delay. But do it enough in a sprint and you will see limited overlap in work hours and decision-making slow down. It becomes part of the project architecture, planned or otherwise.
Put The Working-Day Gap On Paper
Map out what constitutes a normal day for every team in local time and in Australian Eastern, Central or Western time. Factor in daylight saving, seasonal patterns, public holidays and any leave that has been put in. Before the first public holiday even comes around, an offshore team, Perth and Sydney will be on different clocks.
Do not be under the impression a two hour differential will be the same at year’s end; daylight saving will alter the gap between overseas and the various Australian states. Make a note of the UTC offset and time-zone name in your project documentation, abbreviations are too open to interpretation from one country to the next.
Delivery And Time Zones
A question coming in after the other side has logged off is where the communication difficulties of offshore software development tend to start. By the time a reply is forthcoming your team is done for the day and you have a 24-hour loop for a ten-minute decision. Maintaining core team hours helps mitigate these delays by ensuring overlapping working times across different time zones.
It is not just talk. A ticket on hold means a code review is put back, testing follows suit and a release is shunted to the following sprint. The quality of the work is there but the waiting makes for a sluggish project.
An Example Of A Blocked Ticket
Take an Australian product manager in Perth who at 4.30 pm is over a feature and wants to know if a payment error is best shown in plain English or with a technical message. The comment is seen by the offshore developer come the morning, he seeks clarification and his answer is in after he is finished.
No one has been remiss and nothing is amiss, but the ticket has cost a working day. Do that with ten decisions and you will see the project wobble. It is a common challenge in this line of work because the delay is so well concealed in the workflow.
When Clock Gaps Cause Trouble
Outsourcing can make process weaknesses more apparent. Leave requirements vague or ownership in doubt and the different local mornings will soon show it.
One is hard pressed to find anyone who does not think offshore is slow on account of being offshore. More often than not the problem is there is no method in place for the hours when people cannot be reached.
Things That Will Trip Up A Team
Some of the usual suspects are:
- Urgent matters that wait overnight for want of an owner.
- Code reviews that fall outside the window of the next developer.
- Bug fixes held up until a log or screenshot is in hand.
- A deployment with no one online to vouch for its success.
- The weekly meeting at the same inopportune hour.
- And the burnout of those on late night or early calls.
All of which takes a toll on cohesion and work-life balance. You will find a developer will not be as forthcoming in an 11pm meeting, though the dashboard would have you believe the project is fine.
Sprints, Reviews And Meetings
You will see your time-zone planning in your meetings. They can bring about alignment or, if poorly timed, be more of a drain.
With code reviews and sprint planning you need to be circumspect as they happen in the interstices of a working session. Should the reviewer be offline for eight hours the author will have put the context aside for something else or be too late in the day to get the sprint done.
Review Momentum: How to Protect It
Establish review expectations in line with the working overlap that actually exists. A team may determine, for instance, that a pull request of any standard nature will be answered in a day, but if it is blocking a release one should expect a response in two hours of common time.
Have your review comments on GitHub and make sure every discussion is tied to the appropriate Jira or Trello ticket. Do not let decisions get dispersed over email, Slack, Zoom or private channels. What you cannot put your hands on later is no more than a rumour in work clothes; it does not make for sound project documentation.
In sprint planning it is well to have a definition of “ready” before the sprint is underway. Laying out the acceptance criteria, test data, designs, dependencies and who has the authority to field questions will see off many of the pauses that come from a lack of context.
Offshore Team Hours
The way to handle offshore teams and their time zones is with an arrangement that is visible and repeatable as well as fair. One is not trying to impose Australian hours on all comers, but to put in place some shared time for decision making without upending schedules on a permanent basis.
For an Australian business, time-zone management in offshore development is an operating agreement. Put it in writing, put it to the test in a live sprint and be prepared to alter it if the evidence warrants.
A Core Overlap Window
There should be a short window of core overlap where key personnel are on hand. Two hours on a weekday will do, subject to daylight saving and where one is located. Reserve it for things like architecture or risk reviews, demonstrations and release planning where a live discussion is of value.
Where the time gap is considerable, rotate the less convenient meeting times. Resentment is to be expected if the offshore side is always left with the late night and the Australians with normal office hours. Fairness is no soft option; it is what ensures better retention and safer decisions, to say nothing of clear communication.
But do not let the window get so large as to encroach on focused work. An entire day of overlapping meetings is counter to the purpose of offshore delivery and will have everyone as flat as a pancake by Friday.
Documentation on an Async-First Basis
An async-first approach means a developer has the information at hand to get on with it and need not wait for a meeting, while the Australian team can look over progress in its own time. The most effective systems are plain, even boring, which is as it should be. They leave no room for doubt as to what comes next and one does not need a detective licence to use them.
Writing for the Next Morning
A good handoff tells you what has been done and what is still to do, what is in the way and what call has to be made. Provide links to the logs, the test environment, the PR, design and ticket. Give a deadline in a proper time zone (“Wednesday 3.00 pm AWST”) instead of “tomorrow afternoon”.
It should address these four points:
- What was put to bed?
- What requires attention?
- What might impede progress?
- Who is to decide?
Slack is fine for a bit of coordination, but durable decisions belong in the project’s documentation space or in Jira, Trello and GitHub. Have a conversation on Teams or Zoom if it is called for and then put the outcome down in writing. Without written actions a recording is just a digital cupboard of forgotten things.
Follow-The-Sun Handoffs
When regions are involved this type of workflow can build momentum. A team completes a task, puts in some notes and passes it on for the other to pick up in the course of its day. But the handoff has to be complete or it is not much of a model. To pass something unfinished with a “please check” is to present a minor mystery at someone else’s breakfast table.
Handoffs Must Be Release-Safe
Be explicit about the handoff point in development. The developer puts forward a pull request, the evidence of testing, any limitations and a suggested next step. The team on the receiving end must be clear on whether they are to merge, deploy, test or review.
Put one person in each region on the hook for deployment handoffs and make sure the escalation path, monitoring and rollback instructions are in order along with access rights. Do not count on having one individual awake and watching his notifications. People go on leave or the internet fails or there is life to be lived.
Then measure the workflow against such indicators as the age of a blocked ticket, average response and review times, deployment incidents and sprint carry-over. The numbers will show if the setup is aiding delivery or simply shuffling the waiting.
Tools to Minimise Waiting
No tool will fix a poorly run project, though they can bring the risks of different time zones into view. In the end the behaviour around the tool is of greater import than the tool itself.
For teams in need of reporting and workflows with a good deal of detail, Jira is an option. A smaller board where ownership is unambiguous is better served by Trello. Then there is GitHub for the purposes of code review and to air issues; for quick coordination one will turn to Slack, Zoom or Microsoft Teams. The key is to be selective with tools and put each piece of information where it ought to be.
Track The Right Signals
| Signal | What It May Show | Useful Response |
|---|---|---|
| Blocked tickets past a working day | Decision-makers are not on hand to answer questions | Put in place an alternate approver and have your escalation rules on record |
| Code reviews over a day old | There is no clarity as to who owns the review or if there is overlap | Set response SLAs and have reviewers in place prior to any work |
| Sprint carry-over that is a habit | Development time is being conflated with waiting time | Make a distinction between build effort and the time for approval or handoff |
| Attendance at late meetings | Work-life balance could be on the decline | Shift routine updates to an async channel and rotate the times of your meetings |
| Deployment confusion | No one is taking charge of the handoff or rollback | A release checklist with time stamps and named contacts will help |
If the project calls for web standards or accessibility, make sure requirements are out in the open and the W3C web standards can be referenced. Having clear standards puts an end to debates that would otherwise run on for days.
Protect People From Burnout
It is tempting to think an approach is efficient when you do not ask your people to put in unreasonable hours for months on end, but it is the most cost effective time-zone strategy in the long run. In time it will lead to mistakes that could have been avoided, fatigue and staff leaving.
The guidance from Safe Work Australia on fatigue as a hazard in the workplace applies to distributed software teams too. One does not want a tired individual to make a bad call on a release or to overlook a defect.
Share The Awkward Hours
Where live meetings are unavoidable after hours, have a rotating schedule. Do not put a late call on the calendar right before an early shift and let people know in advance. Make them infrequent. Should one person be made the permanent link between regions, you have engineered a single point of human failure for the project.
Take into account personal and cultural differences as well. Whether it is a public holiday or a matter of religion or family, availability will be impacted. Have practical constraints noted in the project calendar; there is no need for anyone to put private details on the table to justify them.
Compare Local And Global Options
Decisions on local versus global development in Australia should be dictated by the demands of the work, the risk and what collaboration is needed. An offshore model might give extended delivery coverage or a deeper talent pool, but local development means more office hours in common and quicker decisions in person.
One is not inherently superior to the other. A product that is pressing for constant input may do better with a narrow time difference. For a maintenance programme that is well documented several zones are no problem. It comes down to the uncertainty in the project.
Expectation Versus Reality
The expectation is an offshore team will of itself produce a 24-hour cycle. The reality is you need complete handoffs, dependable environments and prepared work to keep things moving; what you get is a 24-hour queue.
You might think more meetings will put right any misunderstanding. More often than not a well written requirement or decision record will head off the confusion that extra calls cannot. Save the meeting for when there is conflict or a decision to be made; they are a costly way to make up for a sentence left unsaid.
And the assumption is a lower rate per hour translates to a lower overall cost. Then there is the reality of it: a good deal on paper can be whittled away by rework and sprint delays, by approvals that are rushed and time spent waiting. Put in the numbers for the full cost of delivery, not to mention project management, testing, coordination, tooling, travel and what it takes for Australian staff to unblock work.
A Practical Decision Checklist
One should make sure an offshore web development team is up to the pressure before making an appointment. The sales call will be polished enough; put the arrangement to the test with a deployment deadline, a bug that turns up late or a member of the team calling in sick.
- Is there a core overlap in the day that is fair? Have you made note of all the locations and daylight-saving changes as well as their UTC offsets? For each ticket is there an owner to answer for it?
- Are the SLAs for an urgent matter distinct from routine ones? Do you measure your code reviews and approvals, as well as bug fixes?
- Will the team get by for a day without convening?
- Are the contacts for escalation, the rollback procedure and handoffs at deployment on record?
- And does the way meetings are scheduled allow for some work-life balance?
If one has to say no more than once or twice, the operating model needs mending before the team is scaled. Adding developers will not put right an absent decision path, they will only have more people standing around it.
Offshore Time Zones: Frequently Asked Questions
Is it a bad idea to go offshore on account of time zones?
Not at all. They do impose a cost in terms of coordination, but with good documentation and dependable handoffs and a core window of overlap, those can be kept in check. It is a model best suited to a project with the planning discipline to see work done while another team is offline and ownership is clear.
What is the right amount of overlap?
You will not find a figure that applies to all. A well documented project may be served by two hours of concentration, a complicated product launch might require more. Err on the side of the minimum needed to make decisions and after a delivery cycle is in the books have a look at any carry-over from the sprint, blocked-ticket age and meeting fatigue.
Must everyone be in every meeting?
There is no need. Put those who have to make the decision or can offer some specialist input on the invite list. An agenda in writing before the fact and an outcome recorded after is sufficient. Let an async channel take the routine status update, do not have half the team put their sleep out of order for a meeting.
Daylight-saving confusion for an Australian team?
Calendars and project documents should refer to named locations and UTC offsets. When daylight saving comes and goes in any of the locations involved, the schedule should be reviewed. “EST” and the like are not to be relied upon as the abbreviations are not consistent.
The best tool for the job?
There is none. Jira or Trello for status and ownership, GitHub for the code review, Slack, Zoom or Microsoft Teams if live coordination is called for. What matters is knowing where an update is to be put and how expeditiously a response is required.
Let the clock work for you
In offshore web development the time zone issue is not so much of an inconvenience if the team has planned for the absence. Be specific about handoffs, measure the waiting, document the decisions and keep a fair overlap window.
An arrangement is to be judged by whether it allows sound decisions to be made and work to be put to bed and the laptop shut at night, the whole project not in tow. Not by how many meetings there are or the extent of the time difference.
