Working with engineers in another time zone

Tascbar is in Kerala, in the south of India, and many of the founders and businesses we work with are somewhere else. A lot of our projects run across a time difference, so we’ve had to get good at it. This is how we run those projects, and what to ask any engineering team before you start one with them.

The time difference is mostly a scheduling problem

India Standard Time is four and a half to five and a half hours ahead of the UK, depending on the time of year, nine and a half to ten and a half hours ahead of the US east coast and an hour and a half ahead of the Gulf. A client in London starts their morning as we reach mid-afternoon. A client in New York wakes up to a day of our work already done.

The gap is useful when the work needs nothing from you and awkward when it does, so it pays to be honest about which is which. Writing code, fixing bugs and building the next screen need no overlap at all. Deciding what the next screen should do needs you in the room, or something written down that can stand in for you.

Agree the overlap before the project starts

Pick a window of two or three hours that works on both sides and treat it as the project’s working day for anything that needs a decision. Calls, demos and anything with a yes or no in it go in that window. Everything else goes in writing.

Agree at the same time how quickly messages get answered outside the window and who to contact when something can’t wait. An urgent message answered in nine hours is usually fine if everyone knew that was the arrangement. The same nine hours feel very different when nobody said.

One engineer answers for the project

Every Tascbar project has a lead engineer who is accountable for it from the first conversation to the production release. You talk to them directly, and they’re the person who knows the code. That’s what Forward Deployed Engineering means in practice.

Across a time difference this matters more than it does in the same office. A question that arrives at the end of your day is read the next morning by someone who can answer it from what they know and then act on it. There’s no round trip through a coordinator, which across nine hours can turn a small question into a two-day delay.

When the work needs skills your lead engineer doesn’t have, such as design, mobile development or infrastructure, they bring in the right people from our network and coordinate them. You still have one point of contact.

Decisions in writing, software every week

Two habits keep a remote project honest.

The first is writing decisions down. Memory is unreliable across a time gap, and a decision made on a call in your morning is acted on in our afternoon, sometimes by someone who wasn’t on the call. Ask for every decision in writing, with the reasoning, so the person picking it up can act without another meeting. Where there are trade-offs, we explain them in plain language so you can make the call, and that explanation is what goes in the record.

The second is working software. It’s the only progress report that can’t be spun. We build in short sprints, so you see something you can use every week, and you can test features as they land, give feedback and change priorities without derailing the project. A demo at the end of each week tells you more than any status update.

Expect to be told no

A good team asks questions, raises concerns and tells you when something won’t work. At a distance that’s easy to lose, because typing “sure” is easier than starting a hard conversation across time zones. When you’re choosing a partner, notice whether they push back on anything in the first calls. If they agree with everything, you’ll find out what they really thought six weeks in.

Start with a small first phase

You don’t need to commit to a whole roadmap on day one. A small, clearly defined first phase shows you how the team communicates, how they handle feedback and the quality of what they deliver, before much money is at stake.

Our projects start with an Understand stage and a Define stage, which end in a proposal with the plan, a timeline, a cost estimate and the engineer who will lead the work. Nothing gets built until you’ve seen that. If the first phase goes well, the next one is a bigger bet on a team you already know.

Questions to ask before you sign

• Who will I talk to day to day, and do they write the code?
• Which hours overlap with mine, and what happens outside them?
• How will I see progress? Ask to see working software each week.
• Where do decisions get recorded?
• What’s the smallest first phase we could start with?
• Who else will work on this, and who coordinates them?

If the answers are clear, the time difference stops being the thing to worry about. What’s left is the same as any project: a problem worth solving, a scope that fits the budget and a team that owns getting it to production. You can read how we take a project from problem to production, or tell us what you’re building.