Remote Onboarding Checkliste für IT-Unternehmen (2026) [+ Kostenlose Vorlage]

Die meisten Remote-Onboarding-Checklisten sind für HR-Generalisten geschrieben. Sie decken den Versand von Equipment, Willkommens-E-Mails und die Anmeldung zu Benefits ab und hören dann auf. Es gibt nichts zur Einrichtung einer Dev-Umgebung, zur Vergabe des richtigen Repo-Zugriffs oder dazu, wie Sie einen neuen Entwickler bis Tag 5 zum ersten PR bringen.

Diese Remote Onboarding Checkliste ist anders. Sie ist speziell für IT-Unternehmen gebaut: Software-Häuser, Produktteams und verteilte Engineering-Organisationen, die remote einstellen und brauchen, dass das Onboarding wirklich funktioniert. Sie finden eine phasenweise Checkliste (Vorbereitung bis Monat eins), eine rollenbasierte Verantwortungstabelle, häufige Fehler, die Engineering Manager machen, und die Kennzahlen, die sich lohnt zu tracken. Am Ende gibt es auch eine kostenlose PDF- und Notion-Vorlage.

Wenn Sie gerade Remote-Entwickler einstellen, deckt der Leitfaden So automatisieren Sie die Einarbeitung von Remote-Entwicklern die Seite der Dokumentenautomatisierung detaillierter ab. Dieser Artikel konzentriert sich auf den menschlichen Prozess.

Remote-Onboarding in einem 40-köpfigen Software-Unternehmen ist nicht dasselbe wie Remote-Onboarding in einer Einzelhandelskette. Die Unterschiede sind wichtig.

Die Zugangsberechtigung ist ein Sicherheitsereignis. Ein neuer Entwickler braucht Zugriff auf GitHub oder GitLab, AWS- oder GCP-Anmeldedaten, VPN-Konfiguration, SSO-Einrichtung und eine Einladung zum Passwort-Manager, oft schon vor Tag 1. Wenn das schiefgeht, sitzt der Entwickler 48 Stunden untätig herum, während IT-Tickets sich stapeln, oder schlimmer: Er bekommt zu viele Berechtigungen für Produktionsumgebungen, die er noch nicht berühren sollte.

Das Papierpaket ist anders. Generisches Onboarding konzentriert sich auf Arbeitsverträge und Steuerformulare. IT-Unternehmen brauchen in der Regel eine contractor NDA for software companies, eine IP assignment agreement for developers und manchmal eine separate software development agreement, besonders für Auftragnehmer. Diese Dokumente schützen Ihren Code und Ihr geistiges Eigentum ab Tag 1.

Die Kultur ist auf asynchrone Zusammenarbeit ausgerichtet. Laut dem GitLab Remote Playbook setzen hochleistungsfähige Remote-Engineering-Teams standardmäßig auf schriftliche Kommunikation, Überdokumentation und strukturierte async-Rituale. Ein neuer Entwickler, der Ihre async-Normen nicht versteht, wird entweder zu viele Slack-Nachrichten schicken oder schweigen. Beides ist schlecht. Ich habe selbst erlebt, wie ein neuer Entwickler zwei Wochen lang kaum Nachrichten geschrieben hat, weil er nicht wusste, wie oft Fragen erlaubt sind.

Der erste produktive Beitrag ist messbar. Time-to-first-commit und Time-to-first-PR sind konkrete Kennzahlen, die generische HR-Onboarding-Leitfäden nie erwähnen. Sie sollten Ihre primären Erfolgsindikatoren sein, nicht 'Wie hat sich der Mitarbeiter nach Tag 1 gefühlt'.

Ehrlich gesagt, behandeln die meisten allgemeinen Checklisten das IT-Onboarding so, als würden Sie einen neuen Mitarbeiter in der Debitorenbuchhaltung begrüßen. Die entwicklerspezifischen Lücken sind der Grund, warum dieser Artikel existiert.

