Onboarding skaliert nicht
Jeder neue Engineer braucht einen Buddy. Der Buddy verliert 30-50% seiner Produktivität. Bei 10 Hires pro Jahr ist das ein Vollzeit-Job, der nie auf dem Organigramm auftaucht.
Engineering-Team skalieren: Onboarding, IDP und Wissenstransfer ohne Reibungsverluste.
Neuer Engineer braucht 3 Wochen bis zur ersten produktiven Zeile? Das ist kein Personalproblem – das ist ein Systemproblem. Wir bauen Self-Service-Infrastruktur, automatisches Provisioning und Onboarding-Prozesse, die mit dem Team skalieren.
- Onboarding: von 3 Wochen auf 3 Tage durch Automatisierung.
- Internal Developer Platform: Self-Service statt Ops-Ticket.
- Wissenssilos aufgelöst: Systeme statt Köpfe tragen das Wissen.
Was drei Wochen Onboarding euch kostet
Konkretes Rechenbeispiel für ein 50-Engineer-Team.
- 10 Hires pro Jahr × 3 Wochen = 30 Wochen verschwendete Senior-Zeit
- Jeder neue Engineer bringt die erste Woche keine Produktivität
- Wissenssilos: wenn 3 Personen gehen, bricht Betrieb zusammen
Diese Probleme kommen automatisch wenn Teams wachsen
Sie verschwinden nicht von selbst – und mehr Engineers einzustellen macht sie zunächst sogar größer.
Ops ist der Flaschenhals
Entwickler brauchen eine neue Umgebung, einen Datenbankzugriff, ein SSL-Zertifikat. Ops hat ein Ticket-System, das täglich wächst. Alle warten aufeinander.
Wissen sitzt bei Einzelpersonen
Der Senior der alles weiß. Wenn der im Urlaub ist, steht das Team. Wenn er geht, ist das Wissen weg. Kein System, keine Dokumentation, keine Runbooks – nur Köpfe.
Systeme, die mit dem Team skalieren
Automatisierung ersetzt nicht Menschen – sie ermöglicht, dass Menschen das Richtige tun.
Automatisiertes Onboarding
Neuer Engineer kommt am Montag: bis Dienstag hat er lokale Umgebung, Zugänge, Repo-Zugang und erste PR-Erfahrung. Ohne Buddy, ohne Ticket.
- Self-Service Developer-Environment mit Devcontainer
- Automatisiertes Provisioning von Zugängen und Tools
- Onboarding-Runbook als ausführbarer Code
Internal Developer Platform (IDP)
Self-Service für Entwickler: neue Umgebungen auf Knopfdruck, Deployments selbst triggern, Logs selbst einsehen. Ops konfiguriert einmal – alle nutzen es selbst.
- Backstage als Developer Portal (optional)
- Self-Service Kubernetes Namespaces
- Automatisiertes Environment-Provisioning
Wissenstransfer & Runbooks
Wissen aus Köpfen in Systeme bringen: Runbooks als Code, automatisierte Diagnose-Workflows, Incident-Playbooks und On-Call-Rotation die das Team verteilt.
- Runbooks als ausführbarer Code (nicht Word-Dokumente)
- On-Call-Rotation mit klaren Eskalationswegen
- Architecture Decision Records (ADRs) im Repo
Fragen zu Engineering-Team skalieren
- Warum wird Onboarding teurer je größer das Team?
- Weil Wissen in Köpfen steckt, nicht in Systemen. Jeder neue Engineer lernt von einem bestehenden – der dafür keine Features baut. Ohne Self-Service skaliert Onboarding linear mit dem Team.
- Was ist eine Internal Developer Platform?
- Ein Self-Service-Layer über eurer Infrastruktur: Entwickler bekommen neue Umgebungen, können Deployments triggern und Logs einsehen – ohne auf Ops zu warten. Ops konfiguriert einmal, alle nutzen selbst.
- Ab wann lohnt sich eine IDP?
- Ab ~20–30 Entwicklern spürt man den Engpass. Ab 50 Engineers wird es ohne IDP zum Wachstumshindernis. Wir bauen MVP-IDPs, die mit eurem Team skalieren.
- Wie löst man Wissenssilos auf?
- Durch Systeme statt Personen: Runbooks als Code, Infrastructure as Code, automatisiertes Onboarding und On-Call-Rotationen. Wissen sitzt im System, nicht nur in einem Kopf.
Onboarding und Wissenssilos lösen?
Assessment anfragen – wir analysieren eure aktuelle Team-Infrastruktur und zeigen, was typischerweise in 10 Arbeitstagen möglich ist.