Resiliente verteilte Teams aufbauen: Lehren aus unserem Schweizer-Indischen Modell

Als wir 2022 unser Entwicklungszentrum in Hyderabad eröffneten, um den Hauptsitz in Zug zu ergänzen, dachten wir, das Schwierigste wäre die technische Infrastruktur: sichere VPNs, gemeinsame Repositories, CI/CD-Pipelines über zwei Kontinente. Wir lagen falsch. Das Schwierigste war der Aufbau einer Kultur, in der sich ein Entwickler in Hyderabad ebenso ermächtigt fühlt, eine Designentscheidung infrage zu stellen, wie jemand, der drei Meter vom CTO in Zug entfernt sitzt.

Vier Jahre später ist unser Schweizer-Indisches Modell das Rückgrat unserer Lieferfähigkeit. Der Weg dorthin war jedoch nicht geradlinig, und die Lehren, die wir gezogen haben, gelten für jede Organisation, die echte verteilte Teams aufbauen will – und nicht nur Arbeit an einen günstigeren Standort auslagern.

Verteilt vs. ausgelagert: Der entscheidende Unterschied

Die meisten Unternehmen, die von „verteilten Teams“ sprechen, haben in Wirklichkeit einen Hauptsitz, der entscheidet, und ein Remote-Büro, das ausführt. Das Remote-Team wird zum reinen Auftragsempfänger. Dieses Modell ist aus drei Gründen fragil:

• Wissen konzentriert sich am Hauptsitz. Wenn Entscheider und Umsetzer getrennt sind, geht Kontext bei der Übertragung verloren. Anforderungen werden immer detaillierter, um das zu kompensieren – und lassen dem Remote-Team weniger Raum, eigene Expertise einzubringen.
• Karrierewege divergieren. Wenn die interessanteste Architekturarbeit am Hauptsitz stattfindet, werden die besten Ingenieure im Remote-Büro früher oder später zu einem Unternehmen wechseln, das ihnen diese Herausforderungen vor Ort bietet.
• Resilienz sinkt. Wenn ein Standort ohne täglichen Input des anderen nicht funktionsfähig ist, haben Sie keine Verteilung geschaffen. Sie haben eine Abhängigkeitskette mit neun Stunden Zeitzonenverzögerung.

Ein wirklich verteiltes Team zeichnet sich dadurch aus, dass jeder Standort Ergebnisse verantworten kann, nicht nur Aufgaben. Das war von Anfang an unser Ziel – auch wenn die Umsetzung länger dauerte als erwartet.

Die vier Säulen unseres Modells

1. Gemeinsame Verantwortung, nicht gemeinsame Tickets

Wir weisen keine Features Einzelpersonen zu und verfolgen sie über ein JIRA-Board. Stattdessen weisen wir Domänen standortübergreifenden Tandems zu. So wird z. B. unsere Zahlungsintegrations-Domäne gemeinsam von einem Senior-Ingenieur in Zug und einem in Hyderabad verantwortet. Beide haben gleiche Befugnis für Designentscheidungen und sind gemeinsam für den Zustand der Domäne verantwortlich.

Dieses Tandem stellt sicher, dass Wissen an beiden Standorten existiert. Wenn eine Person nicht verfügbar ist, im Urlaub oder das Unternehmen verlässt, geht das Domänenwissen nicht verloren. Es erzwingt echte Zusammenarbeit: Man kann etwas nicht gemeinsam verantworten, ohne substanzielle technische Gespräche zu führen.

2. Überlappungszeiten sind unantastbar

Zug und Hyderabad liegen je nach Sommer-/Winterzeit 3,5 bis 4,5 Stunden auseinander. Das ergibt ein großzügiges Überlappungsfenster von etwa 10:00–14:00 Uhr MEZ, in dem beide Büros voll besetzt sind. Dieses Fenster schützen wir strikt.

Während der Überlappungszeiten laufen alle synchronen Aktivitäten: Architekturdiskussionen, Sprint-Planung, domänenübergreifende Abstimmungen und Pair-Programming-Sessions. Außerhalb dieser Zeiten arbeitet jeder Standort autonom an seinen Domänen und hinterlässt klare asynchrone Übergabenotizen in unserem internen Dokumentationssystem.

„Die Qualität Ihrer asynchronen Kommunikation bestimmt die Qualität Ihres verteilten Teams. Sind die Übergabenotizen vage, beginnt der nächste Morgen mit Verwirrung statt mit Schwung.“

3. In physische Präsenz investieren

Wir fliegen regelmäßig Ingenieure zwischen Zug und Hyderabad. Nicht nur Führungskräfte, nicht nur zu Kick-offs, sondern arbeitende Ingenieure, die reguläre Sprint-Arbeit im anderen Büro leisten. Ein Entwickler, der mit seinem Gegenüber in der Kantine in Hyderabad zu Mittag gegessen und die Zuger Altstadt durchlaufen hat, kommuniziert anders per Videocall. Die Investition in Reisen amortisiert sich mehrfach durch weniger Reibung und mehr Vertrauen.