Die Checkliste ist in vier Phasen organisiert. Jede Phase hat einen klaren Verantwortlichen (HR, IT oder der Hiring Manager). Arbeiten Sie sie der Reihe nach ab. Vorbereitungsschritte zu überspringen, um 'Zeit zu sparen', führt fast immer zu Problemen in Woche 1.

Vor dem ersten Arbeitstag (Pre-Boarding)

Diese Phase beginnt sobald das Angebot angenommen wird, nicht am ersten Tag. (Klingt selbstverständlich, aber ich habe schon gesehen, wie HR erst am Startdatum mit dem Papierkram begann.)

Papierpaket (HR-Verantwortlich, innerhalb von 48 Stunden nach Annahme des Angebots abschließen):

• Arbeitsvertrag oder Auftragnehmervertrag unterzeichnet und gegengezeichnet
• NDA über Dokumentenmanagement für IT-Unternehmen unterzeichnet. Der blockchain-verifizierte Prüfpfad garantiert Authentizität
• IP-Zessionvereinbarung unterzeichnet. Das schützt Ihren Code ab Tag 1
• Steuerdokumente ausgefüllt (W-9 für US-Auftragnehmer, entsprechende Formulare für Ihr Land)
• Hintergrundprüfung oder Referenzüberprüfung abgeschlossen
• Benefits-Anmeldeunterlagen versandt (bei Vollzeitmitarbeitern)

Nicht sicher, worin der Unterschied zwischen einem Vertrag und einer einfachen Vereinbarung besteht? Der Leitfaden Vertrag vs Vereinbarung erklärt, wann welcher Typ angebracht ist.

IT-Zugangsberechtigung (IT-Verantwortlich, 2–3 Werktage vor dem ersten Tag abschließen):

• Firmen-E-Mail und SSO-Konto erstellt
• Passwort-Manager-Einladung versandt (1Password, Bitwarden oder vergleichbar)
• VPN-Zugangskonfiguration eingerichtet. NIST SP 800-46 empfiehlt MFA für jeden Remote-Zugang
• GitHub- oder GitLab-Konto mit least-privilege-Zugang bereitgestellt (nur bestimmte Repos, nicht organisationweit)
• Cloud-Anmeldedaten mit korrekter IAM-Rolle eingerichtet (kein Produktionszugang am ersten Tag)
• Hardware versandt und Lieferung bestätigt (Laptop, Monitor, Peripherie)
• Kommunikationstools installiert: Slack oder Teams, Zoom, Loom
• Projektmanagement-Tool-Zugang: Jira, Linear oder vergleichbar

Vorablesung durch den Manager (3–5 Tage vor dem ersten Tag):

• Architektur-Überblick-Dokument oder README geteilt
• Engineering-Wiki- oder Confluence-Zugang gewährt
• Dokument zu den Arbeitsnormen des Teams (async-Stunden, PR-Review-Erwartungen, Meeting-Rhythmus)
• 30-60-90-Tage-Plan-Dokument im Voraus geteilt, damit der Neue es vor Tag 1 lesen kann
• Buddy zugewiesen und Vorstellung per E-Mail versandt

Tag 1 — Erste Eindrücke zählen

Tag 1 ist nicht der richtige Zeitpunkt für Informationsüberflutung. Es ist ein Tag zum Vertrauen aufbauen.

• Begrüßungs-Videoanruf: Manager + unmittelbares Team (unter 30 Minuten halten, die Leute sind nervös)
• Manager-1:1: Der 30-60-90-Plan wird ausdrücklich durchgegangen. Nicht davon ausgehen, dass er gelesen wurde.
• IT-Check: Alle Konten funktionieren, VPN-Verbindung steht, Dev-Tools installiert
• Dev-Umgebung-Setup-Session: Der Neue wird mit einem Senior Engineer gepaart für die Einrichtung (Docker, lokale Dev-Umgebung, IDE-Konfiguration). Nicht einfach Dokumente schicken und hoffen.
• Erstes Ticket zugewiesen: Ein kleines, gut abgegrenztes Issue mit dem Label 'good first issue' oder vergleichbar. Etwas, das in 1–2 Tagen abgeschlossen werden kann.
• Code-Review-Prozess erklärt: Branching-Strategie, Commit-Message-Konventionen, PR-Template
• Sicherheitstraining abgeschlossen: Phishing-Awareness, Datenhandhabungsrichtlinie, Acceptable-Use-Policy

