Die Organisationsform unseres Unternehmens

Keine mahagoni-getäfelten Chef-Büros, keine Befehle von oben, keine unklaren Verantwortlichkeiten: Jedes Teammitglied trägt Eigenverantwortung und hat Entscheidungsfreiheit.

Letzte Änderung: April 2025
Autor*innen: Isabel Birnstingl | Sven Schweiger

Wie wir zu unserer Organisationsform kamen

Wir sind ein Unternehmen, das Custom Software für Kunden aus vielen Branchen umsetzt. Rund um diese sehr unterschiedlichen Projekte dreht sich bei uns alles: Die Planung, die Umsetzung und die Gewinnung neuer Aufträge. Und rund um diese Projekte hat sich auch unsere Organisation entwickelt, die auf Eigenverantwortung und Entscheidungsfreiheit setzt (siehe dazu auch das Gesetz nach Conway!).

Die Struktur, die wir jetzt leben, gab es nicht von Anfang an. Drehen wir also die Zeit um ein paar Jahre zurück und sehen uns die CSS der Frühzeit an!

Damals war die Organisation unseres Unternehmens rein projektorientiert: Unsere Softwareentwickler wurden pro Projekt zu temporären Teams zusammengestellt, die sich nach Projektende wieder auflösten. Ein Projekt konnte jede Person leiten, die das Interesse und die geeigneten Qualifikationen dafür hatte.

Die Projektorientierung, die nicht funktionierte

Das war zwar sehr flexibel, aber es gab mehrere große Probleme mit diesem Modell:

1. Jeder einzelne Entwickler musste von allen Projektverantwortlichen verplant werden. Das war aufwändig und hatte Konfliktpotential („Mein Projekt ist wichtiger!“, „Ich will diesen Entwickler im Projekt haben!“). Entwickler waren parallel auch Mitglied in mehreren Teams. Und es gab niemanden, der den Überblick über die Gesamtverteilung der Auslastung im Unternehmen hatte.
2. Die immer neu zusammengewürfelten Teams waren nicht ideal für größere Projekte, die über längere Zeit betreut wurden. Wenn ein Projekt abgeschlossen war, „zerstreute“ sich das Team. Wurde das Projekt weiterentwickelt oder gab es einen Fehler (aka: Bug) auszubessern, musste man sich einen Entwickler suchen, der sich damit auskannte und längst in einem anderen Team an einer ganz anderen Lösung arbeitete.
3. Die Planung im Unternehmen musste komplett umgeworfen werden, wenn Projekte später als geplant abgeschlossen wurden.
4. Projekt versus „Kleinkram“: Die Planung von Aufgaben wie z.B. Schätzungen, Nacharbeit, Bug-Fixing und Wartung konkurrierte mit der Projektarbeit.
5. Die Planung von „Engpass-Ressourcen“ war schwierig: Manche Entwickler waren aufgrund ihrer speziellen Skill-Sets zwingend für ein oder mehrere Projekte notwendig. Sie mussten dann oft zwischen Projekten hin- und herspringen, was leicht zu einer Überlastung führte.
6. Das Thema „Planung von Teilzeitmitarbeitern“ machte die Situation nicht einfacher.
7. Der Wissensaustausch bzw. das Teamlernen waren unkoordiniert und hoher Kommunikationsaufwand war nötig, um einen Überblick über alle Projekte zu erhalten.
8. Letztendlich ging viel Energie ins „permanente Teambuilding“: Kaum hatten sich Leute zu echtem Teamwork zusammengefunden und ein „Wir-Gefühl“ entwickelt, war das Projekt fertig und alles begann von Neuem (siehe dazu auch das Modell nach Tuckman und Jensen – es geht um die Nachteile der letzten Phase „Adjourning“).

Unsere alte Struktur machte die Planung schwer und hatte etwas Konfliktpotential...

Um diese Probleme zu lösen, machten wir uns Gedanken über eine neue Organisationsform. Wir definierten gemeinsam folgende Ziele:

1. Einfachere Ressourcen-Planung
2. Konstantere Entwicklungsphasen (wenig bis kein Hin- und Herspringen zwischen Projekten, Einplanung von Zeit für unplanbare Arbeiten wie zum Beispiel Supportanfragen)
3. Reduktion auf nur mehr zwei Kern-Rollen für die Software-Projektumsetzung, die sich aus der Praxis ergaben (Product Owner*in und Software-Entwickler*innen).

Die Basis für die Veränderung: Ein kollegial geführtes Unternehmen

Es gibt den bekannten Spruch: „Der Fisch fängt vom Kopf an zu stinken.“. Positiv ausgedrückt: Das Management spielt eine wichtige Rolle für das Funktionieren des Unternehmens und vor allem auch für Veränderungsprozesse.

