← All writing
Leadership · 9 min read

You do not have a timezone problem

A one-line fix used to take three days.

QA in Colombo finds it late afternoon and writes it up. Engineering in Yerevan picks it up the next morning, fixes it in about 40 minutes, and pushes it. Colombo verifies the following day. Product in Bengaluru accepts it. It goes out with the release I approve from Luxembourg.

Three days on the calendar. Under an hour of work. Nobody was slow, nobody was disengaged, and every single person in that chain did their job promptly.

For a long time I filed this under the cost of a distributed team. Then I did something I should have done years earlier: I worked out how many hours we were actually losing to the planet.

The arithmetic that ended the excuse

Our engineering runs across Luxembourg, Armenia, India and Sri Lanka. The wider business adds Poland, South Africa and Pakistan.

That sounds like it should be brutal. It is not.

Luxembourg, Poland and South Africa all sit at the same offset for most of the year. Armenia is 2 hours ahead of Luxembourg. Pakistan is 3. India and Sri Lanka are 3.5 hours ahead. In the depth of January, when European clocks fall back, the widest gap in the entire company reaches 4 and a half hours.

Take the worst pair, me in Luxembourg and QA in Colombo. If both work a normal nine-hour day, we share 5 and a half hours of it. Yerevan and Colombo share 7 and a half. Luxembourg and Yerevan share 7.

The worst-matched two people in my organization overlap for more than half of every working day.

So when a one-line fix takes three days, the sun is responsible for at most a few hours of that. The other 68 are mine. That was an unpleasant afternoon.

I think a very large number of companies are in this position and have never checked. "We are distributed across six countries" becomes an explanation for slowness, and it goes unchallenged because it sounds obviously true. Go and calculate your actual overlap before you accept it. Unless you genuinely span Europe and the American west coast, or Europe and East Asia, the clock is not your problem. Something else is wearing its costume.

What is actually taking the three days

Once the timezone excuse is gone, the real cause is visible, and it is embarrassing, because it is a decision I made.

We hired by function and by country at the same time. Engineering here because good engineers were available. QA there because a strong team existed. Product somewhere else because that is where we found the right person.

Every one of those decisions was sensible on its own. Together they produced an organization where the boundaries of the org chart and the boundaries of the map are the same lines. And since work has to cross a function boundary several times before it is done, every crossing is also a geographic crossing, and each one gets rounded up to the next working day.

Conway's law says your systems end up shaped like your communication structure. The version nobody warned me about is that when your communication structure is sliced by function and distributed by geography, your delivery process becomes a serial chain with a sunrise between each link. The work is fast. The sequence is slow.

So I stopped counting days and started counting sunrises. How many times does the sun have to come up before this change is live? That question is more useful than any velocity metric I have ever used, because everyone in the chain can see their own contribution to it, and nobody can blame the clock.

That fix was three sunrises for 40 minutes of work.

Follow the sun is not the answer

The standard prescription is to embrace it. Hand work westward at the end of each day and let it move around the globe continuously.

I have tried this. It works for a support rota, and it fails for engineering, for a reason that took me too long to see: handing over work costs more than the work. Explaining a half-finished change to someone who has not been living inside the problem takes longer than finishing it. And ownership dissolves. When three people touched something across three days, nobody feels responsible for it, and quality follows exactly where you would expect.

Follow the sun optimizes for machine utilization in an organization made of people. It is an idea from manufacturing that never should have crossed over.

Closed loops instead

What worked was the opposite. Instead of moving work between locations, stop the work from needing to move.

Every location gets a complete loop: enough of every function to take a problem from raw to verified and shipped without waking anyone up. That means a cluster with engineers has to have someone who can test and someone who can decide. Not a full copy of the company, a full copy of the path.

This changes hiring in a way that feels wrong at first and is right. When you need a QA engineer, do not hire in the country where QA engineers are cheapest. Hire in the country where the engineers who will need that QA already are. You are not buying a skill; you are buying a shortened loop, and the loop is worth more than the rate difference. I have paid a premium of maybe 15% to remove a sunrise and considered it the best money I spent that year.

