Ein internationales Entwicklerteam von Grund auf aufbauen: worauf kommt es an?
Von der Ausschreibung bis zum ersten Sprint: wie ich ein sechsköpfiges internationales Entwicklerteam mit vollständiger Budgetverantwortung aufgebaut, ongeboardet und in den operativen Betrieb geführt habe.
Als mir die Aufgabe übertragen wurde, ein neues Entwicklerteam aufzubauen, war die Ausgangslage klar: sechs Stellen, internationale Kandidatinnen und Kandidaten, meine erste Budgetverantwortung und die Erwartung, dass das Team in einem überschaubaren Zeitraum liefert. Was auf dem Papier wie ein HR-Projekt aussieht, ist in der Realität eine der komplexesten und umfangreichsten Führungsaufgaben.
Der Recruitment-Prozess beginnt früher als die meisten denken. Bevor die erste Ausschreibung online geht, muss klar sein, welche Fähigkeiten das Team tatsächlich braucht und wie sie sich am besten ergänzen. Ich habe die Stellenprofile erarbeitet, Muss- und Kann-Kriterien scharf getrennt und Ausschreibungen so formuliert, dass sie die richtigen Personen ansprechen, nicht möglichst viele. Reichweite war nicht das Ziel, ich wollte passende Personen finden.
Die Vorauswahl und Vorgespräche habe ich selbst geführt, weil technische und kulturelle Übereinstimmungen am besten durch direkte Gespräche entstehen. Bei internationalen Kandidatinnen und Kandidaten kamen Zeitzonenkomplexität, unterschiedliche Erwartungen an Kommunikation und Zusammenarbeit sowie Fragen rund um Vertragsgestaltung und Remote-Setups hinzu, alles Dinge, die bei lokalem Recruiting vermutlich weniger von Bedeutung sind.
Das Bootcamp war für mich der entscheidende Schritt zwischen Recruiting und Betrieb. Vier intensive Wochen, in denen das Team nicht nur die technische Basis eingeübt hat – Toolchain, Codestandards, Deploymentprozesse, sondern auch gelernt hat, wie es zusammenarbeitet. Wer schreibt die Stories? Wie werden Abhängigkeiten kommuniziert? Wie geht das Team mit Blockern um? Diese Muster wollte ich früh festlegen, damit sie später nicht zu einem Problem werden.
Danach folgte die Schulungsphase mit einem klaren Ziel: das Team sollte selbstständig urteilen können, nicht nur Anweisungen ausführen. Dazu gehörte fachliches Wissen ebenso wie das Verständnis für den Gesamtkontext. Warum gibt es dieses System? Wer nutzt es? Was passiert, wenn etwas schiefgeht?
Im operativen Betrieb habe ich die Scrum-Struktur konsequent umgesetzt: Sprint-Planung mit klaren Zielen und realistischer Kapazitätsplanung, Story-Erstellung gemeinsam mit Product Owner, Abnahme mit direktem Feedback aus dem Fachbereich und Retros, die langsam, aber stetig zu Verbesserungen geführt haben.
Was ich aus diesem Aufbau mitnehme: Ein Team ist keine Ressource, die man zusammenstellt und dann laufen lässt. Es ist ein System, das gepflegt werden muss. Investitionen in die frühen Phasen (Ausschreibung, Auswahl, Bootcamp) zahlen sich doppelt aus, weil sie später teure Reibungsverluste vermeiden. Und Budgetverantwortung in diesem Kontext bedeutet nicht Sparen, sondern priorisieren: dort investieren, wo es den grössten Hebel hat.