Rollen in der Softwareentwicklung
Rollen sind keine Titel.
Sie definieren:
- Entscheidungsrechte
- Verantwortlichkeiten
- Qualitätsverantwortung
- Eskalationspfade
Unklare Rollen erzeugen:
- implizite Architektur
- doppelte Verantwortung
- Verantwortungsdiffusion
- politische Entscheidungen
- Reibung zwischen Teams
Diese Übersicht ist bewusst pragmatisch:
Wer entscheidet was?
Wer trägt welches Risiko?
Wer darf Nein sagen?
1. Technische Rollen
Technische Rollen tragen Verantwortung für:
- Struktur
- Qualität
- langfristige Wartbarkeit
- technische Risiken
Sie entscheiden über das Wie der Umsetzung.
Software Architect
Verantwortet:
- langfristige Systemstruktur
- Architekturprinzipien
- Kontextabgrenzung
- konzeptionelle Integrität
Fokus: Nachhaltigkeit über Zeit.
Solution Architect
Verantwortet:
- End-to-End-Systemdesign
- Integrationen
- Systemgrenzen
- technische Machbarkeit über mehrere Systeme
Fokus: Gesamtlösung.
Tech Lead
Verantwortet:
- technische Führung im Team
- Umsetzungsqualität
- Schuldenmanagement
- Review-Standards
- Architektur wirksam machen
Fokus: Delivery + Qualität im Alltag.
Principal Engineer
Verantwortet:
- systemübergreifende technische Richtung
- strategische Architekturentscheidungen
- technische Standards
Fokus: Einfluss über mehrere Teams hinweg.
Entwickler-Level (Junior, Mid, Senior)
Unterschied liegt nicht nur in Erfahrung, sondern in:
- Entscheidungsfähigkeit
- Risikoerkennung
- Ownership
- Teamwirkung
Test Engineer
Verantwortet:
- Teststrategie
- kritische Flows
- Integration & E2E
- Reproduzierbarkeit
Nicht: „am Ende testen“.
DevOps Engineer
Verantwortet:
- CI/CD
- Deployment-Stabilität
- Observability
- Infrastruktur-Automatisierung
Nicht: „Ticket-Abarbeitung für Server“.
Platform Engineer
Verantwortet:
- interne Plattform
- Self-Service
- Standards
- Reduktion kognitiver Last
Fokus: Enablement.
Site Reliability Engineer (SRE)
Verantwortet:
- SLOs
- Incident-Prozesse
- Error Budgets
- Systemresilienz
Fokus: Zuverlässigkeit als Produktmerkmal.
→ SRE
Security Engineer / AppSec
Verantwortet:
- Risikoanalyse
- Threat Modeling
- Security-Gates
- Nachweisbarkeit
Fokus: Risikominimierung, nicht Angstkultur.
2. Wert- und Organisationsrollen
Diese Rollen steuern Richtung, Prioritäten und Rahmenbedingungen.
Sie entscheiden über das Was und das Warum.
Product Manager (PM)
Verantwortet:
- Produktstrategie
- Marktverständnis
- langfristige Roadmap
Fokus: Warum bauen wir das?
Product Owner (PO)
Verantwortet:
- Priorisierung
- Backlog
- Akzeptanzkriterien
- Scope-Stabilität
Fokus: Lieferbarer Wert.
Business Analyst
Verantwortet:
- fachliche Klarheit
- Prozessmodellierung
- strukturierte Anforderungen
UX/UI Designer
Verantwortet:
- Nutzererlebnis
- Flows
- Usability
- Design-System
QA Manager
Verantwortet:
- Qualitätsziele
- Metriken
- Prozess-Standards
- Nachweisbarkeit
Fokus: Qualität als System.
Engineering Manager
Verantwortet:
- Team-Performance
- Organisationsentwicklung
- Kapazitätsplanung
- langfristige Lieferfähigkeit
Nicht: technische Detailentscheidungen.
Scrum Master / Agile Coach
Verantwortet:
- Prozessqualität
- Moderation
- Impediment-Management
- Organisationslernen
Nicht: Projektmanagement-Ersatz.
Teamleiter (disziplinarisch)
Verantwortet:
- Personalführung
- Entwicklungsgespräche
- organisatorische Stabilität
Wichtig:
Fachliche Autorität ≠ disziplinarische Autorität.
3. Wo Rollen typischerweise kollidieren
Konflikte sind strukturell – nicht persönlich.
PO/PM vs. Tech Lead
„Wann?“ vs. „Wie stabil?“
Architect vs. Delivery
Langfristige Integrität vs. kurzfristiger Druck.
QA vs. Feature-Teams
Systematische Qualität vs. Time-to-Market.
Security vs. Business
Risikominimierung vs. Wachstum.
Teamleiter vs. Engineering
Formale Führung vs. fachliche Autorität.
Reibung ist normal.
Unklare Entscheidungsrechte sind problematisch.
4. Quick Check für Teams
- Wer trifft Architekturentscheidungen wirklich?
- Wer trägt Verantwortung für technische Schulden?
- Wer darf Qualität gegen Zeit priorisieren?
- Wer hat Veto-Recht bei Security?
- Wer besitzt kritische Systemkomponenten?
- Wer entscheidet bei Zielkonflikten?
Wenn diese Fragen unklar sind,
entstehen fast immer:
- Eskalationen
- Verzögerungen
- implizite Architektur
- Qualitätsprobleme
Kerngedanke
Rollen sind kein Organigramm.
Sie sind ein Entscheidungsmodell.
Wenn Rollen klar sind, entsteht Struktur.
Wenn sie unklar sind, entsteht Reibung.
Und Reibung wird immer im System sichtbar.