Bei uns ist es NICHT die Aufgabe des Managements im Planungs- oder Projektalltag Entscheidungen zu treffen. Jedes Teammitglied trägt Verantwortung für seinen Bereich und entscheidet in diesem selbstständig. Also kein „Ich sag dir, WAS du tust UND WIE du es tust.“.

Wichtig dabei: Das Management muss die Unternehmenskultur und den Nährboden dafür schaffen, dass Teammitglieder selbst die Entscheidungen treffen können, die im Arbeitsalltag wichtig sind. 

Die Inhaber des Unternehmens haben die Aufgabe, diejenigen Werte festzulegen, auf deren Basis sich die Unternehmenskultur entwickeln kann. Bei uns führten diese Werte zu einem „kollegial geführten Unternehmen“. In diesem werden nicht nur bessere, sondern auch schnellere Entscheidungen getroffen – und zwar genau da, wo sie benötigt werden: im Arbeitsalltag in den Teams und nicht im Management. Dies hilft auch dem Projektfortschritt und damit unseren Kunden!

Wir entwickelten unser neues Modell nach und nach und stellten Schritt für Schritt unsere Organisation um. 

Aus den Projektverantwortlichen wurden Product Owner*innen auf Basis der Definition nach Scrum. Product Owner*innen sind die internen Stellvertreter*innen des Kunden: Sie managen die Projekte unserer Kunden und repräsentieren die Wünsche und Anforderungen der Auftraggeber und User*innen der Software. Sie erarbeiten in Workshops mit den Kunden auch die Spezifikation der umzusetzenden Lösung. 

All unsere Product Owner*innen im CSS-Team haben selbst Software entwickelt und verfügen über Kompetenzen auf drei Ebenen: technisch/fachlich, organisatorische und sozial. 

Intern arbeiten sie je nach Projekt mal mit diesem und mal mit jenem Entwicklungsteam zusammen; eine fixe Teamzuordnung der Product Owner*innen gibt es bei uns nicht.

Unsere Softwareentwicklungsteams sind "permanent" und werden nicht wie in der Vergangenheit für jedes Projekt neu zusammengestellt. Innerhalb der Entwicklungsteams sind alle Teammitglieder selbst für die sozialen und organisatorischen Belange des Teams verantwortlich: Zum Beispiel für die optimale individuelle Teamkultur und für den (teamübergreifenden) Wissensaustausch. Auch hier gilt das Motto "Teamwork statt Hierarchie".

Mit unseren fixen Teams sorgen wir für Stabilität im Kernaufgabenbereich unseres Unternehmens, der Softwareentwicklung: Unsere Kunden profitieren von langfristig bestehenden Ansprechpartner*innen, die ihre Arbeitswelt und Prozesse kennen (Stichwort: Domain Driven Design). 

Zusätzlich verfügen mehrere Softwareentwickler*innen über das Know-how und die Erfahrung mit den umgesetzten Lösungen. So werden zum Beispiel lange "Wieder-Einlern-Phasen" vermieden, wenn eine Softwarelösung erweitert wird, die schon länger im Einsatz ist.

Auch das Zwischenmenschliche spielt dabei eine große Rolle: Wir achten darauf, dass in jedem Team Entwickler*innen miteinander arbeiten, die einander gut ergänzen und Spaß am gemeinsamen Arbeiten haben. So fließt die volle Energie unserer Teams in die Softwarelösung und nicht in laufendes "Team-Rebuilding" oder gar Konfliktlösung.

Eine vereinfachte Darstellung unserer Organisationsform als Kreisorganisation. 

Austausch zwischen den Teams

Da unsere Product Owner*innen viel miteinander reden und in gemeinsamen Büros sitzen, kommt es auch zur teamübergreifenden Verbesserung von Arbeitsprozessen. 

Dies führt unter anderem dazu, dass unsere Product Owner*innen keine Einzelkämpfer*innen sind, sondern sich über Erfahrungen und Probleme austauschen und einander unterstützen. Auch in den wöchentlichen Planungsmeetings mit den Teams entsteht Kommunikation über Team- und Projektgrenzen hinweg.

Unsere Organisationsform ist nicht in Stein gemeißelt

Dem Philosoph Heraklit von Ephesos wird folgender Satz zugeschrieben: „Die einzige Konstante im Universum ist die Veränderung.“.

Eine kluge Aussage, die auch auf unsere Organisationsform zutrifft. Immer und immer wieder finden wir Kleinigkeiten in der Struktur und den Prozessen, die wir verbessern können. Wie die Software-Entwicklung an sich, verändert sich auch unser Unternehmen laufend weiter. Neue Chancen und neue Herausforderungen sorgen für eine zyklische, agile Anpassung und Änderung unseres Organisationsmodells.

Oder um einen anderen österreichischen Philosophen namens Reinhard Fendrich zu zitieren: „Alles ist möglich. Aber nix is fix!“.