Tech-Team aufbauen und skalieren

Mit 3 Entwicklern funktioniert alles informell. Bei 10 wird es chaotisch. Bei 20 bricht es zusammen. Wenn Sie nicht rechtzeitig strukturieren.

Hier ist der Playbook für skalierbares Team-Wachstum.

Die 3 kritischen Schwellen

Schwelle 1: 3-7 Entwickler (Informalität funktioniert noch)

Struktur: Flat, jeder kennt jeden, keine festen Rollen.

Kommunikation: Ad-hoc, Slack, gelegentliche Stand-ups.

Entscheidungen: Gemeinsam oder durch Tech-Lead.

Bottleneck: Tech-Lead wird zum Blocker bei >5 Leuten.

Schwelle 2: 8-15 Entwickler (Struktur wird nötig)

Struktur: Teams bilden sich, erste feste Rollen (Frontend, Backend, DevOps).

Kommunikation: Strukturierte Meetings werden nötig, nicht jeder kennt mehr alles.

Entscheidungen: Nicht mehr im Plenum machbar.

Bottleneck: Unklare Verantwortlichkeiten, "Wer macht was?"-Chaos.

Schwelle 3: 16-25 Entwickler (Organisation ist Pflicht)

Struktur: Mehrere Teams mit klaren Bereichen, dedizierte Leads.

Kommunikation: Formale Prozesse, Dokumentation wird kritisch.

Entscheidungen: Delegation nötig, nicht alles kann zentral entschieden werden.

Bottleneck: Silos entstehen, Teams arbeiten aneinander vorbei.

Mein Tipp aus der Praxis: Die Schwelle zwischen 7 und 10 Entwicklern ist die gefährlichste. In einem Mandat dachte das Startup, sie könnten ihre informelle Kultur einfach weiterleben. Bei 12 Leuten brach das Chaos aus: unklare Verantwortlichkeiten, doppelte Arbeit, frustrierte Entwickler. Die Lösung: Wir haben sofort Team-Leads eingesetzt und Domain-Teams gebildet. Innerhalb von 4 Wochen war die Produktivität wieder da. Die Lektion: Strukturieren Sie proaktiv, nicht reaktiv.

Phase 1: Foundation (0-7 Entwickler)

Hiring-Fokus: Generalists über Specialists

Warum: Bei <7 Leuten brauchen Sie Leute, die alles können.

Red Flags beim Hiring:

• "Ich bin React-Entwickler, Backend mache ich nicht"
• Braucht perfekte Specs vor dem Start
• Kann nicht selbstständig Entscheidungen treffen

Green Flags:

• "Ich lerne, was nötig ist"
• Fragt nach Business-Context, nicht nur nach Tech-Stack
• Hat schonmal in kleinen Teams gearbeitet

Onboarding-Basics (Tag 1)

Minimum Viable Onboarding:

1. Lokales Dev-Environment in <2 Stunden
2. Code-Walkthrough mit Team (1-2 Stunden)
3. Erste kleine Task noch am ersten Tag deployen

Dokumentation:

• README.md mit Setup-Anleitung
• Architecture-Overview (1 Seite reicht)
• "How we work"-Doc (Workflow, Conventions)

Investment: 1 Tag pro neuem Developer.

Prozesse: Minimal, aber existent

Required:

• Code-Reviews (mindestens 1 Approve vor Merge)
• Main-Branch-Protection (kein direktes Push)
• Daily Standup (15 Min, async ist OK)
• Sprint-Planung alle 2 Wochen

Nice-to-have (kommt später):

• Retros
• Pair-Programming-Sessions
• Tech-Talks

Phase 2: Struktur (8-15 Entwickler)

Team-Strukturierung: Skill-based vs. Domain-based

Option A: Skill-based (einfacher, aber gefährlich):

Frontend-Team (3 Leute)
Backend-Team (4 Leute)
DevOps (2 Leute)

