Der Zwei-Wochen-Start: Was „produktiv ab der ersten Woche“ für einen externen Entwickler wirklich bedeutet

Warum „produktiv ab Woche eins“ eine faire Erwartung ist

Wenn ein Kunde einen externen Entwickler ins Projekt holt, lautet die erste Frage fast immer gleich: Wie schnell ist diese Person tatsächlich nützlich? Bei einer Festanstellung liegt die ehrliche Antwort bei Monaten. Ein gutes Onboarding für externe Entwickler sollte in Tagen gemessen werden. Diese Lücke hat wenig mit Talent zu tun. Sie hängt davon ab, wie eng die Aufgabe abgegrenzt ist und wie gut der Kunde sich vor Tag eins vorbereitet.

Das ist deshalb wichtig, weil Interims- und Freelance-Einsätze meist beginnen, wenn ohnehin schon etwas brennt: eine Deadline rutscht, eine Schlüsselperson ist krank, ein Projekt steht seit sechs Wochen still und niemand hat Zeit, es wieder in Gang zu bringen. Niemand holt sich einen Auftragnehmer für eine entspannte dreimonatige Einarbeitung. Braucht der Entwickler einen Monat, bevor überhaupt etwas Reales live geht, hat der Einsatz seinen eigentlichen Zweck bereits verfehlt.

Wofür der Onboarding-Monat einer Festanstellung eigentlich da ist

Es hilft, sich klarzumachen, warum das Onboarding einer Festanstellung so lange dauert, denn die Antwort lautet nicht „die Codebasis ist schwierig“. Eine neue, fest angestellte Person wird in eine Karriere eingeführt, nicht nur in eine Aufgabe. Sie muss Teamnormen verstehen, Menschen in der ganzen Organisation kennenlernen, die Roadmap für das kommende Jahr lernen, sich bei Benefits und Gehaltsabrechnung einrichten und den Kontext aufbauen, der sich über drei oder vier Jahre Beschäftigung auszahlt. Das über sechzig oder neunzig Tage zu verteilen, ist sinnvoll, weil das Unternehmen in eine langfristige Beziehung investiert.

Nichts davon gilt für einen Auftragnehmer, der engagiert wurde, um eine Sache zu reparieren oder eine Lücke zu schließen. Ein externer Entwickler muss die Fünf-Jahres-Produktvision nicht verstehen, um einen kaputten Checkout-Flow zu reparieren oder eine ins Stocken geratene Migration zu übernehmen. Einen Auftragnehmer genauso einzuarbeiten wie eine festangestellte Person zu onboarden, verschwendet das Geld des Kunden und die Zeit des Auftragnehmers mit Kontext, nach dem niemand gefragt hat.

Was Sie vor dem ersten Arbeitstag des Entwicklers vorbereiten müssen

Das Tempo des Onboardings externer Entwickler entscheidet sich größtenteils beim Kunden, nicht beim Auftragnehmer, denn der Entwickler kann erst mit der Problemlösung beginnen, wenn er das System tatsächlich erreichen kann. In der Praxis läuft das auf drei Dinge hinaus:

• Zugang zu Repository, Servern und Tooling, der vor Vertragsbeginn eingerichtet wird, nicht erst am ersten Tag angefragt und drei Tage später von jemandem im Urlaub genehmigt wird.
• Eine lokale Umgebung, die eine fremde Person anhand vorhandener Dokumentation selbst aufsetzen kann, ohne dafür extra einen Call ansetzen zu müssen, nur um die Anwendung zu starten.
• Eine Person, die Fragen beantworten und kleine Entscheidungen treffen kann, ohne ein Meeting einzuberufen. Keine Ticket-Warteschlange, kein Slack-Kanal, den drei Leute halb im Blick haben. Ein Name.

Unternehmen, die das richtig machen, können einen Auftragnehmer noch am ersten Tag echten Code committen lassen. Unternehmen, die das versäumen, verlieren oft die erste Woche an Zugangsanfragen, die zwischen IT, einem reisenden Vorgesetzten und einem VPN-Zertifikat hin- und herspringen, an dessen Ausstellung sich niemand mehr erinnert. Diese verlorene Woche ist nicht das Onboarding-Problem des Entwicklers. Es ist ein Vorbereitungsproblem, und es liegt in der Verantwortung des Kunden, es zu lösen.

Was ein kompetenter externer Entwickler in den ersten zehn Arbeitstagen liefert

Vorausgesetzt, Zugang und Ansprechpartner stehen, sieht ein realistischer Zeitplan für gut gemachtes Onboarding externer Entwickler so aus.

Bis Tag zwei läuft die Umgebung lokal, die Testsuite ist grün, und der Entwickler hat einen ersten kleinen, echten Commit gemacht statt einer Wegwerf-„Hello World“-Änderung. Das ist der schnellste Weg, um Umgebungsprobleme, kaputte Build-Skripte oder fehlende Dokumentation aufzudecken, bevor sie später echte Zeit kosten.