It also changes architecture, and this is where CTOs should pay attention. If your clusters own services they can deploy independently, closed loops are achievable. If everything ships as one artifact with one release train, no amount of org design saves you, because the release itself is a global handoff. Distributed teams and a distributed monolith are a genuinely painful combination, and most companies try to fix it with process when the fix is in the deployment boundary.

The night is no longer empty

Here is the part that is new, and that I could not have written 18 months ago.

The old constraint was that when a cluster went home, its context went home too. That is no longer entirely true, because a good chunk of our work now runs through an agentic harness where the intent behind a piece of work is written down as a matter of course.

So the handoff has changed shape. QA in Colombo does not file a ticket that sits waiting for Yerevan. They file a reproduction, and overnight the harness turns that into a failing test and a draft fix with the reasoning attached. Yerevan opens their laptop to a reviewable pull request rather than a description of a problem.

Three sunrises became one. Not because anyone works longer, and specifically not because anyone takes calls at 23:00, but because the expensive part of a handoff was never the transport. It was the reconstruction of context at the other end, and that is now largely done before anyone arrives.

This is the first genuinely new thing to happen to distributed engineering in a decade, and I notice almost nobody is talking about it. Follow the sun failed because humans cannot cheaply transfer context. Agents can hold it overnight and hand it over in a form that survives. The night shift is not a person in another country. It is preparation.

The prerequisite is unglamorous. It only works if intent is captured in writing at the moment work is specified. Teams that keep the reasoning in people's heads get nothing from this, because there is nothing to carry.

You cannot have one culture

Now the human half, and this is where I disagree with almost every piece of advice on the subject.

The standard goal is one strong shared culture across every location. I think that is unachievable across Armenia, India, Sri Lanka, Poland, South Africa, Pakistan and Luxembourg, and the attempt does damage. What you actually get is a slow flattening toward whichever culture holds the budget, which usually means mine, and the moment that happens, your other locations start performing agreement rather than giving you their judgment.

What does travel is protocol. A thin layer of agreements about how work is conducted, deliberately small: what "done" means, where a decision gets recorded, how you register disagreement, what a reasonable response time is, and which meetings genuinely need to be live.

Protocol scales across cultures because it does not ask anyone to change who they are. It asks everyone to write things down in the same place. Culture does not scale, and pretending otherwise mostly produces posters.

Your risk register is geographically biased

This is the most important thing in this post and the least comfortable.

In some cultures, telling a senior person directly that their deadline is impossible carries a real cost. In others it is expected. That variation is normal, and it is not a defect. But it means the bad news reaching you is filtered differently depending on where it starts, which means your view of risk is not just incomplete, it is skewed in a predictable direction. You will consistently hear more concern from some locations than from others, and it will have nothing to do with where the actual risk sits.

Telling people to speak up does not fix this. It relocates the problem onto the person with the least power in the conversation.

What worked was structural. Stop asking "any blockers?" on a group call, because the silence means different things in different rooms and you will read all of it as agreement. Ask for a number instead: how confident are you that this lands on the 14th, from 1 to 10. A 6 is easy to say when "no" is not. Ask in writing and asynchronously, where the power gradient is weaker than on video. Ask the most junior person first, because once the senior person has spoken, the room is closed in several of our locations. And wherever possible, let the system report status instead of a person, because a dashboard has no relationship to protect.

One more that cost me a year to learn: seniority titles do not translate between markets. A "senior engineer" means different things in different hiring markets, and if you calibrate on titles you will build teams that look balanced on the org chart and are not. Calibrate on work.

What to do on Monday

Two things, and the first takes ten minutes.

Work out the real overlap between your least-overlapping pair of people. Actual hours, not impressions. If it is more than 4, you do not have a timezone problem, and you should stop letting anyone say you do.

Then take one piece of work that shipped last week and count the sunrises. Every one you find is a handoff crossing a boundary, and each of those is either a missing function in a cluster, a missing artifact, or a decision that needed permission from someone asleep. Those are three fixable things, and none of them is the rotation of the earth.

If you want help redesigning the loops rather than the calendar, that is the work I do.

Ruud
CTO · AI transformation
Work with me →
Operating Notes
What I am learning, as I learn it.

I write this myself, fortnightly. Unsubscribe anytime.