Problem: Features brauchen alle Teams →viele Abhängigkeiten.

Option B: Domain-based (besser für Scale):

Team 1: User Management & Auth (4 Leute: 2 FE, 2 BE)
Team 2: Core Product Features (4 Leute: 2 FE, 1 BE, 1 Fullstack)
Team 3: Analytics & Reporting (3 Leute: 1 FE, 2 BE)
Platform/DevOps: Shared (2 Leute)

Vorteil: Autonome Teams, End-to-End-Ownership.

Faustregel: Ab 8 Entwicklern →Domain-based Teams.

Rollen einführen (nicht zu früh!)

Ab 8 Entwickler:

• Team-Leads (1 pro Team): Technische Führung, kein People-Management (noch)
• Tech-Lead (gesamt): Übergreifende Architektur, Standards

Ab 12 Entwickler:

• Engineering Manager: People-Management (1-on-1s, Entwicklung, Hiring)
• Trennung: Tech-Lead = Technology, EM = People

Fehler: Zu früh zu viele Rollen →Overhead ohne Nutzen.

Hiring-Fokus: Ergänzende Spezialisierung

Jetzt ist der richtige Zeitpunkt für Specialists:

• Dedizierter DevOps-Engineer (wenn nicht schon da)
• Senior-Frontend/Backend mit Mentoring-Fähigkeiten
• First Security-focused Engineer (wenn B2B/Enterprise)

Ratio: ~70% Generalisten, 30% Spezialisten.

Onboarding skalieren: Buddy-System

Setup:

• Jeder neue Dev bekommt einen Buddy (erfahrenes Team-Member)
• Buddy = First Point of Contact für 2 Wochen
• Checklist: Tag 1, Tag 3, Woche 1, Woche 2, Woche 4

Beispiel-Checklist:

Tag 1:
- [ ] Environment Setup
- [ ] Erste Code-Change deployed

Woche 1:
- [ ] Team-Intro-Meetings
- [ ] Architektur-Walkthrough
- [ ] Erstes Feature-Ticket abgeschlossen

Woche 2:
- [ ] Code-Review gegeben
- [ ] Pair-Programming-Session
- [ ] Feedback-Gespräch mit Buddy

Woche 4:
- [ ] Selbstständiges Feature delivered
- [ ] Onboarding-Feedback-Session

Investment: 4-8 Stunden pro Buddy, aber deutlich schneller productive.

Prozesse: Dokumentation wird kritisch

Ab 10 Entwicklern:

• Nicht mehr jeder kennt alles
• Wissen muss dokumentiert sein
• Onboarding ohne Documentation = unmöglich

Minimum-Dokumentation:

• Architecture Decision Records (ADRs)
• API-Dokumentation (automatisiert, z.B. OpenAPI)
• Runbooks für kritische Prozesse (Deployment, Incident-Response)
• RFCs für größere Änderungen (optional, aber empfohlen)

Tool-Tipp: Notion, Confluence, oder einfach Markdown im Repo.

Phase 3: Organisation (16-25 Entwickler)

Multi-Team-Koordination: Die Conway-Law-Falle

Conway's Law: "Organisations design systems that mirror their communication structure."

Gefahr: Teams bauen Silos →Software wird Monolith oder chaotisches Micro-Service-Chaos.

Gegenmittel:

1. Shared Tech-Council (wöchentlich):

• 1 Vertreter pro Team + CTO/Tech-Lead
• Diskussion übergreifender Themen
• Architektur-Entscheidungen, Standards
• Kein Micro-Management, nur strategic stuff

2. Inner-Source-Kultur:

• Jedes Team kann in anderen Repos beitragen
• Cross-Team-Code-Reviews
• Shared Libraries & Services

3. Rotation-Programme (optional):

• Entwickler wechseln für 1-2 Monate in andere Teams
• Wissenstransfer, Silo-Prävention

Hiring-Fokus: Seniors + Culture Fit

Ab 15 Entwicklern:

• Sie brauchen mehr Seniors (Ratio 1:3 Senior:Junior ist gesund)
• Seniors mentoren, treiben Standards, lösen komplexe Probleme

Culture Fit wird kritisch:

• Bei <10 Leuten kann man "problematische" Personen aushalten
• Bei 20 Leuten: Toxische Kultur breitet sich schnell aus
• Lieber länger suchen als falschen Hire

Red Flags (Culture):

• "Rockstar Developer"-Attitüde
• Nicht teamfähig, sieht andere als inkompetent
• Keine Feedback-Fähigkeit

Prozesse: Engineering-Management einführen

Entwickler brauchen:

• Career-Development-Gespräche (quarterly)
• 1-on-1s (bi-weekly)
• Performance-Reviews (half-yearly)
• Gehalts-/Beförderungs-Transparenz

Ohne Engineering Manager: CTO macht alles →Bottleneck.

Mit Engineering Manager: CTO fokussiert auf Strategie, EM auf People.

Ratio: 1 Engineering Manager pro 6-8 Entwickler.

Die häufigsten Fehler beim Skalieren

Fehler 1: Zu spät anfangen zu strukturieren

Symptom: Bei 15 Leuten immer noch "wir regeln alles ad-hoc".

Resultat: Chaos, Burnout, Entwickler kündigen.

Fix: Spätestens bei 8 Entwicklern: Teams + Leads + Prozesse einführen.

Fehler 2: Zu viel Prozess zu früh

Symptom: Bei 5 Leuten schon Scrum Master, Daily Stand-ups, Retros, Planning-Poker.

Resultat: Overhead, Frustration, "Prozess statt Arbeit".

Fix: Lean starten, iterativ erweitern.

Fehler 3: Hiring ohne klare Bar

Symptom: "Wir brauchen jemanden, egal wen".

Resultat: Schlechte Hires, Tech Debt durch inkompetente Entwickler, Team-Frust.

Fix: Lieber langsamer wachsen mit guten Leuten als schnell mit schlechten.

Fehler 4: Keine Dokumentation

Symptom: "Alles ist im Kopf von Max".

Resultat: Max kündigt, Wissen ist weg.

Fix: Ab 10 Entwicklern: Documentation is not optional.

Fehler 5: Founders mikromanagen weiter

Symptom: CEO/CTO entscheidet jedes Tech-Detail, auch bei 20 Entwicklern.

Resultat: Bottleneck, Entwickler sind frustriert, keine Ownership.

Fix: Delegation. Trust your Leads.

Die Team-Skalierungs-Checklist

Bei 5 Entwicklern:

• Code-Review-Prozess etabliert
• Basic Onboarding-Dokumentation
• Daily Standup (oder Async-Equivalent)

Bei 10 Entwicklern:

• Teams gebildet (Domain-based empfohlen)
• Team-Leads ernannt
• Buddy-System für Onboarding
• Architecture-Dokumentation vorhanden

Bei 15 Entwicklern:

• Engineering Manager eingestellt
• Tech-Council etabliert
• 1-on-1-Prozess läuft
• Inner-Source-Kultur gelebt

Bei 20 Entwicklern:

• Mehrere autonome Teams
• Dedizierte Leads pro Team
• Career-Development-Framework
• Performance-Review-Prozess

Fazit: Struktur folgt Wachstum

Team-Skalierung ist keine Rocket Science. Es ist:

1. Timing: Prozesse einführen, bevor das Chaos kommt
2. Balance: Nicht zu viel, nicht zu wenig Struktur
3. People First: Gute Hires > schnelle Hires

Die Regel: Struktur sollte ermöglichen, nicht bremsen.

Wenn Ihr Team jammert "zu viele Meetings, zu viel Prozess" →wahrscheinlich zu viel.

Wenn keiner weiß, wer was macht →wahrscheinlich zu wenig.

Finden Sie die Balance. Iterieren Sie.