Bis Tag fünf wurde ein echtes Stück Arbeit reviewt und gemerged, keine Aufwärmaufgabe, die nur erfunden wurde, um die neue Person zu beschäftigen. War der Einsatz um einen konkreten Bug, einen Migrationsschritt oder ein Feature herum geplant, sollte diese Arbeit bereits sichtbar vorankommen.

Bis Tag zehn besitzt der Entwickler einen klar abgegrenzten Teil des Projekts vollständig: ein Modul, eine Bug-Queue, eine definierte Phase einer Migration. An diesem Punkt sollte weniger Betreuung nötig sein, als man es bei einem Zwei-Wochen-Einsatz erwarten würde, weil der Scope eng genug war, um ihn tatsächlich in zwei Wochen zu lernen.

Nichts davon erfordert, dass der Entwickler sich durch ein unternehmensweites Onboarding-Deck klickt oder das Organigramm lernt. Es erfordert ein klar definiertes Problem, funktionierenden Zugang und jemanden, der eine Frage innerhalb einer Stunde statt einer Woche klären kann.

Eine typische Ausprägung dieses Problems: Ein Zwei-Wochen-Einsatz verliert seine ersten vier Tage, weil eine einzelne Cloud-Console-Einladung auf die eine Person wartet, die sie erteilen kann, und genau diese Person gerade verreist ist. Der Entwickler wird abgerechnet und sitzt im Leerlauf. Das ist kein Onboarding-Versagen auf Seiten des Auftragnehmers. Es ist eine Vorbereitungslücke, die eine halbstündige Checkliste vor Vertragsunterzeichnung geschlossen hätte.

Worin sich das vom Onboarding-Plan für Festangestellte unterscheidet

Wer an einen strukturierten 30-60-90-Tage-Plan für Festangestellte gewöhnt ist, ist versucht, dasselbe Raster auf einen Auftragnehmer anzuwenden und die Erwartungen entsprechend zu strecken. Widerstehen Sie diesem Impuls. Der 30-60-90-Tage-Plan ist für jemanden gedacht, der in drei Jahren noch im Unternehmen sein wird und entsprechend breiten Kontext braucht. Ein Zehn-Tage-Plan ist für jemanden gedacht, der ein Problem gut löst und den Einsatz danach entweder verlängert oder weiterzieht. Den ersten Monat eines Auftragnehmers wie das erste Quartal einer festangestellten Person zu behandeln, ist der Grund, warum Unternehmen am Ende Senior-Tagessätze für Arbeit zahlen, die eigentlich schon in Woche eins hätte live gehen sollen.

Dieselbe Logik gilt, wenn die Codebasis selbst das eigentliche Hindernis ist und nicht der Onboarding-Prozess. Ein Entwickler kann in einem Projekt ohne Tests, ohne Dokumentation und mit Jahren an undokumentiertem Stammeswissen nicht schnell produktiv werden, egal wie viel Zugang er am ersten Tag erhält. In diesem Fall liegt die ehrliche Lösung nicht in einer besseren Onboarding-Checkliste. Sie liegt darin, das Codebasis-Problem direkt anzugehen, bevor überhaupt jemand daran arbeiten soll, Auftragnehmer oder nicht.

Anzeichen dafür, dass das Onboarding nicht funktioniert

Ein paar Warnsignale zeigen sich meist früh, wenn das Onboarding externer Entwickler schiefläuft. Der Auftragnehmer wartet nach drei oder vier Tagen immer noch auf Zugang. Niemand kann eine grundlegende Frage dazu beantworten, wie das System deployt wird. Der Scope der Arbeit verschiebt sich ständig, weil er vor Vertragsbeginn nie klar definiert wurde. Oder der Kunde erwartet dieselbe Einarbeitungskurve wie bei einer Festanstellung und ist frustriert, wenn der Auftragnehmer in Woche eins gezielte Fragen stellt, statt einen Monat lang stillschweigend Code zu lesen.

Jedes einzelne davon lässt sich mitten im Einsatz noch beheben. Alle zusammen bedeuten meist, dass der Einsatz von Anfang an auf einen langsamen Start ausgelegt war, unabhängig davon, wer die Arbeit übernommen hat.

Kurz zusammengefasst

Ein fähiger externer Entwickler sollte das Projekt innerhalb von ein, zwei Tagen lokal zum Laufen bringen, innerhalb einer Woche echte, reviewte Arbeit liefern und bis Tag zehn einen klar definierten Teil des Projekts besitzen. Ob das gelingt, hängt weit mehr davon ab, was der Kunde vorbereitet, Zugang, eine funktionierende lokale Umgebung und einen klaren Ansprechpartner, als von irgendetwas, das der Entwickler nach seiner Ankunft tut.

Wenn Sie externe Unterstützung ins Team holen und eine realistische Einschätzung wollen, wie die ersten zwei Wochen für Ihre konkrete Codebasis aussehen sollten, erreichen Sie Wolf-Tech unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir können Ihnen in einem kurzen Gespräch sagen, ob das Onboarding oder die Codebasis selbst der langsame Teil sein wird.