I have spent a large part of my career building and running a fully remote software consultancy. Before that, as a partner, I helped grow a software consulting company from about $6M to $60M in under three years. In both settings, the question I heard most from clients and new managers was the same: how do you keep engineers productive when they are spread across time zones and rarely online at the same moment?
My honest answer is that time zones are rarely the real problem. They expose problems that already exist. A team with fuzzy ownership, undocumented decisions and a habit of solving everything in meetings will struggle in one office. Spread that team across continents and the cracks become canyons.
Here is the practical system I rely on.
Start With Overlap, Not Coverage
Many leaders try to fix time zones by asking people to stretch their days. That works for about a month. Then your best engineers start interviewing elsewhere.
Instead, I define a small, protected overlap window for each team, usually two to three hours where most members are online. That window is for the things that genuinely need real-time conversation: unblocking, pairing on a hard problem, a short standup if the team wants one, and quick decisions.
Everything else moves outside the window. Deep work, code review, documentation and planning happen asynchronously. When people know exactly which hours are collaborative, they stop feeling like they need to be available all the time.
If a team has almost no natural overlap, I treat that as a staffing design question, not a scheduling one. Either the work gets split so each region owns a clear slice, or the team composition changes.
Make Ownership Impossible to Misread
In a co-located team, ambiguity gets resolved in the hallway. In a distributed team, ambiguity sits overnight and costs you a full day.
Every piece of work needs one named owner. Not a group, not "the backend team," one person. That owner is responsible for moving it forward, raising blockers early and writing down what changed. Others can contribute, but everyone knows whose name is on it.
I also ask teams to own outcomes by area rather than by ticket where possible. An engineer who owns the payments service end to end will make better decisions at 11 p.m. their time than someone who picked up a random ticket and has to wait for context.
Write the Handoff Like Someone Else Will Finish It
The handoff is where distributed teams win or lose. When one engineer signs off and another picks up hours later, the quality of that note decides whether the next person starts working or starts asking questions.
A good handoff answers four things:
- What I did today and where it stands.
- What is blocked and who can unblock it.
- What decision I need, and by when.
- Where the relevant code, branch, or document lives.
That takes five minutes to write and saves hours on the other side of the world. I wrote about the broader principle in "The Three-Times Rule: Why Every Remote Company Needs a Written Playbook." If a question comes up three times, it belongs in writing. Handoffs are the daily version of that habit.
Replace Status Meetings With Visible Work
Status meetings are expensive in any company. Across time zones they are worse, because someone is always joining at a bad hour.
I push teams to make work visible by default. Pull requests with clear descriptions. A project board that is actually current. A short written update at the end of each person's day in a shared channel. When status is always available, the meetings you keep can focus on decisions and problems instead of recitations.
A useful test: if a manager cannot tell how a project is going without scheduling a call, the system is not working yet.
Set Response-Time Expectations Explicitly
Async only works if people trust that messages will be answered. Without explicit norms, one person expects a reply in ten minutes and another thinks the next day is fine. Both feel let down.
I like to agree on simple tiers. Something like: urgent production issues go through a defined on-call path, not chat. Blocking questions get an answer within the owner's same working day. Everything else within one business day. The exact numbers matter less than the fact that everyone agreed to them and they are written down.
This also protects people. When the expectation is clear, nobody feels pressure to watch chat all evening.
Review Code for Momentum
Code review can quietly become the biggest source of delay on a distributed team. A pull request opened at the end of one person's day can sit for a full cycle if no one in the next time zone is responsible for it.
A few habits help a lot:
- Keep pull requests small enough to review in one sitting.
- Assign reviewers in time zones that will be online next, when possible.
- Write the description for a reader who has no context.
- Agree on what "good enough to merge" means, so reviews don't turn into open-ended debates.
The goal is momentum. Each handoff of code should move it closer to production, not back into a queue.
Hire for Written Communication
When I evaluate engineers for remote teams, technical skill is the baseline, not the differentiator. The differentiator is how clearly someone writes and how reliably they follow through without supervision.
I look at how candidates explain their own work in writing, how they handle an ambiguous task, and whether they ask good clarifying questions. An excellent engineer who cannot communicate asynchronously will slow down an entire distributed team. A strong engineer who writes clearly will make everyone around them faster.
Protect the People, Not Just the Process
All of this structure exists for one reason: so people can do their best work without sacrificing their evenings. Rotate any inconvenient meeting times so the same region doesn't always absorb them. Watch for engineers who are quietly working across two time zones to compensate for a broken handoff. Make it normal to log off.
High-performing remote teams are not the ones that are always online. They are the ones where the system is clear enough that nobody has to be.
The Short Version
If you take one thing from this, make it this: treat time zones as a design constraint, not an obstacle to fight. Protect a small overlap window, give every piece of work one owner, write handoffs someone else can finish, make work visible, agree on response times, keep reviews moving, and hire people who write well. Do that consistently and distance stops being the story.
If you're building or scaling a distributed engineering team and want to compare notes, you can find me and my work at TDZ Pro, https://tdzpro.com.
Ashkan Rajaee is the founder of TDZ Pro. As a partner, he helped grow a software consulting company from about $6M to $60M in under three years, and he founded and scaled a fully remote software consultancy.
Top comments (0)