Follow-the-Sun Development: How Hamburg + Ho Chi Minh City = Round-the-Clock Engineering

A sprint does not have to pause when your European team ends its day. Follow-the-sun development extends productive engineering hours across time zones, compressing delivery cycles without asking anyone to work outside normal business hours. For companies that need to ship faster without scaling headcount, it is one of the most underused models in distributed software development.

The challenge is that most teams who claim to run it do not. This is what the model actually requires, and how Gradion runs it between Hamburg and Ho Chi Minh City.

What is follow-the-sun software development?

Follow-the-sun (FTS) is, in the words of Carmel, Espinosa, and Dubinsky, researchers whose work established the academic foundation for this model, a type of global knowledge workflow designed to reduce time to market. Work is handed off between geographically distributed teams as each site ends its day. The incoming team picks up directly. Development continues.

With two sites, this extends productive hours to 16 per day. With three sites, to 24. IBM pioneered the approach in the mid-1990s. Their first attempt failed, not because the idea was wrong, but because daily handoffs were not consistently executed.

That is the insight most descriptions miss. Follow-the-sun is not a timezone arrangement. It is a discipline. The timezone is the precondition. The discipline is what delivers.

Why Hamburg and Ho Chi Minh City?

Hamburg operates on CET (UTC+1) in winter and CEST (UTC+2) in summer. Ho Chi Minh City operates on ICT (UTC+7) year-round. The offset is 5 hours in summer and 6 hours in winter.

Gradion also operates an engineering hub in Cairo. Egypt runs on EET (UTC+2) year-round, daylight saving time was abolished in 2011. This places Cairo in the same timezone band as Hamburg: identical in summer, one hour ahead in winter.

In FTS terms, Hamburg and Cairo together form one western anchor, not two independent relay points. They share the European and MENA morning window, deepen the combined engineering capacity on the western side, and extend Gradion's market coverage into the MENA region. Work transfers east to HCMC as Europe and MENA close, and returns to the western team the following morning.

This creates a natural overlap window. Hamburg and Cairo start at 09:00 local time. HCMC is at 14:00 ICT, mid-afternoon, in full production. A structured sync from 09:00 to 11:00 CET gives both sides shared context. The western teams then hand off. HCMC carries the work into its evening.

By the time HCMC closes at 18:00 ICT, Hamburg is at 12:00-13:00 CET the following day. Completed work is waiting. The review begins. The cycle continues.

Sixteen productive engineering hours. No one works outside normal hours. No heroics required.

This is also where the Gradion footprint reflects something deeper than timezone arithmetic. Hamburg brings German engineering rigour, structured architecture decisions, disciplined documentation, precise handoff standards. Cairo adds MENA market proximity and engineering depth to the western anchor. HCMC brings delivery speed, high-volume output, fast iteration, a senior engineering team built to move. Together, they do not just cover more hours. They cover more ground.

What makes it work in practice?

Kroll et al. (2013) reviewed 36 best practices across follow-the-sun implementations. Their finding: handoff quality is the single most critical factor. Poor context transfer is where FTS breaks down, not timezone gaps or cultural differences.

In practice, a functioning FTS workflow requires four things:

Structured handoff documentation. Every task transferred between sites must carry its current state, open blockers, decisions made, and the next required action. A verbal handoff across time zones is not a handoff. It is an assumption that will cost hours.
Fixed overlap hours. The overlap window is not for catching up. It is for alignment. Resolving blockers. Confirming priorities. Closing ambiguity before the receiving team works without support. At Gradion, this window is fixed, not flexible.
Async-first communication. Outside the overlap window, both teams operate asynchronously. Decisions cannot wait for a live conversation. Documentation, async PR review, and written architectural decisions are not overhead. They are the operating system.
Continuous delivery infrastructure. Automated pipelines, shared environments, and test coverage are non-negotiable. A build only the Hamburg team knows how to run is a six-hour delay every time HCMC needs it.

What follow-the-sun is not:

FTS is frequently claimed and rarely practised. Treinen and Miller-Frost (2006), in an IBM Systems Journal case study, documented both successful and failed FTS implementations. The most common failure: teams working in parallel rather than in sequence. Both sites were active. Neither was building on the other's output. The result was duplication, merge conflicts, and coordination overhead that erased the timezone advantage entirely.

A vendor who describes their model as follow-the-sun but cannot describe their handoff process is not running FTS. They are running a distributed team with more polished positioning.

The distinction produces different outcomes. Parallel distributed development scales capacity. Follow-the-sun development scales speed. One adds engineers. The other compresses the calendar.

The Gradion model in practice

Gradion's setup was designed around FTS principles from the start, not retrofitted onto an existing structure.

The Hamburg team anchors client relationships, architecture decisions, and sprint ownership. Cairo strengthens the western anchor, extending engineering depth and MENA market coverage within the same timezone band. HCMC carries the primary engineering volume as a full delivery partner, not a resource pool.

Handoffs are documented in writing. Overlap windows are protected. Async communication is the default, not the fallback.

For clients, this means a blocker resolved at 17:00 CET does not wait until 09:00 the following morning. It is picked up that evening in HCMC. The output is ready when Hamburg and Cairo open.

Across a sprint, across a quarter, that compression is measurable. It is also why the model requires governance, not just geography, to de-risk delivery at scale.

What to ask a follow-the-sun vendor

If you are evaluating whether a vendor genuinely operates on an FTS basis, ask three questions:

1. How do you document and transfer work between sites at end of day? What does the handoff artefact look like?
2. What is your fixed overlap window and who is required to be present?
3. How do you handle a blocker that appears after the handoff?

A vendor who answers all three with specifics is running the model. A vendor who describes their timezone spread without describing their handoff process is not.

Follow-the-sun development is an operating model decision. The geography makes it possible. The discipline makes it work.

Sources

Carmel, Espinosa & Dubinsky (2010), Follow-the-Sun Software Development, Journal of Management Information Systems
Treinen & Miller-Frost (2006), IBM Systems Journal, successful and failed FTS case studies
Kroll et al. (2013), systematic literature review, 36 FTS best practices identified
Wikipedia, Follow-the-sun (citing Carmel, Dubinsky & Espinosa, 2009, Hawaii International Conference on System Sciences)
Timezone offsets: CET UTC+1, CEST UTC+2, EET UTC+2 year-round (Egypt abolished DST 2011), ICT UTC+7