Woche 1 — Einarbeitung

• Tech-Stack-Deep-Dive: Tag 1–2 Fokus auf Kommunikationstools, Tag 3–4 Fokus auf Codebasis-Orientierung
• Erstes Code-Review: Der Neue reviewed einen bestehenden PR, bevor er seinen eigenen schreibt. Das wird als Onboarding-Tool viel zu selten genutzt
• Pair-Programming-Session: Mindestens 2 Stunden mit einem Senior Engineer am ersten Ticket
• 1:1 mit dem Tech Lead: Architekturentscheidungen, technische Roadmap, aktuelle Sprint-Prioritäten
• Soziale Touchpoints: Informeller Kaffeeklatsch mit 2–3 Teammitgliedern (dies terminiert ausmachen, in Remote-Teams passiert das nicht von allein)
• Wochenend-Check-in mit dem Manager: Was ist unklar, was blockiert, was läuft gut

Erster Monat — Vom Onboarding zur Produktivität

• Erster PR innerhalb der ersten 5–7 Werktage gemerged. Das ist ein Meilenstein, nicht nur eine Aufgabe.
• 30-Tage-Review mit dem Manager: Leistung im Vergleich zum Plan, Zugangsberechtigungen angepasst, Kulturfragen beantwortet
• Zugangs-Audit: Alle temporären oder übermäßig gewährten Berechtigungen während der Einrichtung entfernen
• Dokumentationsbeitrag: Der Neue dokumentiert eine Sache, die er selbst herausfinden musste (eine wiederkehrende Onboarding-Schulden-Rückzahlungsgewohnheit)
• Kultur-Check: Fühlt sich asynce Kommunikation natürlich an? Besucht er die richtigen wiederkehrenden Meetings?
• Entwicklungsplan gestartet: Welche Fähigkeiten in Monat 2–3 aufbauen, Mentoring-Struktur bestätigt

30-60-90-Tage-Plan für IT-Einstellungen

Der 30-60-90-Plan gibt neuen Mitarbeitern explizite Ziele anstelle vager Einarbeitungserwartungen. Halten Sie ihn konkret.

Tag 1–30 (Lernen): Die Codebasis verstehen, 2–3 kleine Tickets abliefern, Sicherheitstraining abschließen, die async-Normen des Teams lernen. Erfolg = erster PR gemerged und Zugangs-Audit sauber.

Tag 31–60 (Beitragen): Ein Feature mittlerer Komplexität End-to-End übernehmen, aktiv an Code-Reviews teilnehmen, einen Bereich für Prozessverbesserung identifizieren. Erfolg = Feature auf Staging ausgeliefert.

Tag 61–90 (Treiben): Ein kleines Projekt oder einen Sprint leiten, eine Prozess- oder Tooling-Verbesserung vorschlagen, bei Senior-Level mit Mentoring beginnen. Erfolg = messbarer Beitrag zur Sprint-Velocity.

Der häufigste Onboarding-Fehler ist nicht ein fehlendes Checklisten-Element. Es ist, dass alle annehmen, jemand anderes kümmert sich darum. Diese Tabelle macht Verantwortlichkeiten explizit. Wenn zwei Personen für etwas zuständig sind, ist in Wahrheit keine von beiden zuständig.

Diese Fehler tauchen in Engineering-Teams wiederholt auf, die ansonsten gut laufen. Die meisten lassen sich mit einer einzigen Prozessänderung beheben.

