Follow the Sun: the handoff strategy behind Baldur's Gate 3's global development
August 2023. Baldur’s Gate 3 ships in full after three years of Early Access. 96/100 on Metacritic. GOTY at the Game Awards. In the credits: roughly 500 people, seven studios, three continents. The question I keep coming back to: how do you keep a single product coherent when the people building it never work at the same time — and don’t share the same culture or references?
The Follow the Sun model has the reputation of a good idea that breaks down in production. Coordination drifts, handoffs carry incomplete context, timezone silos replace geographic ones. Larian Studios turned it into a strategic advantage, shipping a game of unprecedented narrative and technical complexity. How? By treating Follow the Sun not as an organizational problem, but as a collaboration infrastructure. That’s what this article breaks down.
TL;DR — Follow the Sun doesn’t work simply because you spread teams across timezones. It works when the technical pipeline is solid, the vision is clear, and collaboration is genuine. Larian applied it successfully on Divinity: Original Sin 2, then at larger scale on BG3. Several lessons transfer directly.
Navigation: What FTS promises · Larian’s mechanics · What held · DevEx angle · Field lessons · FAQ
What does Follow the Sun actually promise?
The premise is straightforward: teams spread across timezones hand work off like a relay. One geography finishes its day and passes the baton; another picks up where the first left off. In theory, this enables near-continuous production: less idle time, QA running while the other team sleeps, faster iteration cycles.
In practice, most attempts fail at the same point: they optimize hours, not knowledge flow. The timezone relay only works if the team picking up knows exactly where things stand, what was decided, and why. Without that, timezones become silos with added lag.
The classic failure: you open an office on the other side of the world, define relay windows, then wonder after the fact why handoffs are inefficient. The real work happens upstream: standardizing pipelines, clarifying ownership, documenting decisions, building shared vision and culture. That’s where Larian pulled off something genuinely difficult.
Six studios, three continents: the concrete mechanics
Larian had been thinking distributed long before BG3, but the game’s development accelerated their growth faster than expected. When announcing new studio openings, the studio made its strategy explicit: “Creating Baldur’s Gate 3 is a huge undertaking and we are growing the team to help us follow the sun.” Not a growth metaphor; a stated architectural decision.
The current footprint covers the three useful timezone bands:
- Europe: Ghent (HQ), Dublin, Barcelona, Guildford, Warsaw; UTC+1 to UTC+2
- North America: Québec City; UTC-5 to UTC-4
- Asia: Kuala Lumpur; UTC+8
13-hour spread between Québec and KL — on the left, Ghent and Dublin open the day that runs through Barcelona to Warsaw; on the right, KL hands off to Europe every morning.
This isn’t a “pure” Follow the Sun with three perfectly spaced relays. The European studios share nearly identical timezones. The real amplitude comes from KL, 6 to 7 hours ahead of Europe, and Québec, 5 to 6 hours behind. In practice, that creates two main relay windows: Europe to the Americas in late afternoon, and Asia to Europe in the morning. This is a distributed model with partial overlaps; it’s also the most common setup in enterprise, and the most realistic to implement.
Making that mechanics work required massive pipeline investment. Tools officially mentioned in Larian’s GDC talks include Flow Production Tracking (formerly ShotGrid) for production tracking, Jira for tickets, supplemented by internal bridges and pipelines. The result: assets, tickets, builds, and validation states are accessible and transferable without friction across all studios. A ticket opened in the morning in Ghent can be processed, tested, and merged in Québec before the next morning in Belgium.
What actually made the relay work?
The short answer: organizational structure had almost nothing to do with it.
Async-first culture. A Follow the Sun model that depends on real-time approvals is dead on arrival; timezones become an availability nightmare. Larian structured work around documentation, extremely detailed tickets, and clear ownership on every task. Each studio can move forward without waiting for another’s sign-off. This is exactly what GitLab documents in its remote culture: async isn’t a workaround for not being co-located; it’s an autonomous way of working.
Skills sharing as resilience. On BG3, discipline leads — technical and creative leads — rotated between studios. Not to control, but to transfer decision-making standards. A narrative lead in Dublin needed to be able to make the same call a lead in Ghent would have made. That’s not rigid standardization; it’s resilience: no single studio becomes the sole keeper of critical knowledge. In the enterprise teams that struggle most with distributed work, this geographic bus factor is usually what blocks them: one expert in one city, and nobody elsewhere can decide without them.
Shared vision as a decision filter. “Stay true to Dungeons & Dragons rules” sounds simple; it’s actually a universal filter. Faced with hundreds of daily decisions — combat mechanics, dialogue, narrative permutations — every team has a common reference frame. That replaces a staggering volume of micro-approvals. The enterprise IT equivalent exists: a clear product vision, documented architecture principles, a shared definition of “production-ready.” Teams that have them don’t wait; teams that don’t get blocked on decisions that should have been trivial.
Why FTS is as much a DevEx problem as an organizational one
This is probably the most directly transferable lesson. At Larian, the relay’s success depends on technical pipeline quality just as much as on human organization. A poorly versioned asset, a non-reproducible build, an incomplete ticket: and the studio picking up spends its first hours reconstructing context instead of shipping.
In enterprise IT, the same symptoms appear. The distributed teams that struggle most aren’t the ones with bad organizational design; they’re the ones with inconsistent source management across sites, development environments that diverge by office, CI/CD pipelines that don’t produce reproducible builds.
A tooling strategy built for scale isn’t a luxury in a distributed model: it’s an execution prerequisite. Dev Containers are a concrete example: the environment becomes a versioned, transferable, reproducible artifact for any studio.
Larian’s thesis in one line: the technical pipeline is a collaboration infrastructure, not an isolated engineering concern.
What enterprise IT can take from this without romanticizing game dev
BG3 isn’t a universal template. In an interview on the Silence on Joue podcast (in French), Swen Vincke described 17-hour days straddling multiple timezones to coordinate studios. The model reduces crunch for execution teams; it can concentrate it on those who orchestrate. Follow the Sun doesn’t eliminate delivery pressure: it redistributes it. It’s not a magic mechanism; it’s an amplifier: it amplifies what’s already working in an organization, and it amplifies what isn’t.
What the model delivers concretely, when the conditions are right:
- Near-continuous QA: when a feature is complete in Europe, a North American team can test it during the European night. On BG3, with its thousands of narrative permutations and save states, this became structural.
- Fewer dependency bottlenecks: inter-team blockers get resolved during the timezone gap rather than queuing up.
- Compounding knowledge: a problem solved in KL in the evening arrives documented in Ghent the next morning. Knowledge flows both ways through the relay.
The three minimum conditions for it to hold:
- Solid pipeline tooling: versioning, CI/CD, global ticketing, reproducible builds. Without this, the relay passes puzzles, not work.
- Unambiguous ownership: every task has a named owner. The relay passes the work, not the responsibility.
- Shared, documented vision: decisions must be made locally, without permanent escalation. That requires having taken the time to document principles, not just features.
One honest warning: this model requires permanent onboarding investment. Every new studio, every new team, must absorb pipeline standards and vision principles. That’s a debt paid upfront and at every scope change; it needs to be budgeted explicitly, not absorbed.
Related: An IDE strategy at enterprise scale · Dev Containers and environment reproducibility · Source management and developer experience
FAQ
Is Follow the Sun only for large organizations like Larian?
No. The principle applies as soon as an organization has teams in two meaningfully different timezones, even at small scale. A 20-person team split between London and Toronto can benefit from a partial relay: a 5-hour gap is enough for a ticket opened in the morning in the UK to be processed before the UK team picks up the next day. What changes at scale is the rigor required on tooling and documentation; the principles stay the same.
Why do most Follow the Sun attempts fail?
Because they treat it as an HR org problem, not a knowledge flow problem. Teams get distributed across timezones, relay windows get defined, and the inefficient handoffs are a surprise. The real work is upstream: standardizing pipelines, clarifying ownership, documenting decisions. Without those foundations, relay teams spend their first hours reconstructing context rather than producing.
What does “sharing the vision” actually mean operationally?
It’s not an internal communications exercise. It means having documented decision principles, accessible to everyone, that any team can apply without escalating. At Larian, “true to D&D” was that filter. In enterprise IT, the equivalent can be Architecture Decision Records, a Product Vision Document, or a precise definition of “production-ready.” The sign that vision is genuinely shared: a team on the other side of the world can resolve an unspecified edge case, and the result is consistent with what the rest of the organization would have chosen.
What’s the real cost of the distributed model?
The main cost is permanent onboarding and documentation maintenance. In a distributed model, documentation isn’t a post-production artifact: it’s active infrastructure. Every significant technical decision needs to be written to be transferable. That takes time, and that time must be budgeted explicitly. The second cost, often underestimated: tooling must be maintained at a higher reliability level than in a co-located team. A broken pipeline at 5pm in Ghent blocking Québec at 11am is half a day lost.