Interim-Softwareentwickler: Wann ein temporärer Entwickler besser ist als auf eine Einstellung zu warten

Ein Entwickler kündigt mit vier Wochen Frist. Jemand geht für sechs Monate in Elternzeit. Eine Schlüsselkraft fällt krankheitsbedingt aus, ohne absehbares Rückkehrdatum. In jeder dieser Situationen braucht der Code weiterhin Aufmerksamkeit, nur weil die Person, die ihn geschrieben hat, nicht verfügbar ist, hört das Bedürfnis danach nicht auf. Releases müssen trotzdem rausgehen, Bugs werden weiterhin gemeldet, und Kunden erwarten weiterhin, dass das Produkt funktioniert.

Genau diese Lücke füllt ein Interim-Softwareentwickler. Kein Berater, der sich Ihre Codebasis ansieht und einen Bericht hinterlässt, und keine feste Einstellung, deren Suche und Einarbeitung drei Monate dauert. Ein Interim-Entwickler kommt zu Ihrem Team mit einem festgelegten Zeitrahmen, schreibt und liefert Code innerhalb Ihrer bestehenden Systeme und übergibt saubere, wenn die Lücke geschlossen ist, sei es, weil die kranke Kollegin zurückkehrt oder eine feste Einstellung beginnt.

Was ein Interim-Entwickler tatsächlich macht

Ein Interim-Softwareentwickler arbeitet innerhalb Ihrer Codebasis so, wie es ein regulärer Teamkollege tun würde: Tickets übernehmen, Pull Requests reviewen, Änderungen deployen und an Standups teilnehmen. Der Unterschied zu einer festen Einstellung liegt im Engagement selbst. Es basiert auf einem bekannten Startdatum, einem groben Enddatum und einem konkreten Scope, meist „dieses Produkt am Laufen halten und weiterentwickeln, bis X passiert."

Das unterscheidet sich von klassischer Staff Augmentation, bei der einfach eine zusätzliche Person in einen Sprint geschoben wird, um Kapazität zu schaffen. Ein Interim-Entwickler ist meist seniorer, weil die Aufgabe verlangt, schnell produktiv zu werden, mit minimaler Einarbeitungszeit, und Entscheidungen zu treffen, ohne monatelangen Kontext zu haben. Es unterscheidet sich auch von einem Fractional-CTO-Engagement, bei dem es um Strategie und technische Führung an wenigen Tagen im Monat geht, nicht um die tägliche Umsetzung. Wenn Sie jemanden brauchen, der die Richtung vorgibt, nicht Code schreibt, ist das ein anderes Thema (wir behandeln das Fractional-Modell in unserem Fractional-CTO-Leitfaden).

Die Arbeit selbst hängt davon ab, was bereits vorhanden ist. Manche Engagements sind eher Wartungsarbeit: den Betrieb aufrechterhalten, Fehler beheben, kleine bereits geplante Features liefern. Andere beinhalten die Übernahme eines halbfertigen Projekts bis zum Release. In jedem Fall arbeitet der Interim-Entwickler innerhalb Ihres Stacks und Ihres Prozesses, nicht mit einem eigenen, mitgebrachten.

Die Situationen, die das tatsächlich erfordern

Ein Entwickler kündigt. Kündigungsfristen sind kurz, und die Suche nach einem Ersatz ist selten abgeschlossen, bevor die Person das Unternehmen verlässt. Ein Interim-Entwickler deckt die Lücke zwischen dem letzten Arbeitstag der alten Einstellung und dem ersten Tag der neuen, damit das Produkt nicht zwei oder drei Monate lang unberührt bleibt, während das Recruiting läuft.

Jemand ist in Elternzeit. Elternzeit, eine längere Krankschreibung oder ein Sabbatical schaffen alle dasselbe Problem: eine klar definierte Abwesenheit mit einem (manchmal verschiebbaren) Rückkehrdatum. Diese Lücke mit einer festen Einstellung zu besetzen, ergibt keinen Sinn, da die Stelle nicht dauerhaft offen ist. Eine Interim-Lösung passt zur Form der Lücke.

Eine Stelle bleibt während einer Suche unbesetzt. Die Suche nach einem guten Senior-Entwickler kann drei bis sechs Monate dauern, von der Ausschreibung bis zur angenommenen Zusage, bei spezialisierten Stacks oder wählerischen Unternehmen noch länger. In der Zwischenzeit pausiert die Roadmap nicht. Ein Interim-Entwickler hält den Schwung während der Suche selbst aufrecht, was auch den Druck nimmt, die Einstellungsentscheidung zu überstürzen.

Ein Projekt muss ausgeliefert werden, bevor eine Festanstellung gerechtfertigt wäre. Manchmal gibt es einen echten, zeitlich begrenzten Bedarf (eine Kundenfrist, eine Investorendemo, eine Compliance-Deadline), der sich nach Abschluss nicht in eine Vollzeitrolle übersetzt. Jemanden fest für einen dreimonatigen Push einzustellen und danach keine Arbeit mehr für diese Person zu haben, passt für beide Seiten schlecht. Ein Interim-Engagement ist auf den tatsächlichen Bedarf zugeschnitten.

Der gemeinsame Nenner bei allen vier Fällen ist ein definierter Endpunkt. Wenn Sie wirklich nicht wissen, wann der Bedarf endet, oder wenn Sie vermuten, dass es sich eigentlich um eine feste Rolle handelt, die Sie noch nicht ausgeschrieben haben, ist ein Interim-Entwickler das falsche Werkzeug. Nutzen Sie einen, wenn die Lücke eine Form hat, auch nur eine ungefähre.

