Tech-Teams in der Schweiz ohne Verzögerung skalieren

Der Engpass eines Schweizer Startups beim Engineering-Team ist selten das Budget. Es ist die vergangene Zeit — die Monate zwischen dem Entschluss, jemanden zu brauchen, und der ersten produktiven Woche.

Fünf bis sechs Monate von der Ausschreibung bis zur produktiven Person sind hier normal. Für ein Unternehmen mit achtzehn Monaten Reichweite ist das ein Drittel davon mit Warten — und der Plan wurde mit ziemlicher Sicherheit anders geschrieben.

Warum es langsam ist, konkret

Die Ursachen gehören benannt, denn jede hat einen anderen Ausweg.

• Kündigungsfristen. Drei Monate sind bei erfahrenen Rollen in der Schweiz üblich, und sie sind vertraglich, nicht verhandelbar.
• Ein kleiner Bewerberkreis. Bei spezialisierten Profilen — MLOps, Data Engineering, Plattform — ist die Zahl qualifizierter Personen im erreichbaren Umkreis tatsächlich klein.
• Wettbewerb durch grosse Arbeitgeber, die mehr zahlen können als ein Startup — und warten können.
• Einarbeitungsbremse. Eine neue Person bindet über Wochen Zeit der bestehenden. Drei gleichzeitig einzustellen kann die Leistung ein Quartal lang senken.

Nur einer dieser Punkte handelt von Geld.

Fünf Wege zu schnellerer Kapazität

1. Eine hybride Talentstrategie, bewusst entschieden

Teilen Sie den Bedarf und besetzen Sie jede Hälfte anders:

• Fest und lokal — Arbeit, bei der Kontinuität den Wert ausmacht. Produktwissen, Architekturverantwortung, alles mit Kundenkontakt. Das Warten und den Lohn wert.
• Flexibel und extern — spezialisierte oder zeitlich begrenzte Arbeit. Ein Plattformaufbau, eine Migration, eine Integration. Für einen Sechsmonatsbedarf eine feste Stelle zu schaffen ist in beide Richtungen teuer.

Der Fehler ist, diese Teilung als Notlösung zu behandeln, wenn die Rekrutierung scheitert — statt als Entwurf. Im Voraus entschieden, bestimmt sie, welche Stellen Sie öffnen und welche nie.

2. Nearshore- und Offshore-Kapazität mit echter Überlappung

Entscheidend ist nicht der Ort, sondern Überlappung und Kontinuität.

Überlappung zur MEZ bedeutet Abstimmung, Reviews und Demos am selben Tag statt eines 24-Stunden-Umlaufs pro Frage. Kontinuität bedeutet ein benanntes Team statt eines wechselnden Pools — denn ein wechselnder Pool setzt den Kontext jedes Mal zurück, und Sie zahlen die Spezifikationskosten erneut.

Worauf zu bestehen ist: benannte Personen, Zugang zu denselben Werkzeugen und Betriebsdaten wie das eigene Team und Teilnahme an denselben Ritualen. Ein Team ohne Sicht auf die Produktion kann keine Ergebnisse verantworten.

3. Die benötigte Personenzahl senken

Die günstigste Engineering-Kraft ist die, die Sie nicht einstellen mussten, weil die Arbeit weggefallen ist.

Wo sich das in einem jungen Unternehmen meist auszahlt:

• Release-Automatisierung. Manuelles Ausliefern bindet wöchentlich erfahrene Zeit und bringt nichts hervor.
• Umgebungsbereitstellung. Dauert eine Testumgebung Tage, arbeiten alle daran vorbei — schlecht.
• Die wiederkehrende Störung. Die meisten Teams haben ein bis zwei Fehlerbilder, die monatlich Stunden kosten und nie behoben wurden, weil keine Zeit ist. Was zirkulär ist.

Eine Woche hier bringt oft mehr als ein Quartal Rekrutierung.

4. Für die nächste Stufe einstellen, nicht für die aktuelle Lücke

Startups stellen für den akuten Schmerz ein. Das ergibt ein Team, das wie eine Liste vergangener Notfälle geformt ist.

Die nützlichere Frage: Was muss das Team können, wenn das Volumen dreimal höher ist? Die Antwort lautet meist: weniger, dafür erfahrenere Personen mit breiterem Zuschnitt — nicht mehr vom heutigen Profil.

5. Remote-First, mit tatsächlich geklärten Schweizer Pflichten

Remote vergrössert den Kreis, das ist der Zweck. Es bringt auch Pflichten mit, die spät entdeckt werden:

• Arbeits- und Sozialversicherungsrecht richten sich danach, wo die Person sitzt, und das lässt sich nicht aufschieben.
• Datenzugriff nach revDSG/nDSG und DSGVO ist eine echte Frage, wenn Engineers in einer anderen Rechtsordnung Personendaten berühren. Pseudonymisierte Datensätze, dokumentierte Zugriffskontrollen und Nachweise zur Unterauftragsverarbeitung lösen das — aber nicht rückwirkend.
• Vertragspartner. Liegt die Verantwortung in einer anderen Rechtsordnung als die Pflicht, ist sie theoretisch.

Nichts davon spricht gegen Remote. Es spricht dafür, das vor der ersten Anstellung zu klären statt vor der fünften.

Kennzahlen, die zeigen, ob die Skalierung wirkt

Die Kopfzahl wird überall berichtet und sagt fast nichts. Vier, die etwas sagen:

• Zeit von der Ausschreibung bis zur ersten übernommenen Änderung. Der echte Rekrutierungszyklus, Einarbeitung inbegriffen.
• Kosten pro gelieferter Änderung, über Quartale verfolgt. Steigen sie, während das Team wächst, haben Sie ein Abstimmungs- oder Strukturproblem, kein Kapazitätsproblem.
• Anteil ungeplanter Arbeit. Steigt er, verzehrt die Landschaft die gerade hinzugefügte Kapazität.
• Schlüsselpersonenrisiko bei kritischen Systemen. Versteht nur eine Person etwas, senkt zusätzliches Personal anderswo das Risiko nicht.

Der zweite Punkt überrascht Gründerinnen und Gründer am häufigsten. Mehr Personen sollten die Stückkosten senken; tun sie es nicht, war der Engpass strukturell und Rekrutierung das falsche Instrument — ein Muster, das in Versteckte Kosten der Skalierung behandelt wird.

Weiterführend

• Den richtigen Softwareentwicklungspartner auswählen
• Engineering-ROI maximieren: Leitfaden für Finanzchefs
• Dedizierte Entwicklungsteams

Wenn Sie Kapazität schneller brauchen, als ein Rekrutierungszyklus erlaubt, vereinbaren Sie ein Gespräch. Unverbindlich.