Wir planen für jeden Ingenieur mindestens zwei Wochen pro Jahr im anderen Büro ein. Neue Mitarbeiter verbringen ihren ersten Monat gemeinsam mit ihrem standortübergreifenden Tandempartner. Das ist nicht verhandelbar. Es ist auch einer unserer stärksten Vorteile bei der Gewinnung von Talenten: Ingenieure wollen für ein Unternehmen arbeiten, das in echte zwischenmenschliche Beziehungen investiert.

4. Einheitliche Technikstandards

Nichts spaltet ein verteiltes Team schneller als der Eindruck, ein Büro liefere „bessere“ Arbeit als das andere. Wir begegnen dem mit einem einzigen, strengen Technikstandard an beiden Standorten:

• Code-Review ist standardmäßig standortübergreifend: Ein Pull Request aus Hyderabad wird von jemandem in Zug geprüft – und umgekehrt.
• Dieselbe CI/CD-Pipeline, dieselben Linting-Regeln, dieselben Testabdeckungs-Schwellen gelten überall.
• Architecture Decision Records (ADRs) werden gemeinsam erstellt und erfordern die Freigabe beider Standorte.
• Incident-Post-Mortems werden von beiden Büros besucht – unabhängig davon, welcher Code betroffen war.

Ziel ist nicht Uniformität um ihrer selbst willen. Es geht darum, dass jeder Ingenieur unabhängig vom Standort im gleichen Qualitätsrahmen arbeitet und nach dem gleichen Standard bewertet wird.

Was wir falsch gemacht haben

Ehrlichkeit über Misserfolge ist genauso wichtig wie das Teilen von Erfolgen. Drei Dinge mussten wir korrigieren.

Anfangs haben wir überdokumentiert. Um die Distanz auszugleichen, erstellten wir umfassende Spezifikationsdokumente, die keinen Interpretationsspielraum ließen. Ingenieure in Hyderabad fühlten sich als reine Umsetzer statt als Mitdenker. Wir sind zu schlanken Spezifikationen zurückgekehrt, die das „Was“ und „Warum“ beschreiben, das „Wie“ aber dem verantwortenden Team überlassen.

Wir haben kulturelle Kommunikationsstile unterschätzt. Schweizer Direktheit kann in der indischen Berufskultur als schroff wirken, indirekte indische Kommunikation in der Schweizer Kultur als Ausweichen. Beide Deutungen sind falsch. Wir haben in workshops zur interkulturellen Kommunikation investiert – keine generischen Unternehmensworkshops, sondern praxisnahe Sessions dazu, wie Dissens, Eskalation und Feedback in unseren spezifischen kulturellen Kontexten unterschiedlich funktionieren.

Anfangs haben wir in Hyderabad zu viele Junioren eingestellt. Um schnell zu skalieren, holten wir eine Kohorte talentierter, aber unerfahrener Ingenieure. Ohne ausreichend Senior-Mentoring vor Ort fiel es ihnen schwer, eigenständig zu entscheiden. Wir haben umstrukturiert und halten an jedem Standort ein Mindestverhältnis Senior zu Junior von 1:3 ein.

Teamgesundheit über Ländergrenzen messen

Klassische Metriken wie Velocity und Durchsatz zeigen, wie schnell ein Team arbeitet – nicht, wie gesund die Zusammenarbeit ist. Wir erfassen zusätzlich folgende Signale:

• Standortübergreifende-PR-Quote: Wie viel Prozent der Pull Requests werden von jemandem am anderen Standort geprüft? Eine sinkende Quote deutet auf Silobildung hin.
• Entscheidungsverteilung: Wer verfasst ADRs? Wenn die meisten Architekturentscheidungen von einem Standort ausgehen, ist die Verantwortung nicht wirklich geteilt.
• Freiwillige Fluktuationsdifferenz: Hat ein Standort deutlich höhere Fluktuation, stimmt etwas in der Arbeitsbeziehung nicht.
• Meeting-Stimmungsbefragungen: Kurze monatliche Umfragen, ob die Meetings in der Überlappungszeit als kollaborativ oder als anweisend empfunden werden.

Der Zinseszinseffekt

Ein wirklich verteiltes Team aufzubauen ist anspruchsvoll und dauert. Der Ertrag aber potenziert sich mit der Zeit. Heute implementiert unser Büro in Hyderabad nicht nur in der Schweiz designte Software. Es trägt eigene architektonische Innovationen bei, leitet Kundendiscovery-Sessions und betreut Junioren an beiden Standorten. Der Wissenstransfer verläuft in beide Richtungen – genau wie es sein soll.

Für Kunden bedeutet das Resilienz. Ein Projekt, das über zwei Büros und zwei Zeitzonen besetzt ist, kann Störungen abfedern – ob lokaler Feiertag, Krankheit oder plötzliche Scope-Änderung – ohne aus dem Tritt zu kommen. Es bedeutet auch längere Abdeckung: Unser effektiver Arbeitstag reicht vom frühen Morgen in Indien bis zum späten Nachmittag in der Schweiz und ermöglicht Kunden nahezu durchgängigen Fortschritt.

Verteilung ist keine reine Kostensenkung. Richtig umgesetzt ist sie ein Fähigkeitsmultiplikator.