Wie die ersten zwei Wochen aussehen

Die ersten zwei Wochen entscheiden, ob der Rest des Engagements reibungslos läuft, sie verdienen also mehr Struktur als „den Code lesen und anfangen, Tickets zu übernehmen."

Woche eins dreht sich fast vollständig um Einarbeitung: Zugang zu den Repositories, der CI/CD-Pipeline, Staging- und Produktionsumgebungen und allen Projektmanagement-Tools, die das Team nutzt. Ein guter Interim-Entwickler bittet auch um eine Führung durch das System von der Person, die es am besten kennt, egal ob das ein verbliebenes Teammitglied, ein Tech Lead oder ein Gründer ist, statt zu versuchen, alles allein aus dem Code zu rekonstruieren. Architekturentscheidungen, die vor achtzehn Monaten Sinn ergaben, erklären sich selten von selbst.

Bis zum Ende der ersten Woche ist das Ziel eine funktionierende lokale Umgebung, ein erster kleiner gemergter Pull Request (auch etwas Kleines reicht, weil es die gesamte Pipeline Ende-zu-Ende validiert) und eine kurze Liste offener Fragen zu den unklaren oder schlecht dokumentierten Teilen des Systems.

Woche zwei geht in echten Durchsatz über. Der Interim-Entwickler sollte reale Backlog-Elemente übernehmen, keine Schattenarbeit, und in Produktion ausliefern. Jetzt fallen auch typischerweise erste Warnsignale auf: fehlende Tests an kritischen Stellen, undokumentierte Deploy-Schritte, eine Datenbankmigration, die offensichtlich überstürzt war. Das früh aufzudecken, solange noch jemand verfügbar ist, um Fragen zu beantworten, ist weit nützlicher, als es drei Monate später zu entdecken, wenn die Person, die die Antwort kannte, schon weg ist.

Wenn nach zwei Wochen noch kein Code ausgeliefert wurde und keine Klarheit über Prioritäten besteht, ist das ein direktes Gespräch wert. Meist liegt es an unklarem Scope auf Ihrer Seite, nicht an einem schlechten Fit mit dem Entwickler, und es lässt sich in Woche zwei viel günstiger beheben als in Woche acht.

Wie die Übergabe funktioniert

Das Ende eines Interim-Engagements sollte wie ein geplanter Übergang aussehen, nicht wie ein abrupter Stopp. Einige Wochen vor dem bekannten Enddatum (dem Startdatum einer festen Einstellung, der Rückkehr einer Kollegin aus der Elternzeit, einer Projektfrist) verschiebt sich der Fokus von „weiter liefern" zu „sicherstellen, dass die nächste Person nicht bei null anfängt."

In der Praxis bedeutet das, laufende Arbeit abzuschließen oder sicher zu pausieren statt etwas halb gebaut zurückzulassen, Entscheidungen festzuhalten, die nur im Kopf des Interim-Entwicklers existieren (warum eine bestimmte Bibliothek gewählt wurde, wofür ein Workaround kompensiert, was bewusst als technische Schuld für später zurückgelassen wird), und, wo möglich, eine kurze Überlappung mit der kommenden festen Einstellung, damit Fragen direkt beantwortet werden können statt nur über Dokumentation.

Diese Überlappungsphase ist es wert, eingeplant zu werden, wenn es der Zeitplan erlaubt. Schon ein paar Tage, in denen der Interim-Entwickler und die neue feste Einstellung nebeneinander arbeiten, sparen Wochen, in denen die neue Person Kontext wiederentdecken müsste, der bereits existiert hat. Wenn die Lücke speziell durch eine Elternzeit-Vertretung abgedeckt wurde, ist die Übergabe einfacher: Die zurückkehrende Person kennt das System bereits und braucht hauptsächlich eine Zusammenfassung dessen, was sich während ihrer Abwesenheit geändert hat.

Ist ein Interim-Entwickler die richtige Entscheidung

Wenn die Lücke einen groben Endpunkt hat, sei es ein Einstellungszeitplan, ein Rückkehrdatum aus der Elternzeit oder eine Projektfrist, ist ein Interim-Softwareentwickler meist die bessere Wahl, als entweder eine feste Einstellung zu überstürzen oder das Produkt stillstehen zu lassen. Er bringt während der Lücke Code in Produktion, nimmt der festen Suche Druck und übergibt saubere, wenn der Bedarf gelöst ist.

Wenn das, was fehlt, näher an einem vollwertigen Custom-Software-Development-Engagement liegt, einem größeren Build mit eigenem Scope und Team, oder wenn das Problem eher die Gesundheit der bestehenden Codebasis betrifft als eine Personallücke, ist ein Code-Quality-Audit oft der bessere Startpunkt.

Wir bei Wolf-Tech haben Vakanzen, Elternzeiten, Kündigungen und zeitlich begrenzte Projekte abgedeckt, innerhalb bestehender PHP-, Symfony-, React- und Next.js-Codebasen, ohne das Laufende zu stören. Wenn Sie vor einer solchen Lücke stehen, schreiben Sie uns an hello@wolf-tech.io oder erfahren Sie mehr darüber, wie wir arbeiten, auf wolf-tech.io.