1. 1.
   Zugangsberechtigung bis zum ersten Tag hinauszögern. Wenn Sie erst am Morgen des neuen Entwicklers Konten erstellen, verbringt er die erste Hälfte von Tag 1 damit, IT-Ticket-Warteschlangen zu beobachten. VPN, GitHub und SSO sollten 48 Stunden vor dem Startdatum bereit sein. Das ist die einzelne Maßnahme mit dem höchsten ROI.

1. 2.
   Zu viele Berechtigungen gewähren, um 'hilfreich zu sein'. Einem neuen Entwickler vollen Organisationszugang auf GitHub oder Admin-Rechte auf AWS zu geben, ist ein gut gemeinter Fehler. Das schafft Sicherheitsrisiken und macht es ironischerweise schwieriger, die richtigen Dinge zu finden. Least-privilege-Zugang mit einem dokumentierten Eskalationspfad ist für alle besser. NIST SP 800-63 empfiehlt rollenbasierte Zugriffskontrolle ab Tag 1.

1. 3.
   Das Papierpaket vor Arbeitsbeginn überspringen. Sie wollen nicht, dass ein Entwickler Code schreibt, bevor die IP-Zessionvereinbarung unterschrieben ist. Das ist keine Paranoia — es ist ein echtes IP-Eigentumsrisiko. Erledigen Sie das Papierpaket (NDA, IP-Zession, Arbeits- oder Auftragnehmervertrag) vor dem ersten Commit, nicht danach. Sie können das alles digital abwickeln mit E-Signatur- und Vertragsmanagement für IT-Teams.

1. 4.
   Dokumentation ohne Session schicken. 'Hier ist unser 80-seitiges Wiki' ist kein Onboarding. Einen neuen Entwickler 45 Minuten durch die Architektur zu führen und dann auf die Dokumente zu verweisen, funktioniert. Asynchrone Dokumentation dient der Referenz. Sie ersetzt keine synchrone Orientierung.

1. 5.
   Kein erster-PR-Meilenstein. Der erste gemergte PR ist der psychologische Wendepunkt im Remote-Onboarding. Entwickler, die bis Tag 7 noch nichts ausgeliefert haben, fühlen sich wie Gäste statt wie Teammitglieder. Bauen Sie es explizit in den Plan ein: ein gut abgegrenztes Ticket, eine Pairing-Session, ein zeitnahes Code-Review.

1. 6.
   Das Zugangs-Audit nach 30 Tagen überspringen. Temporäre Zugangsberechtigungen häufen sich. Der neue Entwickler bekommt temporären Admin-Zugang für eine bestimmte Aufgabe, und niemand entfernt ihn. Führen Sie ein formelles Zugangs-Audit nach 30 Tagen und erneut nach 90 Tagen durch. Es dauert 20 Minuten und schließt eine echte Sicherheitslücke.

Laut SHRM-Forschung verzeichnen Organisationen mit strukturierten Onboarding-Programmen um 50 % höhre Neueinstellungs-Retention. In der IT ist diese Lücke noch teurer: Der Ersatz eines Mid-Level-Engineers kostet 50–200 % des Jahresgehalts.

Die meisten Unternehmen messen Onboarding-Erfolg mit einer 30-Tage-Zufriedenheitsumfrage. Das ist besser als nichts, aber nicht genug. Hier sind die Kennzahlen, die Ihnen wirklich sagen, ob das Onboarding funktioniert.

Time-to-first-commit. Wie viele Kalendertage vom Startdatum bis zum ersten Code-Commit? Für erfahrene Entwickler sollten das 2–3 Tage sein. Wenn es länger dauert, ist Ihr Dev-Umgebung-Setup-Prozess kaputt.

Time-to-first-PR. Wie lange dauert es, bis der erste Pull Request eingereicht und gemergt wird? Ziel: 5–7 Werktage. Entwickler, die bis Tag 10 noch nichts ausgeliefert haben, berichten typischerweise, dass sie sich isoliert und unproduktiv fühlen.

