In 2022, when we opened our development centre in Hyderabad to complement our headquarters in Zug, we thought the hardest part would be the technical infrastructure: secure VPNs, shared repositories, CI/CD pipelines spanning two continents. We were wrong. The hardest part was building a culture where a developer in Hyderabad felt as empowered to push back on a design decision as someone sitting three metres from the CTO in Zug.
Four years later, our Swiss-Indian model is the backbone of our delivery capability. But the path here was not straight, and the lessons we learned apply to any organisation trying to build genuinely distributed teams rather than merely offshoring work to a cheaper location.
Distributed vs. Offshored: The Distinction That Matters
Most companies that claim to have "distributed teams" actually have a headquarters that makes decisions and a remote office that executes them. The remote team becomes an order-taker. This model is fragile for three reasons:
- Knowledge concentrates at HQ. When the decision-makers and the implementers are separated, context gets lost in translation. Requirements become more prescriptive to compensate, leaving less room for the remote team to apply their own expertise.
- Career paths diverge. If the most interesting architectural work happens at HQ, the best engineers in the remote office will eventually leave for a company that offers them those challenges locally.
- Resilience drops. When one office cannot function without the other's daily input, you have not created distribution. You have created a dependency chain with a nine-hour timezone delay.
A truly distributed team is one where each location can own outcomes, not just tasks. That was our design goal from day one, even though reaching it took longer than we anticipated.
The Four Pillars of Our Model
1. Shared Ownership, Not Shared Tickets
We do not assign features to individuals and track them through a JIRA board. Instead, we assign domains to cross-location pairs. For example, our payment integration domain is co-owned by a senior engineer in Zug and a senior engineer in Hyderabad. Both have equal authority to make design decisions, and both are accountable for the domain's health.
This pairing ensures that knowledge exists in both locations. If one person is unavailable, on holiday, or leaves the company, the domain does not lose its institutional memory. It also forces real collaboration: you cannot co-own something without having substantive technical conversations.
2. Overlap Hours Are Sacred
Zug and Hyderabad are separated by 3.5 to 4.5 hours depending on daylight saving. This gives us a generous overlap window of roughly 10:00-14:00 CET, during which both offices are fully staffed. We guard this window fiercely.
During overlap hours, we run all synchronous activities: architecture discussions, sprint planning, cross-domain syncs, and pair programming sessions. Outside overlap hours, each office works autonomously on their domains, leaving clear asynchronous handoff notes in our internal documentation system.
"The quality of your asynchronous communication determines the quality of your distributed team. If handoff notes are vague, the next morning starts with confusion instead of momentum."
3. Invest in Physical Presence
We fly engineers between Zug and Hyderabad regularly. Not just managers, not just for kick-offs, but working engineers doing regular sprint work in the other office. A developer who has shared lunch in the Hyderabad canteen and walked through the Zug Altstadt with their counterpart communicates differently over video call. The investment in travel pays for itself many times over in reduced friction and increased trust.
We budget for each engineer to spend at least two weeks per year in the other office. New hires spend their first month co-located with their cross-office pair. This is non-negotiable. It is also one of our strongest hiring advantages: engineers want to work for a company that invests in real human connection.
4. Unified Engineering Standards
Nothing fractures a distributed team faster than the perception that one office produces "better" work than the other. We eliminate this by enforcing a single, rigorous engineering standard across both locations:
- Code review is cross-location by default. A pull request from Hyderabad is reviewed by someone in Zug, and vice versa.
- The same CI/CD pipeline, the same linting rules, the same test coverage thresholds apply everywhere.
- Architecture Decision Records (ADRs) are written collaboratively and require sign-off from both locations.
- Incident post-mortems are attended by both offices, regardless of which team's code was involved.
The goal is not uniformity for its own sake. It is ensuring that every engineer, regardless of location, operates within the same quality framework and is held to the same standard.
What We Got Wrong
Honesty about failures is as important as sharing successes. Here are three things we had to course-correct.
We initially over-documented. Trying to compensate for distance, we created exhaustive specification documents that left no room for interpretation. Engineers in Hyderabad felt they were being treated as implementers rather than thinkers. We scaled back to lean specs that describe the "what" and "why" but leave the "how" to the owning team.
We underestimated cultural communication styles. Swiss directness can read as blunt in Indian professional culture, while Indian indirectness can read as evasion in Swiss culture. Neither interpretation is correct. We invested in cross-cultural communication workshops, not the generic corporate kind, but practical sessions focused on how disagreement, escalation, and feedback work differently across our specific cultural contexts.
We hired too many juniors in Hyderabad initially. Trying to scale quickly, we brought on a cohort of talented but inexperienced engineers. Without enough senior mentorship locally, they struggled to make autonomous decisions. We restructured to maintain a minimum senior-to-junior ratio of 1:3 in each location.
Measuring Team Health Across Borders
Traditional metrics like velocity and throughput tell you how fast a team is moving but not how healthy the collaboration is. We track several additional signals:
- Cross-location PR ratio: What percentage of pull requests are reviewed by someone in the other office? A declining ratio suggests the offices are siloing.
- Decision distribution: Who is authoring ADRs? If most architectural decisions originate from one office, ownership is not truly shared.
- Voluntary attrition delta: If one office has significantly higher turnover, something about the working relationship is not right.
- Meeting sentiment surveys: Brief monthly polls that ask whether overlap-hour meetings feel collaborative or directive.
The Compounding Returns
Building a genuinely distributed team is hard and slow. The payoff, however, compounds over time. Today, our Hyderabad office does not just implement Swiss-designed software. It contributes original architectural innovations, leads client discovery sessions, and mentors junior engineers in both locations. The flow of expertise is bidirectional, exactly as it should be.
For clients, this means resilience. A project staffed across two offices and two time zones can absorb disruptions, whether a local holiday, an illness, or a sudden change in scope, without missing a beat. It also means extended coverage: our effective working day spans from early morning in India to late afternoon in Switzerland, giving clients near-continuous progress.
Distributed is not a cost play. Done right, it is a capability multiplier.
Looking to build or scale a distributed engineering team? We have learned these lessons so you do not have to. Talk to us about how our model can work for your organisation.