Arbeiten ohne Projektmanager: Warum wir bei mindmatters auf kollegiale Projektführung setzen
Bei mindmatters gibt es keine Projektmanager, Projektleiter, Tech Leads oder ähnliche klassische Führungsrollen. Was auf den ersten Blick vielleicht ungewöhnlich erscheint, ist bei uns Teil eines bewussten Organisationsprinzips: Wir arbeiten kollegial und ohne formelle Hierarchien – auch in Projekten.
Das hat natürlich Auswirkungen auf die Zusammenarbeit mit unseren Kunden. Welche das sind, welche Vorteile und Herausforderungen entstehen und wie wir trotzdem strukturiert vorgehen – genau darum geht’s hier.
Wenn du lieber liest, geht’s hier weiter mit dem Blogbeitrag.
Unser Führungsverständnis: Führung ≠ Führungskräfte
Wir sehen Führung als Interessenausgleich – zwischen den Bedürfnissen des Unternehmens, der Kolleg:innen und natürlich unserer Kunden. Damit das funktioniert, braucht es jede Menge Führungsarbeit: Ziele definieren, Feedback geben, Strukturen schaffen, Motivation fördern u.v.m..
Aber – und das ist der Knackpunkt – diese Führungsarbeit übernehmen bei uns nicht einzelne Führungskräfte, sondern alle im Team. Unsere Devise lautet: Führungsarbeit statt Führungskräfte.
Daher wäre es widersprüchlich, in den Projekten plötzlich klassische Projektrollen einzuführen. Das passt einfach nicht zu unserer Art zu arbeiten.
Orientierung am Scrum Framework
Ein weiterer Grund, warum wir keine Projektmanager einsetzen, ist unser methodischer Rahmen: Wir orientieren uns am Scrum Framework – zumindest in der Anfangsphase eines Projekts.
Warum Scrum? Unsere Projekte bewegen sich meist im komplexen Umfeld. Unsere Kunden kommen mit offenen Fragestellungen, ungelösten Problemen oder der Vision für eine maßgeschneiderte Software, deren Anforderungen sich erst im Lauf des Projekts konkretisieren. Scrum hilft uns, flexibel und fokussiert zu bleiben.
Im Scrum Guide gibt es keine Projektmanagerrolle – und auch bei uns wird diese Rolle nicht künstlich „dazuerfunden“.
Welche Rollen gibt es stattdessen?
In unseren Projekten setzen wir auf ein reduziertes, aber wirkungsvolles Rollenset:
- Product Owner (von Kundenseite): Verantwortlich für die Produktvision und die Priorisierung der Anforderungen
- Entwicklungsteam: Mindestens zwei Entwickler:innen, die im Pair arbeiten
- UX-Designende: 1–2 Personen, um die Nutzerperspektive von Anfang an mitzudenken
- Prozessbegleitung: Vergleichbar mit dem Scrum Master, aber framework-unabhängig gedacht
Die Rolle der Prozessbegleitung
Die Prozessbegleitung (bei Scrum wäre das der Scrum Master) unterstützt das Team – insbesondere den Product Owner – bei der Selbstorganisation, der Prozessgestaltung und der methodischen Arbeit.
Diese Rolle ist nicht disziplinarisch. Sie hilft bei:
- der Moderation von Terminen
- der Umsetzung bewährter Prozesse
- dem Umgang mit Tools wie Jira
- der Bereitstellung von Metriken zur besseren Entscheidungsfindung
- der Kommunikation zwischen Kunde und Team
Man könnte sagen: Die Prozessbegleitung in der kollegialen Projektführung ist so etwas wie die unsichtbare Hausmeisterrolle, die alles am Laufen hält, ohne im Rampenlicht zu stehen.
Vorteile: Warum Product Owner statt Projektmanager?
Wir sehen in dieser Aufstellung mehrere handfeste Vorteile:
1. Direkte Steuerung statt Umwege
Der Product Owner arbeitet direkt mit dem Team zusammen – ohne Umwege über einen Projektmanager. Das ermöglicht schnelle Entscheidungen, täglichen Austausch (z. B. im Daily) und eine enge Abstimmung über den Stand der Entwicklung.
2. Mehr Identifikation, mehr Motivation
Durch den engen Austausch entsteht ein echtes Wir-Gefühl. Das Team fühlt mit, wenn es ein Problem löst oder ein neues Feature entwickelt. Diese emotionale Bindung zum Produkt ist Gold wert.
3. Geringere Kosten
Ohne Projektmanager entfallen Doppelabstimmungen und zusätzliche Stundensätze. Die Prozessbegleitung braucht in der Regel nur einen Tag pro Woche, was in den meisten Fällen deutlich günstiger ist.
4. Fokus auf den Nutzen für User
Ein Product Owner hat den Fokus auf den tatsächlichen Nutzen für die Anwender:innen. Ein klassischer Projektmanager ist häufig eher mit Terminen, Budgets und Prozessen beschäftigt. Für uns zählt: Was bringt den Nutzer:innen wirklich Mehrwert?
5. Echtzeit-Abstimmungen statt Review-Marathon
Unsere Product Owner nehmen jedes Feature selbst ab. Sie sind laufend im Bilde, was gebaut wird, und können jederzeit Feedback geben. Das sorgt für kontinuierliche Qualitätssicherung und schnelleres Lernen.
Herausforderungen: Was ohne Projektmanager schwierig sein kann
Natürlich ist diese Form der Zusammenarbeit nicht immer einfach – vor allem für Unternehmen, die klassisch organisiert sind. Hier ein paar typische Herausforderungen:
1. Offene Kommunikation will gelernt sein
Als Kunde direkt mit einem fremden Entwicklerteam zu kommunizieren, ist für viele ungewohnt. Vor allem, wenn man aus einer „Auftraggeber-Dienstleister“-Denke kommt.
2. Produktverantwortung bleibt beim Kunden
Eine Vision lässt sich nicht outsourcen. Der Kunde bleibt verantwortlich für den Erfolg des Produkts – auch wenn wir bestmöglich bei der technischen Umsetzung helfen.
3. Führungs-Skills beim Product Owner
Ein Product Owner braucht gewisse Führungsfähigkeiten – z. B. um Konflikte wertschätzend anzugehen oder Entscheidungen im Sinne der Vision zu treffen. Dabei helfen wir natürlich, aber die Verantwortung bleibt.
4. Agile Arbeitsweise ist nicht selbstverständlich
Viele unserer Kunden kennen aus ihrem Alltag ganz andere Projektstrukturen. Die agile Herangehensweise erfordert ein Umdenken – Offenheit vorausgesetzt.
5. Zeitaufwand darf nicht unterschätzt werden
Die Rolle des Product Owners kostet Zeit – für Meetings, Entscheidungen, Feedbackschleifen. Wer hier zu knapp plant, bremst das Projekt aus. Und Zeit ist in der Softwareentwicklung eben auch Geld.
Fazit: Ohne Projektmanager, aber mit Haltung
Unsere Erfahrung zeigt: Selbstorganisierte Teams brauchen keine klassischen Projektmanager, um erfolgreich zu sein. Viel wichtiger ist die enge Zusammenarbeit, eine klare Rollenverteilung und der Fokus auf das Produkt.
Wir glauben nicht, dass Projektmanager magische Fähigkeiten besitzen, um Probleme schneller zu lösen. Stattdessen setzen wir auf Verantwortung teilen statt delegieren.
Mit der richtigen Begleitung, einem motivierten Team und echtem Interesse am Erfolg funktioniert das wunderbar – auch für Kunden ohne eigene Softwareabteilung.
Ihr möchtet auch Projekte mit klarer Rollenverteilung, Fokus auf das Produkt und eine enge kollegiale Zusammenarbeit?
Wir freuen uns auf den Austausch.