30-Tage-Retention-Rate. Welcher Prozentsatz neuer Einstellungen ist nach 30 Tagen noch im Unternehmen? Frühe Abwanderung in der Tech-Branche ist oft ein Onboarding-Fehler, kein Hiring-Fehler. Beobachten Sie das nach Kohorten.

Zugangs-Audit-Clean-Rate. Beim 30-Tage-Zugangs-Audit: Welcher Prozentsatz der Konten hat null übermäßig gewährte Berechtigungen? Das ist sowohl eine Sicherheits- als auch eine Onboarding-Qualitätskennzahl. Überberechtigung bedeutet, dass die Bereitstellung nicht sorgfältig erfolgte.

Schulungsabschluss-Rate. Hat der neue Mitarbeiter bis Ende Woche 2 das Sicherheitsbewusstseins-Training, das Code-Review-Prozess-Training und jedes erforderliche Compliance-Training abgeschlossen? Unvollständige Schulungen schaffen Risiken und deuten auf einen Prozessmangel hin.

Manager-berichtete Produktivität. Eine strukturierte Frage beim 30-Tage-Review: 'Auf einer Skala von 1–5, wie produktiv ist diese Person im Verhältnis zu den Erwartungen?' Aggregieren Sie das über alle Einstellungen, um systemische Onboarding-Probleme zu erkennen.

Der Buffer State of Remote Work Report zeigt konsistent, dass sich vom Team isoliert zu fühlen die größte Herausforderung für Remote-Arbeiter ist. Diese Kennzahlen helfen Ihnen, das früh zu erkennen, bevor es zu einer Kündigung wird.

Sie brauchen kein dediziertes Onboarding-Produkt. Die meisten IT-Unternehmen haben bereits alles, was sie brauchen. Die Lücke ist in der Regel der Prozess, nicht das Tooling. Das sollte der Stack jedoch abdecken.

Identitäts- und Zugangsmanagement. Okta, JumpCloud oder Google Workspace für SSO. Ein Passwort-Manager (1Password Teams, Bitwarden Business) für Anmeldedaten, die kein SSO nutzen. MFA für alles: Hardware-Tokens für Admin-Konten, Authenticator-Apps für Standard-Zugang.

Kommunikation. Slack oder Microsoft Teams für asynchrone Nachrichten. Zoom oder Google Meet für synchrone Videoanrufe. Loom für Erklärvideos (nützlich für Architektur-Orientierungen. Einmal aufzeichnen, für jeden neuen Mitarbeiter wiederverwenden).

Projektmanagement und Dokumentation. Jira oder Linear für Sprint-Arbeit, Confluence oder Notion für Dokumentation. Das Engineering-Wiki ist wahrscheinlich das am stärksten unterinvestierte Onboarding-Ressource in den meisten Teams.

Dev-Umgebung. Docker für reproduzierbare lokale Umgebungen. Ein dokumentiertes Einrichtungsskript, das tatsächlich funktioniert (quartalsweise auf einer frischen Maschine testen). GitHub oder GitLab für Versionskontrolle, mit Branch-Protection-Regeln, die vor dem ersten PR des neuen Mitarbeiters gesetzt sind.

Dokumentenunterzeichnung und Verträge. Hier nutzen viele IT-Unternehmen immer noch per E-Mail verschickte PDFs und hoffen auf das Beste. Für NDA-Unterzeichnung, IP-Zessionvereinbarungen und Arbeitsverträge brauchen Sie E-Signatur- und Vertragsmanagement für IT-Teams, mit Blockchain-Verifizierung, zeitgestempelten Prüfpfaden und der Möglichkeit, ein komplettes Papierpaket in einem einzigen Arbeitsablauf statt in drei separaten E-Mail-Threads zu versenden.

Das Ziel ist nicht, Tools hinzuzufügen. Stellen Sie sicher, dass jedes Tool im Stack einen klaren Verantwortlichen hat und vor dem ersten Tag des neuen Mitarbeiters eingerichtet ist.