16 September 20257 Min. Lesezeit
Niemand budgetiert die Einarbeitung. Der Vertrag beginnt am Ersten des Monats, der Satz ist vereinbart, und unter dem Plan liegt die Annahme, dass an diesem Morgen nützliche Arbeit beginnt. Das tut sie nicht, und in der Lücke zwischen dieser Annahme und der Realität verschwindet ein überraschender Teil des Geldes.
Das ist keine Klage über Outsourcing. Eine neue Angestellte hat dieselbe Einarbeitung, meist eine längere. Der Unterschied ist, dass niemand von einer Angestellten in Woche eins Produktivität erwartet und alle es von jemandem erwarten, den sie pro Tag bezahlen. Diese Erwartung macht die ersten zwei Wochen schlechter, nicht besser.
Die Einarbeitung ist real, und sie ist nicht kostenlos
Wer in eine unvertraute Codebasis kommt, muss drei getrennte Dinge lernen: wie das System funktioniert, wie Ihr Team arbeitet und was Sie tatsächlich wollen. Das Erste geht am schnellsten, denn es steht im Code. Das Zweite und Dritte stehen fast nirgends geschrieben, und genau deshalb ist Remote-Onboarding schwieriger als die Variante am selben Ort.
In einem Büro sickert die dritte Kategorie durch. Sie hören die Diskussion über den Release-Prozess mit, Sie bemerken, dass die Person, der Testabdeckung wichtig ist, zwei Schreibtische weiter sitzt, Sie lernen, dass niemand den Abrechnungsdienst anfasst, ohne vorher zu fragen. Nichts davon erreicht jemanden, der aus Beirut arbeitet, wenn Sie es nicht bewusst irgendwo hinschreiben.
Planen Sie damit. Eine vernünftige Arbeitsannahme für eine Entwicklerin mittlerer Erfahrung, die in ein System üblicher Komplexität kommt, ist eine erste Woche, die wenig hervorbringt, eine zweite Woche, die etwas Kleines und Echtes hervorbringt, und ein erster Monat, der damit endet, dass sie bei gut verstandener Arbeit ohne Aufsicht ausliefert. Wenn Sie dafür keinen Raum gelassen haben, ist der Plan falsch, und die Person wird dafür bezahlen.
Woche null: was vor dem Start vorhanden sein sollte
Das Wirksamste, was Sie tun können, ist, die langweiligen Blocker vor den Starttermin zu ziehen statt danach. Jede Stunde Warten auf einen Zugang wird zum selben Satz abgerechnet wie eine Stunde Programmieren.
- Jedes Konto von jemand anderem angelegt und getestet: Repository, CI, Ticket-Tracker, Chat, Staging, Fehler-Tracking und was die Arbeit sonst berührt.
- Eine README, mit der das Projekt lokal läuft, im letzten Monat von jemandem überprüft, der ihr wörtlich gefolgt ist statt aus dem Gedächtnis.
- Eine benannte Person, die dafür verantwortlich ist, ihre Fragen zu beantworten, wobei diese Verantwortung ausgesprochen und nicht stillschweigend vorausgesetzt wird.
- Ein erstes Ticket, vorab ausgewählt, klein und wirklich nützlich.
- Die Unterschriften erledigt: Vertrag, Rechteübertragung und der AV-Vertrag, falls personenbezogene Daten berührt werden.
Nichts davon ist schwierig. Es ist schlicht Arbeit, die nur erledigt wird, wenn jemand sie verantwortet, und fast immer verantwortet sie niemand, weshalb die erste Woche so oft in Zugangsanträgen verschwindet.
Die erste Aufgabe sollte klein, echt und lieferbar sein
Der Impuls ist, mit Lesen zu beginnen: Hier ist die Codebasis, machen Sie sich ein paar Tage vertraut. Das ist eine schlechte Verwendung für eine Woche. Ein System zu lesen, ohne einen Grund zu haben, es anzufassen, erzeugt eine flache Landkarte, die bis zum folgenden Montag verdunstet.
Geben Sie ihnen stattdessen etwas Kleines, das in die Produktion geht. Eine sichtbare Fehlerbehebung, einen kleinen Endpunkt, einen Text, der durch die ganze Pipeline muss. Der Punkt ist nicht die Änderung. Der Punkt ist, dass ihre Auslieferung sie auf einen Schlag durch jeden Teil Ihres Prozesses zwingt: lokales Setup, Branch-Konventionen, Review, CI, Deployment und wer immer es freigeben muss. Sie werden die kaputten Teile Ihres Prozesses finden, denn sie sind die Einzigen im Haus, die noch nicht gelernt haben, sie zu umgehen.
Kontext kommt in Schichten, nicht in einem Dokument
Es ist verlockend, das riesige Onboarding-Dokument zu schreiben. Es übersteht den Kontakt mit der Realität selten, weil es einmal geschrieben, einmal gelesen und binnen eines Quartals veraltet ist.
Ein haltbareres Muster ist geschichtet. Eine kurze Orientierungsseite, die erklärt, was das Produkt tut, wer es nutzt und wie Geld ins Unternehmen kommt. Eine zweite Schicht mit Architekturnotizen, idealerweise dort abgelegt, wo der beschriebene Code liegt. Eine dritte Schicht, die gar kein Dokument ist: die Gewohnheit, die Begründung in Tickets und Pull Requests zu schreiben, sodass der Kontext an der Arbeit hängt statt in einem Ordner, den niemand zweimal öffnet.
Die dritte Ebene ist die, auf die es über ein Jahr ankommt. Die ersten beiden bringen jemanden durch die ersten zwei Wochen.
Benennen Sie eine Person, kein Team
„Fragen Sie im Channel, wenn Sie nicht weiterkommen“ klingt einladend und wirkt wie eine Mauer. Eine neue Person unterbricht nicht acht Fremde, um etwas zu fragen, das sie für offensichtlich hält; sie rät stattdessen zwei Stunden lang, und sie rät auf eine Weise falsch, die im Review einen Tag kostet.
Benennen Sie für den ersten Monat eine Person als erste Anlaufstelle. Sagen Sie ihr, dass das Teil ihrer Aufgabe ist und kein Gefallen, und rechnen Sie damit, dass es sie ein paar Stunden pro Woche kostet. Diese Kosten sind real, und sie gehören neben den Satz in Ihre Rechnung, was die Zusammenarbeit kostet.
Die Überschneidung der Arbeitszeiten macht das billig. Eine Frage, die um elf gestellt und um Viertel nach elf beantwortet wird, kostet fast nichts. Dieselbe Frage in eine Lücke von einem Arbeitstag hinein kostet den Rest des Tages, und nach zwei oder drei davon hören die Leute auf zu fragen. Genau das verhindern Sie.
Teil des Teams, ohne so zu tun, als wären sie Angestellte
Hier gibt es zwei gegensätzliche Fehler, und beide sind häufig. Der erste ist, die ausgelagerte Person strukturell getrennt zu halten: eigener Kanal, eigenes Stand-up, eigenes Backlog. Sie driftet ab, weil sie mit einer veralteten Fassung des Plans arbeitet, und bis es jemandem auffällt, muss eine Arbeit von zwei Wochen neu gemacht werden.
Das zweite ist, so zu tun, als gäbe es den vertraglichen Unterschied nicht. Es gibt ihn. Diese Menschen stehen nicht auf Ihrer Gehaltsliste, sie arbeiten womöglich für andere Kunden, ihre Kündigungsfrist ist eine andere, und ihre Zugriffsrechte sollten auf das beschränkt sein, was die Arbeit verlangt, statt auf alles. Das offen zu sagen ist keine Ausgrenzung, und es zum Tabu zu erklären führt nur dazu, dass niemand das Ende der Zusammenarbeit plant.
Die tragfähige Haltung ist einfach: gleiches Backlog, gleicher Kanal, gleiche Definition of Done, gleiche Review-Standards, gleiche Einladung, in einer Design-Diskussion zu widersprechen. Anderer Vertrag, anderer Zugriffsumfang, andere Erwartungen an Dauerhaftigkeit. Diese Konstruktion verwirrt niemanden außer Führungskräfte, die sie nie ausgesprochen haben.
Wie Woche zwei aussehen sollte
Am Ende der zweiten Woche sollen drei Dinge zutreffen: Etwas, das sie geschrieben haben, ist in der Produktion, sie haben mindestens ein paar nicht triviale Fragen gestellt, und sie haben mindestens eine Sache an Ihrem Aufbau gefunden, die falsch ist. Wenn alle drei eingetreten sind, hat das Onboarding funktioniert, und Sie können aufhören, es eng zu begleiten.
Wenn keines davon eingetreten ist, warten Sie nicht bis zum zweiten Monat, um den Grund zu erfahren. Die häufigste Ursache ist nicht Können. Es ist, dass niemand die erste Aufgabe konkret gemacht hat, sodass die Person zwei Wochen lang gelesen hat, höflich verfügbar war und darauf wartete, dass ihr jemand sagt, was zu tun ist.